透过Retrofit使用看其源码设计模式

最新推荐文章于 2023-03-09 22:42:21 发布
置顶 最新推荐文章于 2023-03-09 22:42:21 发布
阅读量5k 收藏 5
点赞数 3
分类专栏： Android 文章标签： 设计模式 源码 Retrofit
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/huyongl1989/article/details/52829822
版权

欢迎访问我的个人独立博客 ittiger.cn，原创文章，未经允许不得随意转载。

前言

这篇文章我将从Retrofit的基本用法出发，透过其使用步骤，一步步的探究Retrofit的实现原理及其源码的设计模式。这篇文章可能会将Retrofit中用到的设计模式和其实现原理穿插着写，所以各位同学也可以选择性的阅读。而对于Retrofit具体使用还不太清楚的同学可以去看的另一篇文章Retrofit2的使用介绍

Retrofit基本用法

我以用户登录作为示例：

声明接口

首先我们先定义一个登录服务接口LoginService，如下：

public interface LoginService {
    @FormUrlEncoded
    @POST("login")
    Call<String> login(@Field("username") String name, @Field("password") String password);
}

创建Retrofit对象

Retrofit retrofit = new Retrofit.Builder()
    .baseUrl("http://ittiger.cn")
    .addConverterFactory(GsonConverterFactory.create())
    .build();

发起请求

LoginService service = retrofit.create(LoginService.class);
Call<User> call = service.login("user", "pwd");
call.execute()或call.enqueue()

Retrofit关键类

在讲Retrofit实现原理之前，我先说下Retrofit里面涉及到几个关键类都是干什么用的

  1. Retorift： 负责配置请求过程中的基本参数，如：请求地址，结果转换器，自定义OKHttpClient等，同时还会生成请求接口对象
  2. Call： 网络请求执行者(Retrofit.Call)，比如：上面示例中最后调用login方法得到的Call对象就是此接口的实例
  3. OkHttpCall： 此类是Retrofit.Call接口的实现，示例中最后调用login方法得到的Call对象就是此类的实例。但是其底层网络请求执行都是通过OkHttp.Call接口间接执行的，也就是说OkHttpCall是对OkHttp.Call网络请求功能的封装。
  4. Converter & Converter.Factory： 分别负责网络请求结果转换以及生成Converter转换器
  5. CallAdapter & CallAdapter.Factory： 分别负责对Retrofit.Call实例(OkHttpCall)进行适配及生成CallAdapter适配器
  6. Platform： 确定Retrofit当前运行平台，以及确定当前平台默认的的CallAdapter.Factory和Executor
  7. ExecutorCallAdapterFactory： Android平台下的默认CallAdapter.Factory实现
  8. ServiceMethod： 解析接口服务所有注解、生成请求对象Request、解析请求结果Response
  9. ParameterHandler： 服务接口方法(login())参数解析处理器，配合ServiceMethod进行服务接口参数注解解析
  10. RequestBuilder： 根据参数和URL构造请求需要的OkHttp.Request对象

以上就是Retrofit源码实现中比较关键的10个类及其相关作用

使用流程 >> 实现 >> 设计模式

Builder模式创建Retrofit

Retrofit场景

Retrofit retrofit = new Retrofit.Builder()
    .baseUrl("http://ittiger.cn")
    .addConverterFactory(GsonConverterFactory.create())
    .build();

上面代码的对象创建方式看着是不是似曾相识，看着很眼熟，没错，Android里面的Dialog的创建就是使用的这种方式：Builder模式

Builder模式定义

将一个复杂对象的构建与它的表示分离，使得同样的构建可以创建不同的表示

Builder模式使用场景

  1. 相同的方法不同的执行顺序产生不同的结果
  2. 多个部件都可以装配到一个对象中，但是产生的结果不同

Builder模式类图

这里写图片描述

Retrofit中的Builder模式

  1. Retrofit中的Builder模式是简化版的Builder模式，省略了抽象建造者和指挥者
  2. 不同的配置会对Retrofit产生不同的影响，如果通过addCallAdapterFactory()配置CallAdapterFactory和不配置CallAdapterFactory会对Retrofit产生完全不同的影响。
  3. 如果Retrofit中使用构造方法的方式创建对象，则需要实现多个不同参数的构造方法，而使用构造方法创建对象时如果参数太多，很多时候参数代表的意思是不太理解的，总归来说就是创建过程不直观。

Builder模式优缺点

  • 优点：
    1. 不需要知道产品内部的组成细节，产品与创建过程解耦
    2. 分步组装产品，使得产品的创建过程更精细更清晰
    3. 容易扩展，新产品只需要新建一个建造者即可
  • 缺点：
    1. Builder模式创建的产品差异性小，使用范围受限制
    2. 不同的产品会产生多个建造者和指挥者

