超详细Retrofit源码解析（二）

• 适配器模式

  上一篇文章我们已经分析了Retrofit解析注解封装进ServiceMethod的流程，读者在这里要记住，一个ServiceMethod就代表一个interface接口里的方法。相信部分读者已经忘了Retrofit的create流程，这里我们再贴一下这部分代码，然后继续分析下去。

  public <T> T create(final Class<T> service) {    Utils.validateServiceInterface(service);    if (validateEagerly) {      eagerlyValidateMethods(service);    }    return (T) Proxy.newProxyInstance(service.getClassLoader(), new Class<?>[] { service },        new InvocationHandler() {          private final Platform platform = Platform.get();          @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);            }            ServiceMethod<Object, Object> serviceMethod =                (ServiceMethod<Object, Object>) loadServiceMethod(method);            OkHttpCall<Object> okHttpCall = new OkHttpCall<>(serviceMethod, args);            return serviceMethod.callAdapter.adapt(okHttpCall);          }        });  }

  ServiceMethod初始化完毕之后，接下来需要创建Call对象。

  OkHttpCall<Object> okHttpCall = new OkHttpCall<>(serviceMethod, args);

  看到没有？这部分默认使用的是OkHttpCall，并且是写死的，用户无法自行扩展。如果你不想默认使用okhttp，那只能修改这部分代码，重新打包retrofit了。

  构造完okhttpCall对象，接下来该做什么呢？

  有了接口代理对象之后，我们就需要把http请求发送出去了。发送可以使用同步方式与异步方式。同步方式我们好理解，http请求发送出去后程序需要阻塞等待http响应的返回，这样我们自然会自己开辟子线程来执行同步请求等待结果并处理；但异步形式呢？既然是异步发送，http响应的到达一般是通过回调的形式通知的。而异步发送请求在Retrofit里面本身又是运行在子线程的，如果不经过特殊处理，回调自然也是运行在子线程。

  这么说，难道还要用户自行从子线程切换到主线程去处理回调？这也太麻烦了吧？

  想太多！！！Retrofit这么神奇的库，当然早就处理好了这种情况。还记得我们在上一篇文章里面提到的MainThreadExecutor吗？聪明的你肯定已经想起来了。是的，它就是用来执行切换操作的神器。

  既然知道有这个神器存在，接下来该怎么使用呢？默认的okhttpCall对象和MainThreadExecutor是没有任何挂钩的，okhttpCall的异步请求的实现也没有去做任何的切换操作，而我们又需要执行异步操作完毕后可以自行切换到主线程去回调，很显然，okhttpCall不能满足我们的使用场景，该怎么办呢？

  这时候就需要适配器模式来发挥作用了，把不能满足使用情形的Call适配成符合场景的另外一个Call。这个系列的文章开头就已经大致介绍了CallAdapter的作用，但还没有实际看过这个接口内部的构造，我们现在跟进去看看。

  public interface CallAdapter<R, T> {  //返回要将http响应转换到的Java对象类型，如Call<Repo>，则返回类型是Repo  Type responseType();  T adapt(Call<R> call);  abstract class Factory {    public abstract @Nullable CallAdapter<?, ?> get(Type returnType, Annotation[] annotations,        Retrofit retrofit);    protected static Type getParameterUpperBound(int index, ParameterizedType type) {      return Utils.getParameterUpperBound(index, type);    }    protected static Class<?> getRawType(Type type) {      return Utils.getRawType(type);    }  }}

  CallAdapter里面最重要的一个方法是adapt，它的作用是把传递进来的Call对象适配成符合程序需求的其他类型的对象。

  还记得上一篇文章中，在建造者模式这一节中我们分析了默认的适配器工厂的赋值吗？是的，它的默认值是ExecutorCallAdapterFactory（忘记的读者请自行异步上一篇文章回顾哦）。我们再重新温习一下ExecutorCallAdapterFactory。

  final class ExecutorCallAdapterFactory extends CallAdapter.Factory {  final Executor callbackExecutor;  ExecutorCallAdapterFactory(Executor callbackExecutor) {    this.callbackExecutor = callbackExecutor;  }  @Override  public 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 new ExecutorCallbackCall<>(callbackExecutor, call);      }    };  }  }

  ExecutorCallAdapterFactory的get方法是获取CallAdapter的入口，可以看到，get内部返回了一个匿名的callAdapter对象，实现了responseType和adapt两个方法。

  因此，Retrofit.create的serviceMethod.callAdapter.adapt(okHttpCall)最终调用的是由ExecutorCallAdapterFactory获取到的CallAdapter的adapt方法。okhttpCall最终也被适配成ExecutorCallbackCall返回。这就是Retrofit需要的Call对象。

  这里我们也关注两个点：

  1. 构造ExecutorCallbackCall对象时，传入的callbackExecutor是我们在上一篇文章分析过的MainThreadExecutor；

  2. 构造ExecutorCallbackCall对象时，传入的call是OkhttpCall；

  至于适配的其他平台，如RxJava\Java8\Guava等，我们不做展开，这里主要是梳理分析Retrofit的主要流程源码。若有较多读者有需要，可以反馈给我，后续开专栏补上。

  ---

