初识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()的源码，所有谜底都将揭开：
这个方法生成并返回了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的具体实现是什么？
这里直接给出答案，如下两图：
- 通过上面两图，可以看到，输入对象是固定的，即
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得一塌糊涂。
至此，第二层神秘面纱缓缓而落，这是一位心灵手巧的奇女子，你给她一针一线，她还你一幅刺绣，刺绣上可以是锦绣山河，也可以是紫气东来；你给她新鲜的食材，她变幻出色香味俱全的美味佳肴。
总结
动态代理、适配是Retrofit的核心，理解清楚这两点，再去梳理框架的其他细节，方可事半功倍。除此之外，框架内部使用了大量的Builder模式和Factory模式，这两个模式使得创建对象和获取对象更有条理，更清晰易懂。值得一提的是，这个框架配备了完整的单元测试用例，非常值得我们学习。
参考文章
http://square.github.io/retrofit/
https://github.com/square/retrofit