Retrofit创建流程 >> Platform

在创建Retrofit过程中有这样一行代码：

Retrofit retrofit = new Retrofit.Builder()
...
.build();

从代码可以看到在创建Retrofit时得先根据Retrofit.Builder内部类的默认构造方法Retrofit.Builder()创建一个Builder对象，所以我们来看看这个默认构造方法里都做了些什么事：

public Builder() {
  this(Platform.get());
}

OK，我们再来看看我们前面说到的Platform这个平台类的静态方法get()

//静态实例对象，类加载就确定了
private static final Platform PLATFORM = findPlatform();

  static Platform get() {
    return PLATFORM;
  }

  private static Platform findPlatform() {
    try {
      Class.forName("android.os.Build");
      if (Build.VERSION.SDK_INT != 0) {
        return new Android();
      }
    } catch (ClassNotFoundException ignored) {
    }
    try {
      Class.forName("java.util.Optional");
      return new Java8();
    } catch (ClassNotFoundException ignored) {
    }
    try {
      Class.forName("org.robovm.apple.foundation.NSObject");
      return new IOS();
    } catch (ClassNotFoundException ignored) {
    }
    return new Platform();
  }
  ...
}

通过上面的代码我们可以很明确的知道，在Platform类加载的时候它就通过反射的机制确定了当前运行的平台是属于哪一个，是Android，是Java8还是IOS，并生成对应的平台类的实例，get()方法是用来获取当前的平台类的实例。

目前，我们只关注Android平台下的Platform实例，我们也来看看Android平台类中做了些什么：

static class Android extends Platform {
    @Override public Executor defaultCallbackExecutor() {
      return new MainThreadExecutor();
    }

    @Override CallAdapter.Factory defaultCallAdapterFactory(Executor callbackExecutor) {
      return new ExecutorCallAdapterFactory(callbackExecutor);
    }

    static class MainThreadExecutor implements Executor {
      private final Handler handler = new Handler(Looper.getMainLooper());

      @Override public void execute(Runnable r) {
        handler.post(r);
      }
    }
  }

可以看到Android类中重写了Platform类的两个方法defaultCallbackExecutor()和defaultCallAdapterFactory(Executor callbackExecutor)

  1. 前者就是用来返回当前平台下默认的Executor，这Android平台下就是MainThreadExecutor这个类的实例，可以看到这个执行器主要就是用来进行线程切换的，因为我们知道安卓平台下所有的UI操作都必须在UI线程中执行。
  2. 后者就是用来返回当前平台下默认的CallAdapter.Factory
  3. 当然你也可以不使用这两个默认值，都可以在创建Retrofit过程中自定义配置自己需要的相关实例

Retrofit创建流程 >> ExecutorCallAdapterFactory

看完Platform之后紧接着我们再来看看Android平台下默认的CallAdapter.Factory实现ExecutorCallAdapterFactory都做了些什么，这里只贴关键代码：

public interface CallAdapter<T> {
	abstract class Factory {
	    public abstract CallAdapter<?> get(Type returnType, Annotation[] annotations,
	        Retrofit retrofit);
	    ...
	}
}

final class ExecutorCallAdapterFactory extends CallAdapter.Factory {
  final Executor callbackExecutor;//对应默认的MainThreadExecutor

  ExecutorCallAdapterFactory(Executor callbackExecutor) {
    this.callbackExecutor = callbackExecutor;
  }

  @Override
  public CallAdapter<Call<?>> get(Type returnType, Annotation[] annotations, Retrofit retrofit) {
    ...
    return new CallAdapter<Call<?>>() {
      @Override public Type responseType() {
        return responseType;
      }

      @Override public <R> Call<R> adapt(Call<R> call) {
        return new ExecutorCallbackCall<>(callbackExecutor, call);
      }
    };
  }
  ...
}

大家看源码可以发现CallAdapter.Factory工厂是通过get()方法来创建CallAdapter的，所以ExecutorCallAdapterFactory关键代码也是在get()方法的实现上，上面的代码中我们可以看到get()方法返回一个CallAdapter实例，这就是我前面介绍关键类作用时说到的CallAdapter.Factory主要负责生成CallAdapter的实现。

该类中，我们从其类的命名以及代码实现结构上来看，ExecutorCallAdapterFactory其实也使用了一种设计模式，那就是工厂方法模式，其实Retrofit中还有一个地方也使用了工厂方法模式，那就是Converter & Converter.Factory它的实现方式和CallAdapter & CallAdapter.Factory是一样样的。

