教你玩转retrofit，retrofit源码解析

2019新年将至，最近总结了一下近一段时间的技术和职业生涯。猛然发现在公司工作已经一年半了，这期间大大小小项目做了一大堆（物流、快递、零担、城配甚至还做过一个小程序）。实际上这一年半个人技术上是突飞猛进的，但是似乎并没有把这个过程中学到的技术认真做过整理。刚好年关个人时间较为充裕，因此打算对自己这一年半的总结和心得分多篇文章整理一下，一方面是为了自己巩固知识，另一方面也希望后来人看到文章能够有所帮助。

个人文风较为简单，文章也更注重过程性的东西而非丰富的扩展（想把某一个知识点发散的研究透彻那么我的文章不适合你，但是如果想画龙点睛似的将一个点搞透，那么选我没错了），技术的东西不会铺垫很多花哨的语言，同是也会尽量把文章写得通俗易懂。有不懂的地方欢迎私信我，看到必回。

文章大纲

1. retrofit使用方法
2. retrofit整体工作流程（图解）
3. 代码讲解
4. 总结

1、retrofit使用方法

如下图，retrofit使用需要我们新建一个请求接口，请求方法和参数注解的形式在接口中标注。所以首先就要获取一个接口的实例，然后用实例调用接口获得响应数据监听器实例并进行异步监听请求结果，这样一个请求就算完成了

2、retrofit整体工作流程（图解）

过程如下，简要说说其中原理

1. 手机发起请求
2. 我们通过请求接口配置的请求方法（@get、@post ...），请求参数 （@Qurey 、 @Field ...）等配置一个请求对象
3. 异步注册请求
4. 获取到结果后根据配置的ConvertFactory解析返回数据

 

3、代码讲解

首先要看看我们在接口中配置的service是如何被解析的。这要从创建Retrofit对象开始说

retrofit = Retrofit.Builder().baseUrl("http://192.168.2.1:8080")
                .addCallAdapterFactory(ApiCallAdapterFactory())
                .addConverterFactory(ApiConverterFactory())
                .build()

在这里运用了建造者模式，build（）之后retrofit同时有了请求处理工厂集合（CallAdapterFactory）和响应工厂集合（ConverterFactory）。我们的配置参数解析发生在  retrofit.create()里面，先上代码：

 public <T> T create(final Class<T> service) {
    ~~~~~~~~~~
    return (T) Proxy.newProxyInstance(service.getClassLoader(), new Class<?>[] { service },
        new InvocationHandler() {
          private final Platform platform = Platform.get();
          private final Object[] emptyArgs = new Object[0];

          @Override public Object invoke(Object proxy, Method method, @Nullable Object[] args)
              throws Throwable {
            // If the method is a method from Object then defer to normal invocation.
            if (method.getDeclaringClass() == Object.class) {
              return method.invoke(this, args);
            }
            if (platform.isDefaultMethod(method)) {
              return platform.invokeDefaultMethod(method, service, proxy, args);
            }
            return loadServiceMethod(method).invoke(args != null ? args : emptyArgs);
          }
        });
  }

这里用到了一个设计模式：java动态代理模式（动态代理不清楚的去了解一下吧），总之在这里处理了我们的注解，并且生成了请求类。下面详细讲解一下这里的部分（核心部分）

上面的代码最终通过loadServiceMethod 返回一个OkHttpCall ，它继成自retrofit2.Call，在这个call里面持有一个

okhttp3.Call rawCall，所以真实请求是用okhttp完成的，这也是为什么retrofit必须和okhttp形影不离（本文不对okhttp做扩展）。

让我们看看loadServiceMethod的代码
 

 ServiceMethod<?> loadServiceMethod(Method method) {
    ServiceMethod<?> result = serviceMethodCache.get(method);
    if (result != null) return result;

    synchronized (serviceMethodCache) {
      result = serviceMethodCache.get(method);
      if (result == null) {
        result = ServiceMethod.parseAnnotations(this, method);
        serviceMethodCache.put(method, result);
      }
    }
    return result;
  }

有用的一行代码是 result = ServiceMethod.parseAnnotations(this, method)，再来看看ServiceMethond.paresAnnotations的代码

 static <T> ServiceMethod<T> parseAnnotations(Retrofit retrofit, Method method) {
    RequestFactory requestFactory = RequestFactory.parseAnnotations(retrofit, method);

    Type returnType = method.getGenericReturnType();
    if (Utils.hasUnresolvableType(returnType)) {
      throw methodError(method,
          "Method return type must not include a type variable or wildcard: %s", returnType);
    }
    if (returnType == void.class) {
      throw methodError(method, "Service methods cannot return void.");
    }

    return HttpServiceMethod.parseAnnotations(retrofit, method, requestFactory);
  }

