Retrofit 源码深入分析 —— Call 对象的诞生与请求

一、概述

Retrofit 是一个基于 OkHttp ，并遵循 Restful 风格的一个网络请求封装库，它将一个请求以接口的形式具现化的表现出来，将 OkHttp 的请求操作简化，并可以配置 convert 将响应转换为你想要的数据 model，且支持异步或同步的操作，2.6.x 版本以上更是对协程进行了支持，其优异的设计，简便的请求方式，推出没多久就在 Android 开发领域出圈，目前 github star 数量已经达到 37.8k 并被大量的 App 采用。
现如今更是成为各大公司面试的长问问题。基于此，本篇文章会从源码层面深入分析 Retrofit 的运行机制，了解 Retrofit 的内部原理。

站在巨人的肩膀上眺望，就算最终我们成不了巨人，起码也能比旁人看的更远不是。

二、Retrofit 基本流程图

Retrofit 流程图

如图所示，接下来我们就按照流程图来逐步分析 Retrofit 的源码

三、一个简单的请求

阅读源码的最好方式就是从使用的角度从调用链一步步深入分析，这样能让我们避免在繁复纷杂的代码中迷失方向，无所适从。所以让我们从一个简单的请求开始，慢慢的揭开 Retrofit 神秘的面纱。

public interface GitHub {

 @GET("/repos/{owner}/{repo}/contributors") 
 Call> contributors(@Path("owner") String owner, @Path("repo") String repo);
 
}

public static final String API_URL = "https://api.github.com";

Retrofit retrofit = new Retrofit.Builder()
                .baseUrl(API_URL)
                .addConverterFactory(GsonConverterFactory.create())
                .build();
                
 // Create an instance of our GitHub API interface.
GitHub github = retrofit.create(GitHub.class);

// Create a call instance for looking up Retrofit contributors.
Call> call = github.contributors("square", "retrofit");

// Fetch and print a list of the contributors to the library.
List contributors = call.execute().body();

for (Contributor contributor : contributors) {
  System.out.println(contributor.login + " (" + contributor.contributions + ")");
}

上述代码是 Retrofit 官方 sample 中的例子，代码并不是很多，可以看到经过一些耳熟能详的构建步骤和一个声明的 Restful 接口，就获得了一个可以进行 enqueue/sync 请求的 Call 对象，而通过这个 Call 对象我们就可以直接获取我们想要的 Response， 不得不佩服，真的是将网络请求变得非常简便。

这里我特别说明一下 build 的构建过程，有助于后面文章的理解

public Retrofit build() {
      if (baseUrl == null) {
        throw new IllegalStateException("Base URL required.");
      }

      //第一步创建一个 OkHttpClient 对象
      okhttp3.Call.Factory callFactory = this.callFactory;
      if (callFactory == null) {
        callFactory = new OkHttpClient();
      }

      //第二步创建一个回调线程 ，Platform 是在 Builder 构造方法中进行的实例化并传入
      //主要作用判断当前的运行环境，如果是 Android 则返回 AndroidCallback
      Executor callbackExecutor = this.callbackExecutor;
      if (callbackExecutor == null) {
        callbackExecutor = platform.defaultCallbackExecutor();
      }

      // 第三步将所有的 CallAdapter add 到 callAdapterFactories 集合中
      //例如常用的 RxJavaCallAdapterFactory
      List callAdapterFactories = new ArrayList<>(this.callAdapterFactories);
      callAdapterFactories.addAll(platform.defaultCallAdapterFactories(callbackExecutor));

      // 第四步将所有的 Converter add 到 converterFactories 集合中
      //列如我们常用的 GsonConvertFactory
      List converterFactories = new ArrayList<>(
          1 + this.converterFactories.size() + platform.defaultConverterFactoriesSize());

      //添加 Retrofit 默认提供的 converter ，当我们的返回类型为 Call 就会使用这个 BuiltInConverters
      converterFactories.add(new BuiltInConverters());
      converterFactories.addAll(this.converterFactories);
      converterFactories.addAll(platform.defaultConverterFactories());

      //创建 Retrofit 实例
      return new Retrofit(callFactory, baseUrl, unmodifiableList(converterFactories),
          unmodifiableList(callAdapterFactories), callbackExecutor, validateEagerly);
    }

说实话，前几年第一次看到这种网络请求的方式的时候，感觉还是蛮秀的，竟然还能这么玩？ 在使用了一段时间后，非常好奇它是怎做到的，相信有不少童鞋应该也很好奇吧。接下来我们慢慢看看这么神奇的操作是怎么完成的~

四、Retrofit 的 create 方法

在进行分析之前，如果你对 Java 动态代理、反射、注解没什么了解的话，建议先简单的了解一下，否则可能无法愉快的阅读后续的文章。

public  T create(final Class service) {
    //校验接口是否可用
    validateServiceInterface(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 @Nullable Object invoke(Object proxy, Method method,
              @Nullable Object[] args) throws Throwable {
            // 调用的是成员类方法
            if (method.getDeclaringClass() == Object.class) {
              return method.invoke(this, args);
            }
            //调用的是 Object 的默认方法
            if (platform.isDefaultMethod(method)) {
              return platform.invokeDefaultMethod(method, service, proxy, args);
            }
            //将解析的请求组装成一个 Call 对象返回
            return loadServiceMethod(method).invoke(args != null ? args : emptyArgs);
          }
        });
  }