工厂方式模式(创建CallAdapter & Converter)

本文我就已CallAdapter进行举例，看懂CallAdapter的创建原理之后，再看Converter的创建也就比较简单，都是一样的道理。

Retrofit场景

Retrofit中使用工厂方式模式的场景我在前面讲ExecutorCallAdapterFactory实现的时候已经讲过了，这里就不重复举例了，大家可以对照着源码看下。

工厂方法模式定义

一个用于创建对象的接口，让子类决定实例化哪个类

工厂方法模式使用场景

  1. 不需要知道其具体的类名，只需要知道生成它的工厂
  2. 一个类通过其子类来决定创建哪个对象

工厂方法模式类图

这里写图片描述

Retrofit中的工厂方法

  1. Retrofit中使用工厂方法模式可以讲CallAdapter的创建与具体实现充分解耦，对于创建我们只需要知道其工厂即可，不需要关注是如何实现
  2. 所以我们可以通过addCallAdapterFactory()和addConverterFactory()很方便的自定义我们自己所需要的适配器工厂和数据转换工厂
  3. 通过addCallAdapterFactory()可以很方便的让Retrofit支持RxJava特性，而通过addConverterFactory()可以自定义配置们想要的转换器，让我们可以将请求数据结果转换成我们想要的任意类型。

这些就是Retrofit使用工厂方法模式带来的好处。

工厂方法模式优缺点

  • 优点
    1. 只关注产品工厂即可，不需要关注产品如何创建，由工厂确定如何创建
    2. 扩展性好，新增产品时，只需要新增一个具体工厂和具体产品
  • 缺点
    1. 新增产品时，需要新增具体工厂和具体产品类，使系统变得庞大
    2. 系统中加入抽象层，增加了系统的抽象性和理解难度

适配器模式 >> CallAdapter

Retrofit场景

先来看看CallAdapter在Retrofit中的使用场景

public interface CallAdapter<T> {
	public Type responseType();

    public <R> Call<R> adapt(Call<R> call);
}

//ExecutorCallAdapterFactory中生成CallAdapter实例
return new CallAdapter<Call<?>>() {
      @Override public Type responseType() {
        return responseType;
      }

      @Override public <R> Call<R> adapt(Call<R> call) {
        return new ExecutorCallbackCall<>(callbackExecutor, call);
      }
    };

前面讲到ExecutorCallAdapterFactory会生成一个CallAdapter实例。而CallAdapter这个名字看着是不是也很眼熟，也有种似曾相识的感觉，没错，CallAdapter与我们在Android中使用ListView或RecyclerView时经常用到的各种Adapter一样也是一个适配器。

那CallAdapter是来适配什么的呢？

还记得前面介绍关键类的时候说到的OkHttpCall吗？CallAdapter就是来适配OkHttpCall实例的，结合上面的代码来说的话在调用CallAdapter.adapt方法时OkHttpCall实例会作为参数传递给adapt方法从而交给CallAdapter去进行适配。

在我前面举的登录示例中，我们调用login()方法得到的Call实例就是CallAdapter适配OkHttpCall之后得到的一个新Call实例对象，至于为什么是这样，我后面会一一讲解，各位看官不要离开

所以Retrofit在这个地方又使用了一种设计模式：适配器模式

适配器模式定义

将一个类的接口变成客户端所需要的另一个接口，从而使原本因接口不匹配而无法一起工作的两个类可以在一起工作

适配器模式使用场景

  1. 需要复用现有类，而现有类不符合系统需求
  2. 需要一个统一的输出接口，而输入端类型不可预知

适配器模式类图

这里写图片描述

Retrofit中的适配器模式

//ExecutorCallAdapterFactory中生成CallAdapter实例
return new CallAdapter<Call<?>>() {
      @Override public Type responseType() {
        return responseType;
      }

      @Override public <R> Call<R> adapt(Call<R> call) {
        return new ExecutorCallbackCall<>(callbackExecutor, call);
      }
    };

Android平台下默认的CallAdapter会将OkHttpCall 和 MainThreadExecutor两个实例对象适配成一个新的Call实例，这个新的Call实例在执行过程中就具备了切换到UI线程的功能。

那Retrofit在这个地方为什么要使用适配器模式将OkHttpCall进行适配了，直接拿过来用不就可以了吗？

前面讲过OkHttpCall仅仅只是对OkHttp.Call执行网络请求操作的封装，没有其他功能，也就是说OkHttpCall也只有网络请求的功能，而Retrofit是支持多个平台的（安卓，Java8，IOS，甚至包括支持RxJava特性），而不同的平台可能具有不同的特性。