这里有用的一行代码是return HttpServiceMethod.parseAnnotations(retrofit, method, requestFactory)

HttpServiceMethod是ServiceMethod的实现类，

 static <ResponseT, ReturnT> HttpServiceMethod<ResponseT, ReturnT> parseAnnotations(
      Retrofit retrofit, Method method, RequestFactory requestFactory) {
    CallAdapter<ResponseT, ReturnT> callAdapter = createCallAdapter(retrofit, method);
    Type responseType = callAdapter.responseType();
    if (responseType == Response.class || responseType == okhttp3.Response.class) {
      throw methodError(method, "'"
          + Utils.getRawType(responseType).getName()
          + "' is not a valid response body type. Did you mean ResponseBody?");
    }
    if (requestFactory.httpMethod.equals("HEAD") && !Void.class.equals(responseType)) {
      throw methodError(method, "HEAD method must use Void as response type.");
    }

    Converter<ResponseBody, ResponseT> responseConverter =
        createResponseConverter(retrofit, method, responseType);

    okhttp3.Call.Factory callFactory = retrofit.callFactory;
    return new HttpServiceMethod<>(requestFactory, callFactory, callAdapter, responseConverter);
  }

CallAdapter<ResponseT, ReturnT> callAdapter = createCallAdapter(retrofit, method)和
Converter<ResponseBody, ResponseT> responseConverter =createResponseConverter(retrofit, method, responseType)

这两行代码分别获得两个工厂列表（这两个工厂列表是在构造retrofit对象的时候添加的.addCallAdapterFactory(ApiCallAdapterFactory()) .addConverterFactory(ApiConverterFactory())  ），用来查找请求参数的构造器和返回参数的解析器。

这个方法的返回值是一个HttpServiceMethod对象，这个就是我们最初看到的代理类里面调用的loadServiceMethod()方法的返回值。

代码看到这里我们再回到Retrofit.create方法InvocationHandler的回调函数里面，这里调用loadServiceMethod后得到了一个HttpServiceMethod对象，然后调用HttpServiceMethod.invoke方法：

@Override ReturnT invoke(Object[] args) {
    return callAdapter.adapt(
        new OkHttpCall<>(requestFactory, args, callFactory, responseConverter));
  }

这个方法的关键点是callAdapter这个变量，CallAdapter是个接口，他在Retrofit源码中的实现是声明在DefaultCallAdapterFactory里的一个匿名内部类。

final class DefaultCallAdapterFactory extends CallAdapter.Factory {
  static final CallAdapter.Factory INSTANCE = new DefaultCallAdapterFactory();

  @Override public @Nullable CallAdapter<?, ?> get(
      Type returnType, Annotation[] annotations, Retrofit retrofit) {
    if (getRawType(returnType) != Call.class) {
      return null;
    }

    final Type responseType = Utils.getCallResponseType(returnType);
    return new CallAdapter<Object, Call<?>>() {
      @Override public Type responseType() {
        return responseType;
      }

      @Override public Call<Object> adapt(Call<Object> call) {
        return call;
      }
    };
  }
}

到了这里我们知道了CallAdapter的来源 。当然了这不是我们最终的目的，我们最终是要看CallAdapter.adapt方法，这个方法的返回值就是Retrofit.create方法最终的返回值，也就是我们调用请求接口的时候拿到的接收结果对象（即第一张图的call）。到了这里整个retrofit的源码就说完了

总结

我的源码解析完全是按照一个正常的阅读源码顺序来的。因为retrofi使用的三种实际模式和源码中大量的使用接口，导致阅读的时候经常是跳跃式查看，过这也正是retrofit源码阅读难的原因所在。跟着我的思路相信你自己看一遍就能揭开retrofit的神秘面纱

 

实际上retrofit给我们提供了非常好的扩展性，比如CallAdapterFactory和ConvertFactory我们是完全可以自己定义的，我公司中的项目正是如此，通过自定义CallAdapterFactory你可以使用其它监听器（例：LiveData，RxJava）接口数据。大家有兴趣的可以自己深入研究一下