Android开发知识学习——从Retrofit原理来看HTTP

文章目录

Retrofit 使用方法简介
Retrofit 源码结构总结
扔物线读源码的思路与方式

Retrofit 使用方法简介

导包

  implementation 'com.squareup.retrofit2:retrofit:最新版本'

创建一个 interface 作为 Web Service 的请求集合，在里面用注解
（Annotation）写入需要配置的请求方法
Java代码

public interface GitHubService {
@GET("users/{user}/repos")
Call<List<Repo>> listRepos(@Path("user") String user);
}

Kotlin代码

interface GitHubService {
    @GET("users/{user}/repos")
    fun listRepos(@Path("user") user: String?): Call<List<Repo>>
}

在正式代码里用 Retrofit 创建出 interface 的实例
Java代码

Retrofit retrofit = new Retrofit.Builder()
.baseUrl("https://api.github.com/")
.build();
GitHubService service =
retrofit.create(GitHubService.class);

Kotlin代码

//用Retrofit创建出interface的实例
        val retrofit: Retrofit = Retrofit.Builder()
            .baseUrl("https://api.github.com/")
            .build()
        val service:GitHubService = retrofit.create(GitHubService::class.java)

调用创建出的 Service 实例的对应方法，创建出相应的可以用来发起网络请求的Call 对象
Java代码

Call<List<Repo>> repos = service.listRepos("octocat");

Kotlin代码

//创建出service实例的对应方法，创建出对应的可以用来发送网络请求的call对象
        val repos :Call<List<Repo>> = service.listRepos("octocat")

使用 Call.execute() 或者 Call.enqueue() 来发起请求
Java代码

repos.enqueue(callback);

Kotlin代码

//使用 Call.execute() 或者 Call.enqueue() 来发起请求
repos.enqueue(callback);

repos.enqueue(object : Callback<List<Repo>?>  {
            override fun onResponse(call: Call<List<Repo>?>, response: Response<List<Repo>?>) {
                TODO("Not yet implemented")
            }

            override fun onFailure(call: Call<List<Repo>?>, t: Throwable) {
            }
        })

在这里插入图片描述

Retrofit 源码结构总结

通过 Retrofit.create(Class) 方法创建出 Service interface 的实例，从
而使得 Service 中配置的方法变得可用，这是 Retrofit 代码结构的核心；
Retrofit.create() 方法内部，使用的是Proxy.newProxyInstance() 方法来创建 Service 实例。这个方法会为参数中的多个 interface （具体到 Retrofit 来说，是固定传入一个 interface）创建一个对象，这个对象实现了所有 interface 的每个方法，并且每个方法的实现都是雷同的：调用对象实例内部的一个 InvocationHandler 成员变量的invoke() 方法，并把自己的方法信息传递进去。这样就在实质上实现了代理逻辑：interface 中的方法全部由一个另外设定的 InvocationHandler 对象来进行代理操作。并且，这些方法的具体实现是在运行时生成 interface 实例时才确定的，而不是在编译时（虽然在编译时就已经可以通过代码逻辑推断出来）。这就是网上所说的「动态代理机制」的具体含义。
因此， invoke() 方法中的逻辑，就是 Retrofit 创建 Service 实例的关键。这
个方法内有三行关键代码，共同组成了具体逻辑：

ServiceMethod 的创建：

loadServiceMethod(method)

这行代码负责读取 interface 中原方法的信息（包括返回值类型、方法注解、参
数类型、参数注解），并将这些信息做初步分析。实际返回的是一个
CallAdapted 。

OkHttpCall 的创建：

new OkHttpCall<>(requestFactory, args, callFactory,
responseConverter)

OkHttpCall 是 retrofit2.Call 的子类。这行代码负责将ServiceMethod 解读到的信息（主要是一个 RequestFactory 、一个OkHttpClient 和一个 ResponseConverter ）封装进 OkHttpCall ；而这个对象可以在需要的时候（例如它的enqueue() 方法被调用的时候），利用 RequestFactory 和 OkHttpClient 来创建一个 okhttp3.Call对象，并调用这个okhttp3.Call 对象来进行网络请求的发起，然后利用ResponseConverter 对结果进行预处理之后，交回给 Retrofit 的Callback 。

adapt() 方法：

callAdapter.adapt(call);

这个方法会使用一个 CallAdapter 对象来把 OkHttpCall 对象进行转换，生成一个新的对象。默认情况下，返回的是一个 ExecutorCallbackCall ，它的作用是把操作切回主线程后再交给 Callback 。另外，如果有自定义的 CallAdapter，这里也可以生成别的类型的对象，例如RxJava 的 Observable ，来让 Retrofit 可以和 RxJava 结合使用。

更细的代码逻辑（例如 ServiceMethod 如何做方法解析、CallAdapter 如何做adapt，就不在讲义里再总结一遍了，可以看课上的分析）

扔物线读源码的思路与方式

寻找切入点，而不是逐行通读
- 理想情况下，逐行通读可以最高效率读通一个项目的代码，因为每行代码都只需要读一遍；但实时情况下，逐行通读会导致脑中积累太多没有成体系的代码，导致你读个几十几百行就读不下去了，因此一点也不实用。而从切入点开始读，可以在最快时间内把看到的代码体系化，形成一个「完整的小世界」；在把「小世界」看明白之后，再去一步步扩大和深入，就能够逐渐掌握更多的细节。
- 寻找切入点的方式：离你最近的位置就是切入点，通常是业务代码中的最后一行。
- 以 Retrofit 为例，最后的 Call.enqueue() 会被我作为切入点；在尝试从 Call.enqueue() 切入失败后，逐步回退到 Retrofit.create()方法，找到项目结构的核心，然后开始继续发散和深入。
在阅读过程中，始终保有把看过的代码逻辑完整化的意识
- 代码阅读过程中，不懂的代码会越来越多，脑子就会越来越乱。如果不断尝试把看到的代码结合起来组合成完整逻辑，就能让头脑始终保持清晰，而不是深入到某个细节好久之后忽然一抬头：「我为什么点进这个方法来着？」可以试着在读源码的时候，经常把多行或多段代码在脑子里（或者笔记里）
  组合成一整块，从而让代码结构更清晰，让阅读过程不断增加进度感，也减小继续阅读的难度。
- 以 Retrofit 为例，当读懂 Proxy.newProxyInstance() 方法实际上是创建了一个代理对象的时候，可以停下来做一个总结：「这是 Retrofit 的大框架」，在脑子里或者笔记上都可以。总结消化过后，再继续阅读。
尽量让每一刻都有一个确定的目标
- 读代码经常会出现「横向逻辑还没看清晰，纵向深度也没挖透」的情况。那么到底是要横向扩展阅读结构，还是纵向挖深度，最好是在每次遇到这种分岔路口的时候就先做好决定。不能在每个分岔路口都想也不想地看到不懂的就追下去，容易迷路。
- 在遇到「横向也广，纵向也深」的时候，根据情况选择其中一个就好，并没有必然哪种选择更优的铁律。而如果遇到越钻越头大的情况，可以退回之前的某一步，换条路继续走。换路的时候记得做好标记：「我在哪里探路失败了」。