Retrofit 入门
相信对于retrofit而言，很多人都知道如何用，网上也有很多文章介绍使用retrofit。而对于它的原理，简直跟它的名字一样，不相上下，介绍使用它的文章更是数不胜数，就是基于动态代理，也为我们对于动态代理的应用提供了一个新思路，这里是对retrofit实现的分析，也会提及它的动态代理部分，下面就是借着retrofit的分析，来重新了解retrofit的设计部分,分成三个部分来进行分析：
1.【Retrofit三步走：流程梳理篇】
2.【Retrofit三步走：request篇】
3.【Retrofit三步走：Response篇】
准备部分
注：这里使用的retrofit2.6.0版本
引用为：implementation ‘com.squareup.retrofit2:retrofit:2.6.0’
对于Retrofit的使用，相信大家都很熟悉，我们先看看我们如何使用Retrofit
Retrofit retrofit = new Retrofit.Builder()
.baseUrl("http://www.test.com/") //设置网络请求的Url地址
.addConverterFactory(GsonConverterFactory.create()) //设置数据解析器
.addCallAdapterFactory(RxJavaCallAdapterFactory.create())
.build();
retrofit.create(某.class);
相信大多都是如此书写，那我们就先从Retrofit的Builder中开始分析,着重了解retrofit对Request请求的一个构造
首先Builder当中就是我们提供的外部配置信息，像我们传入的GsonConverterFactory和RxJavaCallAdapterFactory分别存放在covertFactories和calladapterFactories中
我们看看我们引入的三方支持包GsonConverterFactory和RxJavaCallAdapterFactory
GsonConverterFactory:
RxJavaCallAdapterFactory:
这两个factory是我们整个网络的关键类,我们随后在response篇去详细分析它们
接下来就剩下我们retrofit的入口方法create()，我们这篇也就顺着create来完成对retrofit的Request篇的分析
retrofit的create前半部分的方法如下：
public <T> T create(final Class<T> service) {
首先是对我们目标的接口service进行验证是否合法
Utils.validateServiceInterface(service);
if (validateEagerly) {
eagerlyValidateMethods(service);
}
}
具体的合法验证规则如下：
validateServiceInterface的方法：
static <T> void validateServiceInterface(Class<T> service) {
if (!service.isInterface()) {
throw new IllegalArgumentException("API declarations must be interfaces.");
}
if (service.getInterfaces().length > 0) {
throw new IllegalArgumentException("API interfaces must not extend other interfaces.");
}
}
这个合法验证就是验证我们传递的参数必须为一个接口且这个接口不可以有继承，否则就时非法直接抛出异常
紧跟着后面进行一个validateEagerly对我们的method进行有效形验证的判断，当validateEagerly为true时，进行eagerlyValidateMethods这个方法：
之所以把eagerlyValidateMethods和loadServiceMethod两个方法连在一起分析，从loadServiceMethod方法中的serviceMethodCache可以看着这里做了预处理操作内部存放了我们要处理的接口数据class
故对于validateEagerly的作用也很清晰了，就是是否对我们目标的类，进行预处理操作
到这里，对于Retrofit这个类的庞大的build模块相关部分就到这里了
核心部分
retrofit最主要的实现位置是动态代理这部分，也就是create的返回值部分，如下
在动态代理的这部分，分成三部分
第一部分是容错处理部分，即对Object类型的正常调用的返回以及不同平台的处理;
好比isDefaultMethod的处理,就是应对 Java8 中 的 default 方法处理即判断该方法对象是否为默认方法;对于这个不同平台可能会有人觉得有问题，其实在这个Platform类中有两个内部类：
即Android/IOS两个内部类处理，然后把主线程就放在了这两个内部类里面，Android里面通过Looper.getMainLooper()方法来放置MainThreadExecutor，而IOS这里，则放置的一个"org.robovm.apple.foundation.NSOperationQueue"的一个东西来做MainThreadExecutor，对与NSOperationQueue是苹果提供的一套多线程处理方案,而robovm是一个已经商用的RoboVM 编译器,Robovm可以编译java代码并有iOS一整套的转化代码来桥接，有兴趣的朋友可以自行去研究，这里仅贴出代码:
Robovm地址:https://github.com/robovm/robovm
第二部分是预处理部分殊途同归的方法loadServiceMethod方法;
这部分是对request组成【request分析篇】和response的组成【response分析篇】结构处理部分，我们放在两个篇章详细分析
对应篇章链接地址：【request分析篇】【response分析篇】
最后一部分就是借助okhttp发起请求
最后这部分是结合okhttp串连之前的request和response，从而完成网络请求的发起和处理，我们放在response里来详细赘述