create 方法接收一个 Class 类型的形参，内部通过动态代理的方式，在运行时创建了 Github Api 的接口实现类，在调用接口方法时，代理类会执行 InvocationHandler 的 invoke 方法，而在 invoke 方法中我们就可以对 Github 接口中声明的方法进行一些我们想做的改动了。

可能说到这里，还是有点绕，其实简而言之，这个 invoke 方法有点相当一个方法拦截器，可以在调用实际的方法前植入一些前期操作，比如当我们调用下面的代码时

Call> call = github.contributors("square", "retrofit");

此时在执行 contributors 方法时，会先调用 InvocationHandler 的 invoke方法，在这个方法中，Retrofit 会对方法中的注解通过反射进行解析，其中会解析形参类型，返回类型等等，并将其组装成一个 Call 对象返回。其实如果你对 Java 的 AOP 有过了解的话，那么这里的思想也是一样的。

动态代理相关内容就先解释到这里，接下来我们来重点看看 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;
  }

loadServiceMethod 做的事情并不复杂，就是判断方法签名是否缓存过，没有则解析方法中的所有注解，并加入缓存,代码如下

abstract class ServiceMethod {
  static  ServiceMethod parseAnnotations(Retrofit retrofit, Method method) {
    //解析接口方法中的所有注解并组装成一个请求工厂
    RequestFactory requestFactory = RequestFactory.parseAnnotations(retrofit, method);

    //获取接口方法的返回类型
    Type returnType = method.getGenericReturnType();
    
    //省略一些判断代码...
    
                   //这里对各种参数进行检查，并拼装成一个 CallAdapted 对象
    return HttpServiceMethod.parseAnnotations(retrofit, method, requestFactory);
  }

  abstract @Nullable T invoke(Object[] args);
}

从上面的代码中我们了解到，ServiceMethod 是一个抽象类，内部声明了一个静态的泛型方法 parseAnnotations ，其中通过 RequestFactory 的静态 parseAnnotations 方法解析方法中的所有注解，通过 HttpServiceMethod 的静态 parseAnnotations 方法将解析的各种参数拼装成一个 CallAdapted 对象返回。

这里说明一下
HttpServiceMethod 也是个抽象类并继承自 ServiceMethod 类且实现了 invoke 方法。

简单的了解了上面的代码，接下来我们在逐一看看 RequestFactory.parseAnnotations 和 HttpServiceMethod.parseAnnotations 为我们做了什么

五、Request 的参数解析过程

RequestFactory.parseAnnotations 方法在将 retrofit 对象和 method 传入后，会创建一个 Builder 对象，主要作用就是赋值，如下

static RequestFactory parseAnnotations(Retrofit retrofit, Method method) {
    return new Builder(retrofit, method).build();
}

Builder(Retrofit retrofit, Method method) {
      this.retrofit = retrofit;
      this.method = method;
      this.methodAnnotations = method.getAnnotations();//方法的注解数组
      this.parameterTypes = method.getGenericParameterTypes();//形参的类型数组
      this.parameterAnnotationsArray = method.getParameterAnnotations();//形参的注解数组
}

而具体的解析则在 build 方法中进行，这里在特别说明一下，我们知道 Retrofit 主要通过注解来解释一个接口信息，这里我将 Retrofit 常用的的注解分为两大类，一种是针对方法修饰，一种是针对参数进行修饰，具体信息如下

method	parameter
GET	Url
POST	Path
HEAD	Query
PATCH	QueryName
PUT	QueryMap
OPTIONS	Header
HTTP	HeaderMap
Headers	Field
Multipart	FieldMap
FormUrlEncoded	Part
-	PartMap
-	Body
-	tag

知道了区别，我们来看一下 RequestFactory 的结构图以及解析的流程图。

解析流程图

可以看到解析的过程主要由两个主要方法构成，一个是 parseMethodAnnotation， 负责解析请求方法和 Header , 代码很简单就不贴了，这里我们重点看一下 parseParameterAnnotation 方法，流程图中写的很清楚，它的主要作用就是将解析的形参注解生成一个 ParameterHandler对象返回，那么这个 ParameterHandler 能做些什么呢 ？ 来看看它的结构

ParameteHandler 继承关系

可以看到 ParameterHandler 的子类共有 15 个，且与上述的参数注解一一对应，其内部有一个抽象方法 apply, 两个默认方法 iterable、array、其中前者主要解析的是集合数据，后者主要针对数组的解析，但它们最终还是会调的是由各个子类实现的 apply 方法来将解析的键值对或 body 添加到我们的 request 中。

代码形式如下

abstract class ParameterHandler {
  abstract void apply(RequestBuilder builder, @Nullable T value) throws IOException;

  final ParameterHandler> iterable() {
    return new ParameterHandler>() {
      @Override void apply(RequestBuilder builder, @Nullable Iterable values)
          throws IOException {
        if (values == null) return; // Skip null values.

        for (T value : values) {
          ParameterHandler.this.apply(builder, value);
        }
      }
    };
  }

  final ParameterHandler