Retrofit 的神秘面纱

作者: geniusmart | 来源:发表于2016-09-04 22:41 被阅读2541次

Retrofit 的神秘面纱
为您揭开runtime的神秘面纱 <一>
神秘面纱
婚姻的神秘面纱
✍揭开神秘的面纱 ✍
摘下神秘的面纱
GIT 的神秘面纱
揭开神秘的《面纱》
揭开神秘的面纱
掀开神秘面纱

初识Retrofit时，觉得很神奇，体现在以下两点：

神奇之一：仅凭注解和接口便可执行网络请求。

public interface GithubService {

    @GET("users/{username}")
    Call<User> getUser(@Path("username") String username);

}

神奇之二：接口方法的返回值变幻无穷。

无论你是用默认的方式，或者是RxJava，无论是在Java或是Android中调用，Retrofit均可满足，体现在接口的返回值，如下代码：

public interface GithubService {

    //默认方式
    @GET("users/{username}")
    Call<User> getUserByDefault(@Path("username") String username);

    //RxJava方式
    @GET("users/{username}")
    Observable<User> getUserByRxJava(@Path("username") String username);

}

这两个神奇之处，犹如两层神秘面纱，将Retrofit原本俊俏娇羞的脸庞，遮掩得若隐若现。若不揭开面纱，一睹芳容，便无处释放程序员们最原始的冲动，于是一起来阅读源码吧。

寻找接口的实现类

对于第一个神奇之处，首先我们来看看GithubService接口是如何调用的：

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

GitHubService service = retrofit.create(GitHubService.class);
Call<User> call = githubService.getUser("geniusmart");

仔细斟酌这段代码，GitHubService本身是个接口，并调用了getUser()方法获得返回值，那么问题来了：

GitHubService是由我们定义的接口，但是我们并没有定义实现类，实现类到底在哪里？
既然我们没有定义实现类，那么大胆假设该实现类是由Retrofit框架提供的。对于框架而言，该接口是由开发者自定义的，框架无法做到未卜先知，那么他是如何做到的？

以上两个问题可以总结为：框架如何动态生成GitHubService的实现类？答案也不难猜测——动态代理模式。（对动态代理有疑问的同学，可以先看下《公共技术点之 Java 动态代理》。

接下来验证我们的猜测，GitHubService的来源在此行代码中：

GitHubService service = retrofit.create(GitHubService.class);

查看create()的源码，所有谜底都将揭开：

通过JDK实现动态代理

这个方法生成并返回了GitHubService的动态代理对象，在执行接口的每个方法时，实际执行的是invoke()，而该方法里的逻辑便是此框架的主体流程，如下代码：

public Object invoke(Object proxy, Method method, Object... args){
    //1.负责注解的解析
    ServiceMethod serviceMethod = loadServiceMethod(method);
    //2.负责与OKHttp3的对接，处理同步和异步发送网络请求
    OkHttpCall okHttpCall = new OkHttpCall<>(serviceMethod, args);
    //3.第二层面纱，下文再做解释
    return serviceMethod.callAdapter.adapt(okHttpCall);
}

这个方法里，做了三件事情：

解析方法的注解，比如get/post、url、Headers等，解析的结果存放于ServiceMethod对象中。
创建OkHttpCall，该对象负责与OKHttp3对接，处理同步或异步的网络请求。
这是第二层神秘面纱的谜底，下文再做解释。

至此，我们揭开了Retrofit的第一层神秘面纱，这是一位简单而优雅的小女子，表面朴实无华，恬静清新，令人迫不及待想要揭开她的第二层面纱，知晓她的内心世界。

变幻无穷的适配

首先来回顾下上文提到的第二个神秘之处，同样是获取用户信息的网络请求，可以返回Call<User>或 Observable<User>，这是如何做到的？

上文中，invoke()做的第三件事情便是获取返回值，如下：

return serviceMethod.callAdapter.adapt(okHttpCall);

其中，adapt是适配的意思，其目的是变废为宝，将指定的输入类型适配成实际需要的输出类型，来查看下它的源码：

public interface CallAdapter<T> {
  <R> T adapt(Call<R> call);
}

我们重点关注下adapt的输入输出。这里的设计非常大胆，输入是有约束的，即 Call类型，而输出为泛型T，也就是说输出是没有任何约束的，如此一来，扩展性极强，可以指定任何的类型。

剩下来的问题便是：

adapt由哪个对象触发，即CallAdapter的具体实现是什么？
输入类型Call的具体实现是什么？
输出类型T的具体实现是什么？

这里直接给出答案，如下两图：

默认方式的适配

RxJava方式的适配

通过上面两图，可以看到，输入对象是固定的，即OkHttpCall对象，网络请求实际上便是由该对象发起的。
默认方式的输出对象是ExecutorCallbackCall，它持有OkHttpCall对象，指定了网络请求执行结束后的回调函数在UI线程中执行。
RxJava方式的输出对象是Observable，持有该对象便具备函数式编程的能力。
adapt()的调用者——适配器CallAdapter是动态配置的，默认方式无需配置，如果使用RxJava，则需要配置适配器的工厂对象，如下代码：

Retrofit retrofit = new Retrofit.Builder()
    .baseUrl(BASE_URL)
    .addConverterFactory(GsonConverterFactory.create())
    .addCallAdapterFactory(RxJavaCallAdapterFactory.create())
    .build();

这样设计简直是解耦得一塌糊涂，我们可以任意变换调用方式，也可以任意扩展CallAdapter来定义新的调用方式，而框架无需做任何调整。比如JakeWharton前几天开源的RxJava2的适配——retrofit2-rxjava2-adapter，比如针对Google函数式编程库 Agera的适配——retrofit-agera-call-adapter，简直OCP得一塌糊涂。

至此，第二层神秘面纱缓缓而落，这是一位心灵手巧的奇女子，你给她一针一线，她还你一幅刺绣，刺绣上可以是锦绣山河，也可以是紫气东来；你给她新鲜的食材，她变幻出色香味俱全的美味佳肴。