如果在请求过程中需要用到这些特性的话，那么单靠OkHttp.Call是无法完成的，而如果在其他地方柔和进这些特性的支持可能就会使得框架结构不那么严谨平台解耦性比较差，甚至有可能会增加更多的接口。

Retrofit通过使用适配器模式将平台特性与OkHttpCall适配成一个最终我们需要的Call实例，这样的话我们在使用过程中只需要关注最后拿到的Call对象，而不需要关注底层这个Call实例到底是什么样的，这也就为我们支持更多的特性提供了可能。比如对RxJava特性的支持，我们只需要提供一个支持RxJava特性的CallAdapter适配器即可，所以我们就可以通过addCallAdapterFactory()配置我们提供的支持RxJava特性的CallAdapter.Factory

适配器模式优缺点

  • 优点
    1. 复用性好，引入适配器类来重用适配者类，无需修改原有代码
    2. 增加类的透明性，将适配过程封装在适配器类中，对使用者来说相对透明
    3. 灵活性扩展性好，通过配置可以随时更换适配器
  • 缺点
    1. 使用适配器会使系统整体不好把握，调的是A接口，却被适配成了B接口的实现

静态代理模式 >> ExecutorCallbackCall

Retrofit场景

还是先来看看Retrofit中使用ExecutorCallbackCall的场景

//ExecutorCallAdapterFactory中生成CallAdapter实例
return new CallAdapter<Call<?>>() {
      ...
      @Override public <R> Call<R> adapt(Call<R> call) {
        return new ExecutorCallbackCall<>(callbackExecutor, call);
      }
    };

在上面CallAdapter实现中，可以发现它将OkHttpCall适配成了一个新的Call实例：ExecutorCallbackCall，所以我们接着看看ExecutorCallbackCall的具体实现代码

static final class ExecutorCallbackCall<T> implements Call<T> {
    final Executor callbackExecutor;//Android平台下的Executor：MainThreadExecutor
    final Call<T> delegate;//网络实际执行者OkHttpCall实例

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

    @Override public void enqueue(final Callback<T> callback) {
      if (callback == null) throw new NullPointerException("callback == null");

      delegate.enqueue(new Callback<T>() {
        @Override public void onResponse(Call<T> call, final Response<T> response) {
          //Android平台下此处进行了线程切换
          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) {
          //Android平台下此处进行了线程切换
          callbackExecutor.execute(new Runnable() {
            @Override public void run() {
              callback.onFailure(ExecutorCallbackCall.this, t);
            }
          });
        }
      });
    }

    @Override public boolean isExecuted() {
      return delegate.isExecuted();
    }

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

    @Override public void cancel() {
      delegate.cancel();
    }

    @Override public boolean isCanceled() {
      return delegate.isCanceled();
    }

    @SuppressWarnings("CloneDoesntCallSuperClone") // Performing deep clone.
    @Override public Call<T> clone() {
      return new ExecutorCallbackCall<>(callbackExecutor, delegate.clone());
    }

    @Override public Request request() {
      return delegate.request();
    }
  }
}

可以看到我们通过login()方法拿到Call实例(也就是ExecutorCallbackCall)之后，在执行网络请求时，在ExecutorCallbackCall的实现中其实都是将具体操作委托给OkHttpCall在执行。所以Retrofit在ExecutorCallbackCall中又使用了一种设计模式：静态代理模式

静态代理模式定义

为其他对象提供一种代理以控制对这个对象的访问

静态代理模式使用场景

无法访问或不想直接访问某个对象

静态代理模式类图

这里写图片描述

Retrofit中的静态代理

Retrofit中使用ExecutorCallbackCall代理OkHttpCall具体请求操作，可以将Call的使用与底层实现进行解耦，不用关心底层具体请求接口的实现，所以如果将来出现了一个比OkHttp更好的网络请求库，我们完全可以将OkHttp替换掉，即便这样也不会影响外部API接口在项目中的使用。

静态代理的优缺点

  • 优点
    1. 协调调用者与被调用者，降低系统耦合度
    2. 减小外部接口与内部接口实现的关联，降低耦合
  • 缺点
    1. 委托对象与代理对象需要实现相同的接口，当接口类增加方法时，除了所有实现类需要增加该方法外，所有代理类也需要实现此方法，增加了维护难度
    2. 一个代理类只能代理一种类型的对象

动态代理 >> Retrofit.create()