• 装饰者模式

  创建完代理对象后，接下来就是使用代理对象来发送http请求了。发送分为同步和异步两种，对应Call接口里的execute和enqueue。我们首先分析execute流程，然后再分析enqueue流程，循序渐进。

  经过Retrofit.create方法创建的Call对象实际上是ExecutorCallbackCall对象，因此，同步、异步请求真正调用的是ExecutorCallbackCall的execute和enqueue方法。

  execute

   @Override public Response<T> execute() throws IOException {  return delegate.execute();}

  execute内部的实现非常简单，仅仅是调用了delegate的execute方法。那么delegate是什么呢？顾名思义，它是被ExecutorCallbackCall委托来执行execute操作的。我们再来看看ExecutorCallbackCall对于delegate的赋值。

  static final class ExecutorCallbackCall<T> implements Call<T> {final Executor callbackExecutor;final Call<T> delegate;ExecutorCallbackCall(Executor callbackExecutor, Call<T> delegate) {  this.callbackExecutor = callbackExecutor;  this.delegate = delegate;}...}

  有没有似曾相识的感觉？是的，我们在上文的分析中，曾经划重点指出了ExecutorCallbackCall在构造时的默认赋值，其中，callbackExecutor的默认赋值是MainThreadExecutor，delegate的默认赋值是OkhttpCall。也就是说，实际的发起同步请求的操作还是由OkhttpCall来发起的。

  将某个值通过依赖注入的形式在类内部持有其引用，之后再在类对应的方法里调用该引用的方法（前后可增加一些操作），这种模式就是装饰者模式。

  好了，现在定位到OkhttpCall的execute方法。

  @Override public Response<T> execute() throws IOException {okhttp3.Call call;synchronized (this) {  if (executed) throw new IllegalStateException("Already executed.");  executed = true;  call = rawCall;  if (call == null) {    try {      call = rawCall = createRawCall();    } catch (IOException | RuntimeException | Error e) {      creationFailure = e;      throw e;    }  }}if (canceled) {  call.cancel();}return parseResponse(call.execute());}

  Retrofit的一个请求对象只能执行一次，因此execute一开始会进行判断。通过判断之后，会对call对象赋值rawCall。rawCall一开始显然是null，所以会执行到createRawCall()来创建call对象。

   private okhttp3.Call createRawCall() throws IOException {Request request = serviceMethod.toRequest(args);okhttp3.Call call = serviceMethod.callFactory.newCall(request);if (call == null) {  throw new NullPointerException("Call.Factory returned null.");}return call;}

  Retrofit在创建ServiceMethod对象时，已经将请求的注解信息都封装进去了，这里直接调用ServiceMethod.toRequest就可以把一个接口方法转换成Request请求对象了。我们来看看ServiceMethod是如何将一个接口方法转换成Request对象的。

    Request toRequest(@Nullable Object... args) throws IOException {RequestBuilder requestBuilder = new RequestBuilder(httpMethod, baseUrl, relativeUrl, headers,    contentType, hasBody, isFormEncoded, isMultipart);ParameterHandler<Object>[] handlers = (ParameterHandler<Object>[]) parameterHandlers;int argumentCount = args != null ? args.length : 0;for (int p = 0; p < argumentCount; p++) {  handlers[p].apply(requestBuilder, args[p]);}return requestBuilder.build();}

  toRequest内部使用了RequestBuilder来封装解析的注解信息，并对每个参数注解调用其处理器的apply方法进行转换解析，最后调用RequestBuilder.build方法构造出一个Request对象。RequestBuilder就是一个Request建造器，其内部源码不复杂，读者也请自行翻阅，这里不做展开，我们的解读目标依然是Retrofit主线。

  创建出了Request对象之后，Request对象如何传输到网络上，还需要Call来实现。接下来createRawCall会执行serviceMethod.callFactory.newCall(request)。我们在上一篇文章中已经提到过，serviceMethod.callFactory实际上就是OkhttpClient，因此实际构造Call的操作是交由Okhttp来完成的（Okhtpp实际创建的是RealCall对象），本系列文章主要是探索Retrofit的源码实现，Okhttp部分的源码我们就不做深入分析了，读者有兴趣可以自行去阅读。

  到此，Call对象就已经创建出来了，其本质是Okhttp的RealCall对象，这也直接说明了Retrofit本身并不负责网络请求，而是将该功能交由okhttp来执行，很好地解除了依赖。

  Call对象创建完毕，剩下的就是以下步骤了。

  parseResponse(call.execute())

  call.execute实际就是调用Okhttp.RealCall.execute了。那么RealCall里面的execute到底做了什么呢？这里我们小小地涉足一下，浅尝辄止。

  Okhtpp.RealCall @Override public Response execute() throws IOException {synchronized (this) {  if (executed) throw new IllegalStateException("Already Executed");  executed = true;}try {  client.dispatcher().executed(this);  Response result = getResponseWithInterceptorChain(false);  if (result == null) throw new IOException("Canceled");  return result;} finally {  client.dispatcher().finished(this);}}

  相信细心的读者已经发现了。

  Response result = getResponseWithInterceptorChain(false);

  RealCall是通过上述getResponseWithInterceptorChain方法获取到了http响应的。Okhttp发起网络请求和解析网络响应的核心正是使用了责任链模式实现的，这部分源码太多，这里不做展开，读者可自行搜索相关文章查看。

  好了，现在让我们回到Retrofit。

  call.execute执行完毕以后，程序会获取到Okhttp.Response类型的http响应。而Okhttp.Response在Retrofit中是无法被识别的，因此需要将其转换成REtrofit可以识别的对象，parseResponse()就是起这个作用的。

   Response<T> parseResponse(okhttp3.Response rawResponse) throws IOException {ResponseBody rawBody = rawResponse.body();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);}ExceptionCatchingRequestBody catchingBody = new ExceptionCatchingRequestBody(rawBody);try {  T body = serviceMethod.toResponse(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;}}

  parseResponse解析出rawBody之后，调用了ServiceMethod.toResponse方法，将rawBody转换成对应的JavaBean对象。

  R toResponse(ResponseBody body) throws IOException {return responseConverter.convert(body);}

  可以看到，ServiceMethod的toResponse方法很简单，就是调用事先已经注册好的responseConverter来将rawBody对象convert成我们事先定义好的JavaBean。那么responseConverter的值各位读者还记得吗？对了，它就是我们一开始的时候注册进去的GsonConverterFactory.GsonResponseBodyConverter。

  经过以上流程，execute方法就执行完毕了。

  ---

  enqueue

  分析完同步请求execute的流程，现在我们来分析异步请求enqueue。

  call.enqueue调用的还是ExecutorCallbackCall的enqueue方法。

  ExecutorCallbackCall @Override public void enqueue(final Callback<T> callback) {  delegate.enqueue(new Callback<T>() {    @Override public void onResponse(Call<T> call, final Response<T> response) {      callbackExecutor.execute(new Runnable() {        @Override public void run() {          if (delegate.isCanceled()) {            callback.onFailure(ExecutorCallbackCall.this, new IOException("Canceled"));          } else {            callback.onResponse(ExecutorCallbackCall.this, response);          }        }      });    }    @Override public void onFailure(Call<T> call, final Throwable t) {      callbackExecutor.execute(new Runnable() {        @Override public void run() {          callback.onFailure(ExecutorCallbackCall.this, t);        }      });    }  });}

  这里的enqueue依然是交由OkhttpCall的enqueue方法来执行。我们来看看OkhttpCall的enqueue方法。

  OkhttpCall @Override public void enqueue(final Callback<T> callback) {okhttp3.Call call;Throwable failure;synchronized (this) {  if (executed) throw new IllegalStateException("Already executed.");  executed = true;  call = rawCall;  failure = creationFailure;  if (call == null && failure == null) {    try {      call = rawCall = createRawCall();    } catch (Throwable t) {      failure = creationFailure = t;    }  }}if (failure != null) {  callback.onFailure(this, failure);  return;}if (canceled) {  call.cancel();}call.enqueue(new okhttp3.Callback() {  @Override public void onResponse(okhttp3.Call call, okhttp3.Response rawResponse)      throws IOException {    Response<T> response;    try {      response = parseResponse(rawResponse);    } catch (Throwable e) {      callFailure(e);      return;    }    callSuccess(response);  }

  与execute方法的执行流程相似，首先还是会调用createRawCall()创建一个Okhttp.RealCall对象，再调用该对象的enqueue方法发起真正的http异步请求。

  OkhttpCall.enqueue方法的参数callBack是从ExecutorCallbackCall的enqueue方法传入的。当请求成功获取到响应时，OkhttpCall会执行和execute同样的解析操作：调用parseResponse，在parseResponse里面调用ServiceMethod.toResponse方法，将Okhttp.Response转换成JavaBean，最终再经由Retrofit.Response.success进行封装返回Retrofit.Response对象。

  无论成功或者失败，OkhttpCall都会通过callBack将结果进行回调。这里的回调执行的是ExecutorCallbackCall传递的callBack。

  我们再来回顾一下ExecutorCallbackCall的回调吧。

  new Callback<T>() {        @Override public void onResponse(Call<T> call, final Response<T> response) {          callbackExecutor.execute(new Runnable() {            @Override public void run() {              if (delegate.isCanceled()) {                callback.onFailure(ExecutorCallbackCall.this, new IOException("Canceled"));              } else {                callback.onResponse(ExecutorCallbackCall.this, response);              }            }          });        }        @Override public void onFailure(Call<T> call, final Throwable t) {          callbackExecutor.execute(new Runnable() {            @Override public void run() {              callback.onFailure(ExecutorCallbackCall.this, t);            }          });        }      }

  可以看到，在onResponse和onFailure里面，真正执行回调的是callbackExecutor！！！

  callbackExecutor.execute(...)

  各位，各位，这里的callbackExecutor对象还记得吗？？？

  它就是我们反复强调的MainThreadExecutor了！！！

  从这里开始，异步请求的回调就顺利地从子线程切换到了主线程。

  ---

  跋山涉水，一番探索之后，我们终于把Retrofit的源码捋顺了。希望这两篇文章对各位读者理解Retrofit的设计有所帮助，谢谢！