文章目录
- [Retrofit 使用方法简介](#Retrofit 使用方法简介)
- [Retrofit 源码结构总结](#Retrofit 源码结构总结)
- 扔物线读源码的思路与方式
Retrofit 使用方法简介
- 导包
kotlin
implementation 'com.squareup.retrofit2:retrofit:最新版本'
- 创建一个 interface 作为 Web Service 的请求集合,在里面用注解
(Annotation)写入需要配置的请求方法
Java代码
java
public interface GitHubService {
@GET("users/{user}/repos")
Call<List<Repo>> listRepos(@Path("user") String user);
}
Kotlin代码
kotlin
interface GitHubService {
@GET("users/{user}/repos")
fun listRepos(@Path("user") user: String?): Call<List<Repo>>
}
- 在正式代码里用 Retrofit 创建出 interface 的实例
Java代码
java
Retrofit retrofit = new Retrofit.Builder()
.baseUrl("https://api.github.com/")
.build();
GitHubService service =
retrofit.create(GitHubService.class);
Kotlin代码
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代码
java
Call<List<Repo>> repos = service.listRepos("octocat");
Kotlin代码
kotlin
//创建出service实例的对应方法,创建出对应的可以用来发送网络请求的call对象
val repos :Call<List<Repo>> = service.listRepos("octocat")
- 使用 Call.execute() 或者 Call.enqueue() 来发起请求
Java代码
java
repos.enqueue(callback);
Kotlin代码
kotlin
//使用 Call.execute() 或者 Call.enqueue() 来发起请求
repos.enqueue(callback);
kotlin
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 的创建:
kotlin
loadServiceMethod(method)
这行代码负责读取 interface 中原方法的信息(包括返回值类型、方法注解、参
数类型、参数注解),并将这些信息做初步分析。实际返回的是一个
CallAdapted 。
- OkHttpCall 的创建:
kotlin
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() 方法:
kotlin
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 的大框架」,在脑子里或者笔记上都可以。总结消化过后,再继续阅读。
- 代码阅读过程中,不懂的代码会越来越多,脑子就会越来越乱。如果不断尝试把看到的代码结合起来组合成完整逻辑,就能让头脑始终保持清晰,而不是深入到某个细节好久之后忽然一抬头:「我为什么点进这个方法来着?」可以试着在读源码的时候,经常把多行或多段代码在脑子里(或者笔记里)
-
尽量让每一刻都有一个确定的目标
- 读代码经常会出现「横向逻辑还没看清晰,纵向深度也没挖透」的情况。那么到底是要横向扩展阅读结构,还是纵向挖深度,最好是在每次遇到这种分岔路口的时候就先做好决定。不能在每个分岔路口都想也不想地看到不懂的就追下去,容易迷路。
- 在遇到「横向也广,纵向也深」的时候,根据情况选择其中一个就好,并没有必然哪种选择更优的铁律。而如果遇到越钻越头大的情况,可以退回之前的某一步,换条路继续走。换路的时候记得做好标记:「我在哪里探路失败了」。