众所周知，Retrofit是OkHttp的封装，APP对网络交互部分的完结根本上都是RxJava+Retrofit+OkHttp架构（或协程+Retrofit+OkHttp），可以说，Retrofit现已广为人知。本文首要介绍Retrofit主线源码完结机制，及其所选用的规划形式所涉及到的思维等等。
OKHttp 的运用缺点
这儿说的运用缺点是不那么便当的当地：
1）用户网络恳求的接口装备繁琐，尤其是需求装备杂乱恳求body，恳求头，参数的时分；
2）数据解析进程需求用户手动拿到responsbody进行解析，不能复用；
3）无法适配主动进行线程的切换；
4）万一咱们的存在嵌套网络恳求就会堕入“回调陷阱”。
Retrofit首要处理的问题
在OkHttp运用如此繁琐的情况下，更方便运用的Retrofit应运而生。其所处理的OkHttp的缺点问题包含两方面：
①恳求前：完结共同装备的网络恳求头，共同适配恳求request。
②成果回来：retrofit完结数据适配、线程切换。
简略运用
（本段文字仅讲述retrofit的根本用法，假设对其用法以及掌握的老铁可以直接跳过，检查源码解析部分。）
1、增加依靠
implementation'com.squareup.retrofit2:retrofit:2.9.0'
implementation'com.squareup.retrofit2:converter-gson:2.9.0'
2、界说网络服务接口
增加依靠并同步后，创立一个接口，专门担任界说网络API。这儿咱们选用接口是用于
调试Github的敞开API，接口为：api.github.com/users/octoc… 在恳求后会获取Github用户Octocat的Repo列表：
public interfaceNetService {
@GET("users/{user}/repos") //装备Get恳求、URL路径
Call<List<Repo>>getRepos(@Path("user") String user); //指定回来Call<T>方针，这儿的T指定网络解析数据后回来的类型
//@Path（"user"）表明参数user会替换URL路径中的{user}
}
3、在AndroidManifest.xml中增加网络权限：
<uses-permissionandroid:name="android.permission.INTERNET"/>
4、完结网络服务接口
创立好接口后，接下来便是用Retrofit完结此接口恳求逻辑：
Retrofit retrofit =newRetrofit.Builder()
.baseUrl("https://api.github.com") //装备URL的基地址
.addConverterFactory(GsonConverterFactory.*create*())//装备Gson转化器
.build();
NetService netService = retrofit.create(NetService.class); //用Retrofit方针回来一个NetService的完结
Call<List<Repo>> octocat = netService.getRepos("octocat"); //获取Call方针，用该方针的enqueue完结异步恳求
octocat.enqueue(newCallback<List<Repo>>() {
@Override
public voidonResponse(Call<List<Repo>> call,Response<List<Repo>> response) {
for(Repo rp : response.body()){
Log.i(TAG,"get the id:"+(rp.getId())); //获取数据后打印ID
}
}
@Override
public voidonFailure(Call<List<Repo>> call,Throwable t) {
Log.i(TAG,"onFailure:"+(t.toString()));
}
});
运转后可见打印的日志：
源码流程图
下面是调用Retrofit做一次网络恳求的代码流程：
动态署理
Retrofit源码中运用了动态署理，在看源码之前咱们有必要先了解。在某些场景下，咱们要用某些功用，但不是直接调用完结类，而是经过署理类来完结的。经过署理，咱们可以躲藏完结类的细节，在不修改完结类的基础之上，增加额外的功用等。在日常日子中，署理形式处处可见，例如房屋中介、二手车贩子、代购等等。咱们所说的署理，一般是指静态署理，即一个完结类对应一个署理类，彼此一一对应。假设你现在是个大型轮胎制造商，有家轿车公司预备在你这儿订货车轮胎，咱们用代码完结下：
首要，完结个接口，表明咱们要做的事情——造轮胎：
public interfaceWheel {
voidproduce();
}
然后完结这个接口：
public classWheelMakerimplementsWheel{
@Override
public voidproduce() {
Log.i("proxyDemo","造好并装上车轮");
}
}
独自的车轮是没有用的，这个时分轿车厂商就来了，要把车轮装上去，轿车厂商完结代码如下：
public classBenZimplementsWheel{
privateWheelwheel;
publicBenZ(Wheel wheel){
this.wheel= wheel;
}
@Override
public voidproduce() {
before();
wheel.produce();
after();
}
private voidafter() {
Log.i("proxyDemo","BenZ整车拼装结束，可以售卖了");
}
private voidbefore() {
Log.i("proxyDemo","BenZ拼装好其他零件，只缺装轮胎了");
}
}
轿车厂商来了，拿走了轮胎，就下来便是拼装了，拼装好就可以售卖，然后才有钱回款给你，你公司才能赚钱，代码如下：
Log.*i*("proxyDemo","--------------静态署理-------------");
Wheel wheel =newWheelMaker();
BenZ benZ =newBenZ(wheel);
benZ.produce();
轿车公司拿着你给的轮胎接口后进行拼装，然后售卖，代码很简略没必要过多解释了。对应履行后对应输出如下：
public classSpecialWheelMakerimplementsWheel{
@Override
public voidproduce() {
Log.i("proxyDemo","造好特别车轮并装上-");
}
}
听说你造好后，军方来人，拿走你的轮胎回去拼装并给了你项目回款：
public classTankimplementsWheel{
privateSpecialWheelMakerspecialWheelMaker;
publicTank(SpecialWheelMaker specialWheelMaker){
this.specialWheelMaker= specialWheelMaker;
}
@Override
public voidproduce() {
before();
specialWheelMaker.produce();
after();
}
private voidafter() {
Log.i("proxyDemo","Tank拼装结束，预备上战场了");
}
private voidbefore() {
Log.i("proxyDemo","Tank拼装好其他零件，只缺装轮胎了");
}
}
拼装结束那天，军方邀请你去观赏，所以你一边叮咛手下人持续做事，一边前去观赏，代码如下：
Log.i("proxyDemo","--------------轿车的静态署理-------------");
Wheel wheel = new WheelMaker();
BenZ benZ = new BenZ(wheel);
benZ.produce();
Log.i("proxyDemo","--------------Tank的静态署理-------------");
SpecialWheelMaker specialWheelMaker = new SpecialWheelMaker();
Tank tank = new Tank(specialWheelMaker);
tank.produce();
对应输出为：
这儿就需求用到动态署理了。动态署理不需求事先创立署理（轿车厂商）类，而是依据需求动态创立。相当于一个工厂流水线，对应不同种类型轮胎产品，不管轮胎类型数量增加多少，出产线只要一个。从代码的视点来说，不会增加轿车厂商类，厂商的公共办法就能得到复用。
首要，咱们界说一个动态署理类，需求完结InvocationHandler接口，然后在invoke()中增加相应的逻辑：
public classDynamicProxyWheelimplementsInvocationHandler {
privateObjectwheel; //署理的方针
publicDynamicProxyWheel(Object wheel){
this.wheel= wheel;
}
@Override
publicObjectinvoke(Object proxy,Method method,Object[] args)throwsThrowable {
before();
method.invoke(wheel,args);
after();
return null;
}
private voidafter() {
Log.i("proxyDemo","悉数拼装结束，预备交付");
}
private voidbefore() {
Log.i("proxyDemo","先拼装好其他部件及体系");
}
}
接下来，咱们运用这个动态署理轮胎来出产各种轮胎了：
public classDynamicProxyWheelimplementsInvocationHandler {
privateObjectwheel; //署理的方针
publicDynamicProxyWheel(Object wheel){
this.wheel= wheel;
}
@Override
publicObjectinvoke(Object proxy,Method method,Object[] args)throwsThrowable {
before();
method.invoke(wheel,args);
after();
return null;
}
private voidafter() {
Log.i("proxyDemo","悉数拼装结束，预备交付");
}
private voidbefore() {
Log.i("proxyDemo","先拼装好其他部件及体系");
}
}
Builder形式
Retrofit retrofit =newRetrofit.Builder()
.baseUrl("https://api.github.com") //装备URL的基地址
.addConverterFactory(GsonConverterFactory.*create*())//装备Gson转化器
.build();
在声明Retrofit方针的时分，咱们可以看到这儿应用了一个制作者（构建者）形式，制作者形式的特点是可以讲一个杂乱方针的构成和表明别离开来。这儿，咱们首要重视build()办法的完结：
publicRetrofitbuild() {
if(baseUrl==null) {
throw newIllegalStateException("Base URL required.");
}
//设置Call的工厂类，假设没有设置，则为OkHttpClient方针
okhttp3.Call.Factory callFactory =this.callFactory;
if(callFactory ==null) {
callFactory =newOkHttpClient();
}
//履行回调办法的方针，Android里是在主线程履行回调
Executor callbackExecutor =this.callbackExecutor;
if(callbackExecutor ==null) {
callbackExecutor =platform.defaultCallbackExecutor();
}
//网络恳求适配器工厂调集
// Make a defensive copy of the adapters and add the default Call adapter.
List<CallAdapter.Factory> callAdapterFactories =newArrayList<>(this.callAdapterFactories);
callAdapterFactories.addAll(platform.defaultCallAdapterFactories(callbackExecutor));
//数据转化器工厂类调集，用于解析网络呼应
// Make a defensive copy of the converters.
List<Converter.Factory> converterFactories =
newArrayList<>(
1+this.converterFactories.size() +platform.defaultConverterFactoriesSize());
// Add the built-in converter factory first. This prevents overriding its behavior but also
// ensures correct behavior when using converters that consume all types.
converterFactories.add(newBuiltInConverters());
converterFactories.addAll(this.converterFactories);
converterFactories.addAll(platform.defaultConverterFactories());
return newRetrofit(
callFactory,
baseUrl,
*unmodifiableList*(converterFactories),
*unmodifiableList*(callAdapterFactories),
callbackExecutor,
validateEagerly);
}
假设这时分是一头雾水，很正常，咱们先测验去了解代码，到终究，咱们都会看明白的。 在Build()中，初始化了回调Call的工厂类，网络恳求适配器工厂调集，数据转化器工厂调集。可见其间Call的工厂类默许完结为OkHttpClient。默许的CallAdapter.Factory为ExecutorCallAdapterFactory方针。CallAdapter.Factory首要适配接口的回来类型，如咱们上述例子的接口：
public interfaceNetService {
@GET("users/{user}/repos")
Call<List<Repo>>getRepos(@Path("user") String user);
}
回来为Call类型，而Call类型则是由ExecutorCallAdapterFactory适配的，假设在创立Retrofit方针的时分指定装备RxJavaCallAdapterFactory：
Retrofit retrofit =newRetrofit.Builder()
.baseUrl("https://api.github.com")
.addCallAdapterFactory(RxJavaCallAdapterFactory.create())
.build();
则接口getRepos的回来类型可为RxJava的Observable。
Build()中还初始化了数据转化器工厂类调集，转化器工厂首要担任网络呼应的解析，比方咱们之前代码中是：
Retrofit retrofit =newRetrofit.Builder()
.baseUrl("https://api.github.com")
.addConverterFactory(GsonConverterFactory.*create*())
.build();
这儿设置了GsonConverterFactory，咱们就可以运用Gson解析网络成果，当然还有其他的工厂，比方PhotoConverterFactory，可以运用PhotoBuf解析网络成果。
build()中值得留意的一行代码是：
serviceMethodCache：这个map的第一个泛型参数Method即是咱们的恳求办法。S erviceMethod首要代表网络恳求接口中办法进行注解之后咱们经过解析解析后拿到的方针，与注解中的post、get等办法成对出现，一一对应。serviceMethodCache看姓名就知道是缓存，在这儿首要是做网络恳求相关装备的缓存（之前2.3版本的时分是个LinkedHashMap）。
call Factory：恳求网络的OKHttp的工厂，用于“出产”OKHttp的OKHttpClient；
baseUrl：网络恳求的url的基地址，与接口参数拼接起来便是个完整的URL；
converterFactories：数据转化器工厂调集，用于出产咱们需求的数据转化器（数据转化器：对咱们做了网络恳求后得到的response进行转化成咱们设定的Java方针）；
callAdapterFactories：网络恳求适配器工厂调集，用于放置咱们的网络恳求适配器工厂（网络恳求适配器：把咱们的call方针转化成其他类型）；
callbackExecutor：用于履行回调，Android类中默许的网络回调履行器为Main ThreadExecutor，经过绑定主线程Looper的Handler将网络回调推送到主线程履行。（Retrofit傍边的网络恳求，终究都是经过线程池将咱们的handler来进行调配，可以处理咱们的主线程和子线程等线程切换）毫无意外，咱们处理异步的网络恳求就需求用到它；
validateEagerly：一个符号位，表明是否需求当即解析咱们接口的办法。
咱们持续看Builder()，在这儿Builder是Retrofit的静态内部类：
Platform：表明Retrofit的适配渠道（Android，Java8等）；
baseUrl：网络恳求的URL地址（留意这儿是HttpUrl，不是String）；
converterFactories，callAdapterFactories，callbackExecutor，validateEagerly作用同上。
这儿的结构办法中回来的是Platform.get()，即适配渠道：
baseUrl()
Retrofit retrofit =newRetrofit.Builder()
.baseUrl("https://api.github.com")
.addConverterFactory(GsonConverterFactory.*create*())
.build();
在原例子中，第二行就指定baseUrl()，其办法内部首要作业便是对传入的String进行判空和URL转化：
addConverterFactory
addConverterFactory()操作比较简略，增加工厂调集：
addCallAdapterFactory
Retrofit retrofit =newRetrofit.Builder()
.baseUrl("https://api.github.com")
.addConverterFactory(GsonConverterFactory.*create*())
.addCallAdapterFactory(RxJavaCallAdapterFactory.*create*())
.build();
网络恳求适配器工厂，所做操作与addConverterFactory()相同，也都是相同的增加操作。
方针构成
这时分再回来咱们开端的build()：
网络恳求
在构建好Retrofit方针后，咱们就要对其进行网络恳求了：
Java接口默许不许有默许完结，可是Java8开端可以给接口的一些办法写默许完结了；Java接口不允许写静态办法，但Java8开端允许接口里写静态办法了。然而Retrofit是不支持的这些的，即Retrofit不接纳这两种办法为service接口里的办法。
所以这儿判别便是要求不是JAVA8的默许办法和静态办法。这时分才到要点的办法来：
在进这个办法之前，咱们先跳回原外界办法：
假设platform.isDefaultMethod(method)，则回来platform.invokeDefaultMethod(method, service, proxy, args)，假设不是，则loadServiceMethod(method).invoke(args)。
为了便于了解，上面的三元判别办法等价于：
if(platform.isDefaultMethod(method)){
platform.invokeDefaultMethod(method,service,proxy,args)
}else{
loadServiceMethod(method).invoke(args);
}
仍是判别是否是默许办法，假设不是，才履行loadServiceMethod(method)。结合上面代码，可看出不管validateServiceInterface()，终究都会履行loadServiceMethod()，可见loadServiceMethod()才是要害中的要害。
loadServiceMethod()
serviceMethod，在这儿对应的是接口办法（的封装）。serviceMethodCache在这儿是网络恳求相关装备的缓存，实质是一个Map，在这儿这个Map的key是method，假设能将对应method的value即serviceMethod取出，且不为空则return出去。假设为空，中心代码又变成了：
再看②：
static <ResponseT, ReturnT> HttpServiceMethod<ResponseT, ReturnT> parseAnnotations(
Retrofit retrofit, Method method, RequestFactory requestFactory) {
boolean isKotlinSuspendFunction = requestFactory.isKotlinSuspendFunction;//是否是Kotlin suspend办法
...
Annotation[] annotations = method.getAnnotations();//获取method的注解信息
...
if (!isKotlinSuspendFunction) {
return new CallAdapted<>(requestFactory, callFactory, responseConverter, callAdapter);
} else if (continuationWantsResponse) {
//noinspection unchecked Kotlin compiler guarantees ReturnT to be Object.
return (HttpServiceMethod<ResponseT, ReturnT>)
new SuspendForResponse<>(
requestFactory,
callFactory,
responseConverter,
(CallAdapter<ResponseT, Call<ResponseT>>) callAdapter);
} else {
//noinspection unchecked Kotlin compiler guarantees ReturnT to be Object.
return (HttpServiceMethod<ResponseT, ReturnT>)
new SuspendForBody<>(
requestFactory,
callFactory,
responseConverter,
(CallAdapter<ResponseT, Call<ResponseT>>) callAdapter,
continuationBodyNullable);
}
}
这个类中有几个参数要留意一下：
CallAdapte r表明的是网络恳求适配器，首要的把咱们的Call恳求适配不同的渠道，比方RxJava的渠道。
responseConverter表明的是数据转化器，其实便是reponse内容转化器，作用把服务器回来的Json数据转化成咱们的JavaBean方针。
public <T> Converter<ResponseBody, T> nextResponseBodyConverter(
@Nullable Converter.Factory skipPast, Type type, Annotation[] annotations) {
Objects.requireNonNull(type, "type == null");
Objects.requireNonNull(annotations, "annotations == null");
int start = converterFactories.indexOf(skipPast) + 1;
for (int i = start, count = converterFactories.size(); i < count; i++) {
Converter<ResponseBody, ?> converter =
converterFactories.get(i).responseBodyConverter(type, annotations, this);
if (converter != null) {
//noinspection unchecked
return (Converter<ResponseBody, T>) converter;
}
}
StringBuilder builder =
new StringBuilder("Could not locate ResponseBody converter for ")
.append(type)
.append(".\n");
if (skipPast != null) {
builder.append(" Skipped:");
for (int i = 0; i < start; i++) {
builder.append("\n * ").append(converterFactories.get(i).getClass().getName());
}
builder.append('\n');
}
builder.append(" Tried:");
for (int i = start, count = converterFactories.size(); i < count; i++) {
builder.append("\n * ").append(converterFactories.get(i).getClass().getName());
}
throw new IllegalArgumentException(builder.toString());
}
源码逻辑流程很像之前的CallAdapter，这儿也是遍历converterFactories并从中获取适宜的数据转化器工厂，然后再经过responseBodyConverter()获取到相应的数据转化器。（默许是Json转化器，所以这儿一般获取到的是JsonResponseConverter，了解即可）这样就完结了整个数据转化器的初始化作业。
OkHttpCall
这个OkHttpCall其实便是对OkHttp中的Call的一个封装。
adapt
总结下，先回到咱们的网络恳求代码：
所以这个netService实践上便是经过动态署理返还过来的OkHttpCall方针。而OkHttpCall方针又是对OkHttp的封装，所以这儿的.getRepos(“octocat)其实便是经过咱们的OkHttp库去恳求咱们网络然后实施同步和异步的办法。
Retrofit的恳求，OKHttp的创立
Retrofit的恳求其实也分为两种：
1、同步：OkHttpCall.execute()；
2、异步：OkHttpCall.enqueue()；
（这儿的OkHttpCall是指的create()里回来的OkHttpCall方针）
这儿咱们先重视咱们代码中的异步办法：
okHttpClient.newCall(request).enqueue(new Callback());
newCall()中参数是一个OkHttp里的Request方针，Request方针在Retrofit中经过requestFactory.create()创立，创立好后传给callFactory的newCall()并生成okhttp3.call方针。callFactory方针的创立在HttpServiceMethod的parseAnnotations()办法中，上面现已阐明，这儿不再赘述。
数据解析与回调
Response<T> parseResponse(okhttp3.Response rawResponse) throws IOException {
ResponseBody rawBody = rawResponse.body();
// Remove the body's source (the only stateful object) so we can pass the response along.
rawResponse =
rawResponse
.newBuilder()
.body(new NoContentResponseBody(rawBody.contentType(), rawBody.contentLength()))
.build();
int code = rawResponse.code();
if (code < 200 || code >= 300) {
try {
// Buffer the entire body to avoid future I/O.
ResponseBody bufferedBody = Utils.buffer(rawBody);
return Response.error(bufferedBody, rawResponse);
} finally {
rawBody.close();
}
}
if (code == 204 || code == 205) {
rawBody.close();
return Response.success(null, rawResponse);
}
ExceptionCatchingResponseBody catchingBody = new ExceptionCatchingResponseBody(rawBody);
try {
T body = responseConverter.convert(catchingBody);
return Response.success(body, rawResponse);
} catch (RuntimeException e) {
// If the underlying source threw an exception, propagate that rather than indicating it was
// a runtime exception.
catchingBody.throwIfCaught();
throw e;
}
}
不难看出，在这儿，retorfit将OkHttp回来的数据进行解析，然后将回来数据转化后再return，要点在这儿：
规划形式
经过上述的源码流程整理，不难发现Retrofit其实实质上便是一个网络恳求结构的封装。实践上的网络恳求等功用完结都是交给了OkHttp去完结。在这些代码封装之中，融合了太多的规划形式在里面。
制作者形式
外观形式 （ 门面形式 ）
门面形式要求一个子体系的外部与其内部通讯必须经过一个共同的方针进行。Retrofit给咱们暴露的办法和类不多。中心类便是Retrofit，咱们只管装备Retrofit，然后获取接口方针恳求数据，设置回调，其他的都是Retrofit结构内部的事情了。这儿Retrofit的门面是Retrofit.create() 。这样的代码规划能降低体系耦合度，除了Retrofit，平时开发常用的开源结构Glide也有一个门面，比方Glide.with(xxx)…。
动态署理
动态署理指的是程序运转的时分创立署理类的办法，署理形式中最重要的便是区别人物： 1、方针接口；2、方针方针；3、署理方针。
Retrofit中则是经过Proxy.newProxyInstance去调用其InvocationHandler中的invoke()来完结动态署理，详情上面现已阐明，这儿不再赘述。
装修形式
装修形式是在不改动原类文件和运用继承的情况下，动态的扩展一个方针的功用。Retrofit中用装修形式的便是ExecutorCallbackCall了。
简略说下，enqueue()办法是异步的，当你调用OkHttpCall的enqueue办法，回调的callback在子线程中，假设需求在主线程接受回调，那就要经过Handler转化到主线程上去。ExecutorCallbackCall便是用来干这个事。当然以上是retrofit默许运用的切换线程办法。假设咱们指定用rxjava，那就不会用到这个ExecutorCallbackCall而是RxJava的Call了。
也许你会感觉，装修形式与静态署理形式很像。但这俩者区别也不小：装修形式里，装修后的方针仍是“我”，只不过装修完后“我”的功用更加强壮；署理形式里方针现已不是“我”了，只不过署理形式可以联络到我罢了。
战略形式
战略形式界说了一组算法，将每个算法都封装起来，而且使它们之间可以交换。在CallAdapter中可以增加多个CallAdapter.Factory方针，相当于咱们封装了多个不同的适配算法CallAdapter.adapt()。上文现已阐明，其方针的生成初始化和调用都在HttpServerMethod.parseAnnotations()中：
static <ResponseT, ReturnT> HttpServiceMethod<ResponseT, ReturnT> parseAnnotations(
Retrofit retrofit, Method method, RequestFactory requestFactory) {
......
CallAdapter<ResponseT, ReturnT> callAdapter =
createCallAdapter(retrofit, method, adapterType, annotations);
Type responseType = callAdapter.responseType();
......
}
......
}
private static <ResponseT, ReturnT> CallAdapter<ResponseT, ReturnT> createCallAdapter(
Retrofit retrofit, Method method, Type returnType, Annotation[] annotations) {
try {
//noinspection unchecked
return (CallAdapter<ResponseT, ReturnT>) retrofit.callAdapter(returnType, annotations);
} catch (RuntimeException e) {
.......
}
}
然后办法履行到Retrofit方针的callAdapter() -> nextCallAdapter()。
适配器形式
适配器形式将一个类的接口变换为客户端等待的另一种接口，从而使原本因接口不匹配而无法在一起作业的两个类可以在一起作业。Retrofit代码中将很多的规划形式融合在一起，除了战略形式，CallAdapter中还有此形式，