先看下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();
      @Override 
      public Object invoke(Object proxy, Method method, Object... args)
          throws Throwable {
        ...
        ServiceMethod serviceMethod = loadServiceMethod(method);
        OkHttpCall okHttpCall = new OkHttpCall<>(serviceMethod, args);
        return serviceMethod.callAdapter.adapt(okHttpCall);
      }
    });
}

相信很多人在刚开始用Retrofit时都会有一点疑问，我们明明声明的是接口，为什么通过create()方法就能创建出一个对象实例呢？
通过上面的实现源码我们找到了答案，那就是使用了JDK中提供的动态代理机制，它会在运行过程中为我们声明的服务接口动态的创建出一个代理对象，以便实现我们的请求操作。我个人认为这是Retrofit框架得以实现的一个核心之处，另外一个核心之处就是其完善的注解机制，关于其注解本文就不说，主要就是一些注解的声明和解析，比较简单，感兴趣的可以去看看。

上面的源码中我们可以看到，运行过程中得到服务接口的代理对象之后，当我们调用login()这样的接口方法时，其实真实执行的是上面源码中写的invoke()方法，所以我们调用login()方法时其实是执行了如下三步：

  1. 根据反射得到接口方法Method对象生成对应的ServiceMethod对象，该对象会对该声明方法上的所有方法注解、参数注解进行解析以得到一个请求所需要的所有信息
  2. 得到ServiceMethod对象之后，会根据该对象和方法调用时传递的参数生成OkHttpCall对象，也就是具体的网络实施者
  3. 将OkHttpCall作为CallAdapter适配器中adapt()方法的参数传递给CallAdapter进行适配，最后得到我们所需要的ExecutorCallbackCall对象，也就是调用login()方法得到的Call实例对象

动态代理使用场景

静态代理特点一个代理对应一种类型，如果有多个类需要代理则需要多个代理，而且维护成本高，而动态代理就是来解决此类问题

动态代理特点

运行期由JVM通过反射机制动态生成，可以代理多种类型，代码复用性高。但是只能代理Java接口，不能代理Java实现类。

Call.enqueue() & Call.execute()实现

前面从Retrofit的配置、创建、调用接口方法得到Call实例，基本用法都已经讲的差不多了，现在我们来看基本用法的最后一步Call.enqueue() & Call.execute()

前面讲过调用接口方法比如login()时，Android平台下默认得到的是ExecutorCallbackCall实例，而ExecutorCallbackCall实例中执行网络请求的实际上又是OkHttpCall，所以我们来看OkHttpCall中的Call.enqueue() & Call.execute()两个方法的实现，我以Call.enqueue()为例，另外一个大家可以自己去看看

下面是该方法实现的关键代码：

OkHttpCall.enqueue()

@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 {
	      //如果okhttp3.Call为空，则先创建该实例
          call = rawCall = createRawCall();
        } catch (Throwable t) {
          failure = creationFailure = t;
        }
      }
    }
	...
	//又讲网络执行转交给okhttp3.Call实例来执行
    call.enqueue(new okhttp3.Callback() {
      @Override public void onResponse(okhttp3.Call call, okhttp3.Response rawResponse)
          throws IOException {
        Response<T> response;
        try {
	      //将okhttp3.Response结果包装成Retrofit中的结果对象Response
          response = parseResponse(rawResponse);
        } catch (Throwable e) {
          callFailure(e);
          return;
        }
        callSuccess(response);
      }

      @Override public void onFailure(okhttp3.Call call, IOException e) {
        ...
      }

      private void callFailure(Throwable e) {
        ...
      }

      private void callSuccess(Response<T> response) {
        ...
      }
    });
  }

前面介绍关键类时说过OkHttpCall底层网络执行其实是OkHttp.Call在执行，从上面的代码我们就可以看出来(代码关键地方我加了注释)，上面代码关键第一步是先创建一个okhttp3.call实例，所以我们同样看看创建okhttp3.call实例的代码是怎么实现的

private okhttp3.Call createRawCall() throws IOException {
    Request request = serviceMethod.toRequest(args);
    okhttp3.Call call = serviceMethod.callFactory.newCall(request);
    ...
    return call;
  }

通过上面的createRawCall()方法实现我们可以发现，它会首先通过ServiceMethod.toRequest()方法生成一个OkHttp.Request对象(这部分代码比较简单，我就不细说了)，然后根据ServiceMethod中的成员变量CallFactory创建一个okhttp3.Call实例。但是这个CallFactory是怎么来的呢？其实我们可以猜到这个CallFactory实例就是OkHttpClient实例。但是我们还是看看ServiceMethod的创建过程

ServiceMethod创建

