源码梳理：Retrofit
按照惯例，先上最简单的使用场景
- 初始化retrofit对象
val retrofit = Retrofit.Builder()
.baseUrl("https://api.github.com/")
.build()
- 按照请求创建响应的接口和方法，并使用相应的返回值
interface Service {
@GET("users/{userName}/repos")
fun get(@Path("userName") userName: String) Call<String>
}
- 使用retrofit对象传入service接口的类对象，并调用相应方法得到返回值
val response = retrofit.create(Service::class.java).get("xxx")
我们知道，retrofit的功能是用来发送网络请求的，但它并不负责整个网络请求的过程，核心的请求体构建、建立连接、发送、返回报文解析等工作都是由另一个非常优秀的开源库--OkHttp来完成的。那么问题来了--
既然有了OkHttp，为什么还要写Retrofit？
首先看下github页的介绍，一句话
A type-safe HTTP client for Android and the JVM
确实，okhttp在传入构建好的request后会得到一个Call对象，但请注意，这个Call类和Retrofit创建接口时返回的Call类不是一回事，它是不带泛型参数的。那么由这个Call对象发出请求后会得到一个Response对象，然后我们需要自己去解析里面的header，body等等。这种不受限的响应在带来灵活性的同时也引入了风险，这对于日常开发来说当然是需要降低这种风险的。
所以，Retrofit增加了一个带泛型参数的Call类，而且规定必须写确定的类型，否则会给你报错。
还有一点和OkHttp不同，Retrofit把更多的工作交给了Retrofit类，而关于请求的相应信息规定用一个接口方法来描述关系，再配合注解完成请求的组装。你不用再去考虑一个request的url怎么组装，header怎么加，请求体怎么创建等问题。
好的，接下来我们来看源码。
以下源码基于retrofit-2.4.0
从create出发
先看create方法：
public <T> T create(final Class<T> service) {
// 传入的service必须是接口且无父接口
Utils.validateServiceInterface(service);
if (validateEagerly) {
// 提前初始化接口方法的serviceMethod
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.
// 是否是Object方法
if (method.getDeclaringClass() == Object.class) {
return method.invoke(this, args);
}
// 是否是默认方法
if (platform.isDefaultMethod(method)) {
return platform.invokeDefaultMethod(method, service, proxy, args);
}
// 创建ServiceMethod，内部封装此retrofit和method
ServiceMethod<Object, Object> serviceMethod =
(ServiceMethod<Object, Object>) loadServiceMethod(method);
// 创建请求对象
OkHttpCall<Object> okHttpCall = new OkHttpCall<>(serviceMethod, args);
// 开始请求
return serviceMethod.adapt(okHttpCall);
}
});
}
不管别的，看adapt方法
#ServiceMethod
T adapt(Call<R> call) {
return callAdapter.adapt(call);
}
嗯？这个callAdapter是谁？找一找
#ServiceMethod
private CallAdapter<T, R> createCallAdapter() {
Type returnType = method.getGenericReturnType();
...
Annotation[] annotations = method.getAnnotations();
try {
//noinspection unchecked
return (CallAdapter<T, R>) retrofit.callAdapter(returnType, annotations);
} catch (RuntimeException e) { // Wide exception range because factories are user code.
throw methodError(e, "Unable to create call adapter for %s", returnType);
}
}
把这个接口方法的返回值和注解委托给了retrofit对象来创建
#Retrofit
public CallAdapter<?, ?> nextCallAdapter(@Nullable CallAdapter.Factory skipPast, Type returnType,
Annotation[] annotations) {
...
int start = callAdapterFactories.indexOf(skipPast) + 1;
for (int i = start, count = callAdapterFactories.size(); i < count; i++) {
// 从一个callAdapterFactories列表里依次创建，创建成功的返回，此列表在retrofit创建时初始化
CallAdapter<?, ?> adapter = callAdapterFactories.get(i).get(returnType, annotations, this);
if (adapter != null) {
return adapter;
}
}
...
}
#Retrofit.build()
List<CallAdapter.Factory> callAdapterFactories = new ArrayList<>(this.callAdapterFactories);
// 默认添加一个CallAdapterFactory, platform此处是Android类
callAdapterFactories.add(platform.defaultCallAdapterFactory(callbackExecutor));
#Androoid
@Override CallAdapter.Factory defaultCallAdapterFactory(@Nullable Executor callbackExecutor) {
if (callbackExecutor == null) throw new AssertionError();
// 我们要找的真正创建CallAdapter的类
return new ExecutorCallAdapterFactory(callbackExecutor);
}
#ExecutorCallAdapterFactory.get()
@Override public Call<Object> adapt(Call<Object> call) {
// 真正返回的Call对象，对它进行excute或enqueue等操作
return new ExecutorCallbackCall<>(callbackExecutor, call);
}
我们再看看它的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() {
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);
}
});
}
});
}
可以看到这个默认的call只是在之前的HttpCall之上又加了一层线程切换，最后都会切回主线程。
至此先来梳理一下流程：
- Retrofit在build初始化的时候保存了一系列CallAdapterFactory
- ServiceMethod在build初始化的时候传入retrofit实例，同时通过之前的Factories创建CallAdapter
- serviceMethod调用CallAdapter实例的adapt方法
这个流程其实是通用的，后续还会有类似的对象也是这样创建。
那么我们直接看HttpCall里干了什么
#HttpCall
@Override public void enqueue(final Callback<T> callback) {
...
synchronized (this) {
...
if (call == null && failure == null) {
try {
// 组装并创建真正的OkHttp请求
call = rawCall = createRawCall();
} catch (Throwable t) {
throwIfFatal(t);
failure = creationFailure = t;
}
}
}
...
call.enqueue(new okhttp3.Callback() {
@Override public void onResponse(okhttp3.Call call, okhttp3.Response rawResponse) {
Response<T> response;
try {
// 将返回的数据进行转换
response = parseResponse(rawResponse);
} catch (Throwable e) {
callFailure(e);
return;
}
...
});
}
可以看到，主要做了三件事：创建请求、发送请求、转换返回的数据。至于更底层的请求发送的整个链路处理就交给OkHttp了.
请求创建
先看创建请求，在这个过程中，最核心的类有两个：ParameterHandler 和 CallFactory。
先说CallFactory，其实就是OkHttp的OkHttpClient，可以自己配置并作为Retrofit的build参数传入，或者在build的时候会创建一个默认的。
再看ParameterHandler，看名字其实能大致猜测一下，是用来处理接口方法中的参数的。那我们看一下它是在那里初始化的
#ServiceMethod.build()
// p是方法形参顺序下标，parameterType是形参类型， parameterAnnotations是该形参上加的所有注解
parameterHandlers[p] = parseParameter(p, parameterType, parameterAnnotations);
最后到了ServiceMethod的parseParameterAnnotation方法中，这个方法会根据传入的annotation类型返回相应的ParameterHandler，我们来看个相对简单的@Path注解是怎么处理的
#ServiceMethod.parseParameterAnnotation()
else if (annotation instanceof Path) {
// 与@Path注解冲突的注解直接抛出异常
if (gotQuery) {
throw parameterError(p, "A @Path parameter must not come after a @Query.");
}
if (gotUrl) {
throw parameterError(p, "@Path parameters may not be used with @Url.");
}
if (relativeUrl == null) {
throw parameterError(p, "@Path can only be used with relative url on @%s", httpMethod);
}
gotPath = true;
Path path = (Path) annotation;
String name = path.value();
// 检查是否有非法字符以及与url是否冲突
validatePathName(p, name);
// 创建ParameterHandler
Converter<?, String> converter = retrofit.stringConverter(type, annotations);
return new ParameterHandler.Path<>(name, converter, path.encoded());
}
先不管converter，看看handler的apply方法
#ParameterHandler.Path.apply()
@Override void apply(RequestBuilder builder, @Nullable T value) throws IOException {
if (value == null) {
throw new IllegalArgumentException(
"Path parameter \"" + name + "\" value must not be null.");
}
builder.addPathParam(name, valueConverter.convert(value), encoded);
}
#RequestBuilder.addPathParam()
void addPathParam(String name, String value, boolean encoded) {
if (relativeUrl == null) {
// The relative URL is cleared when the first query parameter is set.
throw new AssertionError();
}
// 调用replace将url中预留的path替换为格式化后的真正path
relativeUrl = relativeUrl.replace("{" + name + "}", canonicalizeForPath(value, encoded));
}
由此可以推断其他ParameterHandler子类应该也是类似的流程，在apply方法中不断将请求补充至完整。
此时再回来看之前的stringConverter, 它是由converterFactory返回的，在这里是由Retrofit创建时传入的GsonConverterFactory对象创建的，
而此对象的该方法未实现，所以会返回一个默认的converter，只是简单的toString，那么就是未经处理的路径直接替换，最后得到完全体的Url。
转换响应
#OkHttpCall
Response<T> parseResponse(okhttp3.Response rawResponse) throws IOException {
...
ExceptionCatchingRequestBody catchingBody = new ExceptionCatchingRequestBody(rawBody);
try {
// 转换成功，返回response
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;
}
}
toResponse其实和toCall差不多，不过最终调用的是GsonResponseBodyConverter的convert，也就是调用gson库进行解析，具体解析原理此处不做说明。
总结
至此我们大致梳理了一遍Retrofit的工作流程，可以看出有三个类承担了大部分的工作：Retrofit，ServieMethod，OkHttpCall。它们的职责也可以做一个大致的概括：
- Retrofit：以builder模式构建，提供公共参数的配置并保存，使用动态代理代理我们定义的接口，在调用方法时解析接口信息并包装成call供我们调用。
- ServiceMethod：与方法对应，负责配合注解解析方法信息并组装成一个完整的Call，解析过程中调用retrofit中的公共配置得到结果。
- OkHttpCall：负责直接调用OkHttp接口，它会传递参数给ServieMethod，ServieceMethod根据具体参数结合之前的方法信息生成具体的Call，OkHttpCall再去发送这个Call，并再通过ServiceMethod的Converter转换响应并返回。
对于一个Retrofit来说，一套公共配置下，一个方法的信息是确定的，那么就可以根据传入的参数动态地返回数据，所以在这里方法信息是可以复用的，所以Retrofit中有一个ConcurrentHashMap实现的ServieMethod缓存，用于复用这些方法信息。
这对于我们自已实现模块也是有帮助的。第一，抽取可变模块做依赖倒置，或者可以只传入工厂对象，这样连依赖关系都不用改，只修改工厂返回的对象就可以。第二，对于一个模块，可以将其拆分为可变与不可变的两部分，并对不可变的部分考虑是否可以做缓存，当然这是在这部分足够重的情况下。第三，对于一个已经比较完备的模块，要在其上做修改或者扩展，首先考虑等否代理实现，最好不要直接修改，如果实在代理不了再考虑重构。