//在Retrofit.create()方法实现的第一步就是通过loadServiceMethod()方法创建ServiceMethod，这是其实现
ServiceMethod loadServiceMethod(Method method) {
    ServiceMethod result;
    synchronized (serviceMethodCache) {
      result = serviceMethodCache.get(method);
      if (result == null) {
        result = new ServiceMethod.Builder(this, method).build();
        serviceMethodCache.put(method, result);
      }
    }
    return result;
  }

//下面是ServiceMethod相关关键代码
final class ServiceMethod<T> {
	final okhttp3.Call.Factory callFactory;
	ServiceMethod(Builder<T> builder) {
	    this.callFactory = builder.retrofit.callFactory();
	    this.callAdapter = builder.callAdapter;
	    this.baseUrl = builder.retrofit.baseUrl();
	    this.responseConverter = builder.responseConverter;
	    ...
	  }
	
	static final class Builder {
		public Builder(Retrofit retrofit, Method method) {
	      this.retrofit = retrofit;
	      this.method = method;
	      ...
	    }
		public ServiceMethod build() {
			  //创建CallAdapter
		      callAdapter = createCallAdapter();
		      //得到请求结果返回类型，接口方法声明
		      responseType = callAdapter.responseType();
		      ...
		      //创建得到Converter结果转换器
		      responseConverter = createResponseConverter();
		      ...
		      return new ServiceMethod<>(this);
		}
	}
}

通过上面的ServiceMethod创建过程的相关代码可以看出，ServiceMethod中的实例变量callFactory其实是调用Retrofit.callFactory()方法所得，大家也可以看看上面我注释的CallAdapter和Converter的创建过程，所以我们再来看看这个方法的实现

public okhttp3.Call.Factory callFactory() {
    return callFactory;
}

可以看到该方法只是返回了Retrofit中的callFactory实例，同样，我们再来看看Retrofit中的callFactory实例是怎么来的

public final class Retrofit {
	private final okhttp3.Call.Factory callFactory;
	...
	
	Retrofit(okhttp3.Call.Factory callFactory, ...) {
	    this.callFactory = callFactory;
	    ...
    }
	
	public static final class Builder {
		private okhttp3.Call.Factory callFactory;
		...
		public Builder client(OkHttpClient client) {
	      return callFactory(checkNotNull(client, "client == null"));
	    }
	    
	    public Builder callFactory(okhttp3.Call.Factory factory) {
	      this.callFactory = checkNotNull(factory, "factory == null");
	      return this;
	    }
		
		public Retrofit build() {
	      ...
	      okhttp3.Call.Factory callFactory = this.callFactory;
	      if (callFactory == null) {
	        callFactory = new OkHttpClient();
	      }
		  ...
	      return new Retrofit(callFactory, ...);
	    }
	}
}

通过上面的代码，我们可以看出Retrofit中的callFactory实例就是我们使用的OkHttpClient实例，所以这就验证了我们前面猜测的serviceMethod.callFactory就是OkHttpClient实例的猜想。

Ok，回到我们前面将的OkHttpCall.equeue()方法的实现流程上来。

请求结果解析

call.enqueue(new okhttp3.Callback() {
      @Override public void onResponse(okhttp3.Call call, okhttp3.Response rawResponse)
          throws IOException {
        Response<T> response;
        try {
	      //将okhttp3.Response结果包装成Retrofit中的结果对象Response
          response = parseResponse(rawResponse);
        } catch (Throwable e) {
          callFailure(e);
          return;
        }
        callSuccess(response);
      }
      ...
}

创建完okhttp3.call实例之后，调用该实现的equeue()方法开始执行网络请求，请求执行完成之后，会调用parseResponse方法，我们来看看这个方法实现的关键代码：

Response<T> parseResponse(okhttp3.Response rawResponse) throws IOException {
    ResponseBody rawBody = rawResponse.body();
	...
	//上面省略的这段代码是对请求失败时的结果处理，大家可以自行查看源码
	
    ExceptionCatchingRequestBody catchingBody = new ExceptionCatchingRequestBody(rawBody);
    try {
      T body = serviceMethod.toResponse(catchingBody);
      return Response.success(body, rawResponse);
    } catch (RuntimeException e) {
      catchingBody.throwIfCaught();
      throw e;
    }
  }

这个方法中，当请求成功时，会调用serviceMethod.toResponse()这个方法，我们来看看这个方法又做了哪些事情：

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

很明显，上面方法中就直接调用了ServiceMethod中的Converter实例进行结果转换，也就是说在这个地方Retrofit会帮我们把网络请求结果转换成我们所需要的类型，转换成功之后会调用Response.success(body, rawResponse)将转换后的结果包装成Retrofit中的Response对象。

获取配置的Converter

问题又来了，上面的Converter是怎么来的呢？

在前面给出的ServiceMethod创建过程的代码块中，我对ServiceMethod中创建Converter实例的代码进行了注释，我们再回过头来看看这段代码：

//ServiceMethod.Buibler中的方法
private Converter<ResponseBody, T> createResponseConverter() {
	  ...
      try {
        return retrofit.responseBodyConverter(responseType, annotations);
      } catch (RuntimeException e) { // Wide exception range because factories are user code.
        throw methodError(e, "Unable to create converter for %s", responseType);
      }
    }

//Retrofit中的方法
public <T> Converter<ResponseBody, T> responseBodyConverter(Type type, Annotation[] annotations) {
    return nextResponseBodyConverter(null, type, annotations);
  }

public <T> Converter<ResponseBody, T> nextResponseBodyConverter(Converter.Factory skipPast,
      Type type, Annotation[] annotations) {
	...
    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) {
        return (Converter<ResponseBody, T>) converter;
      }
    }
    ...
    throw new IllegalArgumentException(builder.toString());
  }

通过上面的代码我们可以看到会从Retrofit的converterFactories转换器工厂集合中去查找当前接口方法对应的转换器工厂。其实这也告诉我们可以在创建Retrofit时配置多个Converter.Factory转换器工厂，也就是说我们一个接口服务中如果声明的多个接口方法的返回值不一样时，我们可以针对性的配置多个不一样的结果转换器工厂去进行结果解析，而不用为了保持结果类型一致对接口进行其他处理。

上面创建ServiceMethod时得到CallAdapter的过程与得到Converter的过程基本一样，我就不赘述了。

到这里，Retrofit的实现原理、实现流程以及其源码实现过程中用到的设计模式就介绍完了。

内容好长，时间好长~~~~

欢迎访问我的独立博客：http://ittiger.cn

下面是我的个人公众号，欢迎关注交流

老胡 - laohu
关注
  • 3
    点赞
  • 踩
  • 5
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
retrofit简单使用
10-27
实现retrofit的基础使用，如GET，POST请求，JSON解析，例子是获取歌曲，并且播放，其他歌曲内容省略，原理是一样不多做解析，适用于retrofit初学者。
Android Retrofit里的设计模式
木寸~
06-18 1417
一、Retrofit三步走 1、创建Bean或者Model接收数据返回 2、创建一个描述网络请求的接口 3、创建Retrofit实例 4、用Retrofit实例创建网络请求接口实例 5、调用接口实例的getCall获取call 6、调用Call请求方法 二、Retrofit Retrofit就是一个定义接口然后对OKHttp的一个封装，事实上网络请求还是在OKHttp里进行。利用注解和参数利用动态代理来替使用者生成网络请求的Request和Call，来完成网络请求的一个框架。 三、Retrofit的设计模式
深入理解OkHttp3：（二）请求（Calls）详解
challenge51all的专栏
09-25 630
HTTP客户端的任务是接受您的请求并访问服务器，处理其响应。这在理论上很简单，但在实践中却很棘手。 Request：              每个HTTP请求都包含一个URL、一个方法(比如GET或POST)和一个Header列表。请求还可以包含body:特定内容类型的数据流。 Response：              Response以代码（像200代表成功，404代表未找到）、H...
retrofit设计模式
只影的博客
01-05 733
retrofit 的设计模式 1. 建造者模式 建造者模式的定义是：将一个复杂对象的构造与它的表示分离，使得建造过程可以创建不同的表示 我们来看一下retrofit的构建代码 很明显的建造者模式 2. 门面模式 门面模式要求一个子系统的外部与其内部通信必须通过一个统一的对象进行，而retrofit里这个统一的对象就是我们创建的Retrofit对象，我们只管配置Retrofit，然后获取接口对象...
Android框架源码分析——从设计模式角度看 Retrofit 核心源码
深海流浪汉
02-09 696
从设计模式角度进行Retrofit源码解析，了解外观模式、构造者模式、策略模式、动态代理的基本使用，回答了CallAdapter和Convert使用的时机、注解和参数的解析处理、和OkHttp相比的优势、接口如何匹配对应的CallAdapterFactory（通过返回值类型）、等问题
从Retrofit/Okhttp源码 学习设计模式-建造者模式
黎程雨的博客
08-16 795
建造者模式 首先我们先大致熟悉下通常的建造者模式 建造者模式（Builder Pattern）也叫生成器模式，其定义如下：将一个对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 建造者模式的通用类图如图所示： Product产品类 Builder抽象建造者 规范产品的组建，一般是由子类实现。 ConcreteBuilder 实现抽象类定义的所有方法，并且返回一个组建好的对象。 Director导演类 产品类 public class Product { public pu
Retrofit基本使用
01-03
Retrofit基本使用 – 文章目录Retrofit基本使用简介Retrofit注解方法注解标记注解请求头注解参数注解简单使用引入Retrofit依赖及添加权限创建Retrofit实例初步封装定义API接口创建代理对象接口调用 – 简介 Retrofit...
Android Retrofit的简单介绍和使用
08-31
主要介绍了Android Retrofit的简单介绍和使用
Retrofit 源码分析初探
01-04
介绍源码前，我们先看下Retrofit的基本使用，大致了解下流程，跟着这个流程来分析源码才不会乱。 1、初始化Retrofit对象 Retrofit retrofit = new Retrofit.Builder() //使用自定义的mGsonConverterFactory ....
Android中Retrofit 2.0直接使用JSON进行数据交互
08-29
本篇文章主要介绍了Android中Retrofit 2.0直接使用JSON进行数据交互，具有一定的参考价值，有兴趣的可以了解一下
Retrofit 最新源码解析 （附源码下载）
01-03
4. 如何使用 5. 源码分析 6. 后记 1. 前言  今年是2020年了，也是我正式入驻CSDN博客的第一年，说起来也凑巧，因为今年的黑天鹅事件导致我们不得不在家宅着，当然到2月中下旬很多企业都复工了，本人也一样进入了...
Android Retrofit的使用详解
08-28
本文介绍了Android Retrofit的使用详解，小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧
java8源码-Retrofit2Demo:Retrofit2使用
06-04
Retrofit的使用 本文注目录： Retrofit入门 Retrofit注解详解 Gson与Converter RxJava与CallAdapter 自定义Converter 自定义CallAdapter 其它说明 前言 本文中的Retrofit均指代Retrofit2.0。 本文涉及到的代码以及...
Retrofit 使用Demo
11-24
详情请看http://blog.csdn.net/zxw136511485/article/details/78616577，
retrofit使用
11-22
里面介绍了retrofit的使用,样式很多欢迎下载。可以运用到项目中
【设计模式】五、代理模式（10分钟悄悄搞定）
小小程序员
10-21 224
目录一、什么是代理模式？二、为什么要用代理模式？优点缺点三、静态代理1、创建接口2、实现接口3、创建代理类4、测试5、总结四、动态代理1、JDK代理模式1.1 创建代理类1.2 测试1.3 探究原理2、CGLIB2.1 maven 项目需要进入2.2 创建对象2.3 创建代理类2.4 测试类2.5 CGLIB总结3 JDK与CGLIB 对比Spring中的代理 一、什么是代理模式？ 代理模式给某一个对象提供一个代理对象，并由代理对象控制对原对象的引用。 举个栗子: 我们要买房子，虽然可以自己一个小区一个小区
Retrofit 分析 - 经典设计模式案例
...
08-31 764
原文链接：http://www.jianshu.com/p/fb8d21978e38 本篇是 retrofit 番外篇。只讲 retrofit 中的设计模式以及我个人的理解与延伸。 —— 由 Stay 分享 如果你还不知道Retrofit，没关系，okhttp你总知道吧。retrofit就是对okhttp再做了一层封装。你只需要通过简单的配置就能顺利使用retrofit来做
Retrofit中的反射耗时，罪魁祸首并不在动态代理，而在反射注解
最新发布
深海流浪汉
03-09 539
简而言之，Retrofit的代理类的方法不是直接发起请求，而是通过解析方法上的注解和传入参数，生成一个可以用于请求的对象。Retrofit的这个ServiceMethod对象，它是一个请求的模板对象，下次再调用这个ServiceMethod代理的方法的时候，直接从缓存中(复用池中）复用这个ServiceMethod对象，减免每次都一样的解析注解的步骤。
Retrofit原理解析（一）
故不积跬步无以至千里
08-30 1814
Retrofit是一个restful的HTTP网络请求框架的封装；那为什么起名叫Retrofit呢？Retrofit翻译为中文，意为改造、翻新之意，Retrofit网络请求的本质是交给内部的OkHttp来完成的，自身只负责网络请求接口的封装，这样一想，名字起的真是十级👍；我们先简单看下RetrofitAPP应用端通过Retrofit请求网络，实际上是使用Retrofit接口层封装请求参数，如Header、Url等信息，之后交给OkHttp完成后续的请求；当服务端返回请求数据后，OkHttp。......

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值