文章目录
流程图
基本使用
下面的使用不涉及到添加请求适配器、返回转换器等。
返回的就是最纯正的ResponseBody
1. 创建服务端ApiInterface
interface MyApi {
@POST("query.php")// 表示改接口使用post的方式请求
@FormUrlEncoded// 表示content-type为:application/x-www-form-urlencoded
fun queryByTitle(@Field("param") paramJsonStr: String, @Field("type") type: Int = 0):Call<ResponseBody>
}
关于Retrofit中的注解有哪些，作用分别是什么，推荐看这篇文章：《Android 网络框架:Retrofit2注解篇》
2.配置BaseUrl生成Retrofit对象
val baseUrl = "https://www.*.com/aabb/"
val retrofit = Retrofit.Builder()
.baseUrl(baseUrl)
.build()
注意：baseUrl一定要以"/"结尾，具体原因会在后面的源码中说明。
3.生成服务端ApiInterface对象
val api = retrofit.create(MyApi::class.java)
4.调用服务端ApiInterface中的方法
// 请求参数
val paramJson = JsonObject()
paramJson.addProperty("title", "黄金瞳")
val call = api.queryByTitle(paramJson.toString())
5.发起请求
// 异步请求
call.enqueue(object :Callback<ResponseBody>{
override fun onFailure(call: Call<ResponseBody>, t: Throwable) {
// 请求失败
}
override fun onResponse(call: Call<ResponseBody>, response: Response<ResponseBody>) {
// 请求成功
Log.d("d",response.body()?.string())
}
})
// 同步请求
// 这里会出错，因为Android不允许在主线程执行网络请求
val response = call.execute()
Log.d("d",response.body()?.string())
源码分析
1. 配置BaseUrl生成Retrofit对象
首先看看Retrofit.Builder的构造函数。
Builder(Platform platform) {
this.platform = platform;
}
public Builder() {
this(Platform.get());
}
Builder(Retrofit retrofit) {
...省略代码
}
有三个构造函数，一般来说都使用的是无参构造函数，然后可以看到调用了Platform.get()，根据名字可以猜到这里是确定当前执行代码的平台。进去看看。
private static final Platform PLATFORM = findPlatform();
static Platform get() {
return PLATFORM;
}
private static Platform findPlatform() {
try {
// 查看是否是Android平台
Class.forName("android.os.Build");
if (Build.VERSION.SDK_INT != 0) {
return new Android();
}
} catch (ClassNotFoundException ignored) {
}
// 返回Java8平台
return new Platform(true);
}
由于上面的例子是在Android中写的，因此这里分析的时候也可以看到返回的是一个Android对象。关于这个对象，功能很简单，就是提供了一个主线程Handler，用于将任务回调到主线程中去。
static final class Android extends Platform {
Android() {
super(Build.VERSION.SDK_INT >= 24);
}
@Override public Executor defaultCallbackExecutor() {
// 返回了一个主线程执行器
return new MainThreadExecutor();
}
static class MainThreadExecutor implements Executor {
// 主线程handler
private final Handler handler = new Handler(Looper.getMainLooper());
@Override public void execute(Runnable r) {
// 将任务提交到主线程的队列中，这样任务就可以在主线程中执行了
// 完成了线程切换
handler.post(r);
}
}
}
现在回去Retrofit.Builder中的baseUrl()方法看看是如何处理传入的String的。
public Builder baseUrl(String baseUrl) {
Objects.requireNonNull(baseUrl, "baseUrl == null");
return baseUrl(HttpUrl.get(baseUrl));
}
先检查了一下是否为Null，然后将String类型的url转换成HttpUrl的形式。
public Builder baseUrl(HttpUrl baseUrl) {
Objects.requireNonNull(baseUrl, "baseUrl == null");
List<String> pathSegments = baseUrl.pathSegments();// 这一步是将url进行拆解
// 必须以"/"结尾
if (!"".equals(pathSegments.get(pathSegments.size() - 1))) {
throw new IllegalArgumentException("baseUrl must end in /: " + baseUrl);
}
this.baseUrl = baseUrl;
return this;
}
这里主要是对url进行拆解，并判断是否是以"/"结尾。
配置好baseUrl之后，再去看看build()方法是如何生成Retrofit对象的。
public Retrofit build() {
// 必须要设置baseUrl，在设置的时候还会检查baseUrl是不是以"/"结尾
if (baseUrl == null) {
throw new IllegalStateException("Base URL required.");
}
// 所谓的callFactory 就是okHttpClient 可以看做为一个浏览器
okhttp3.Call.Factory callFactory = this.callFactory;
if (callFactory == null) {
callFactory = new OkHttpClient();
}
// 这里大部分情况下是没设置的，因此这里的platform基本为Android()
// 返回的默认执行器也是主线程执行器，用于将runnable用主线程handler执行
Executor callbackExecutor = this.callbackExecutor;
if (callbackExecutor == null) {
callbackExecutor = platform.defaultCallbackExecutor();
}
// Make a defensive copy of the adapters and add the default Call adapter.
// 翻译：制作适配器的防御副本，并添加默认的呼叫适配器。
// 这里优先添加自己配置的CallAdapterFactory，然后再在末尾添加一个默认的
List<CallAdapter.Factory> callAdapterFactories = new ArrayList<>(this.callAdapterFactories);
callAdapterFactories.addAll(platform.defaultCallAdapterFactories(callbackExecutor));
// Make a defensive copy of the converters.
// 制作防御者的副本。
List<Converter.Factory> converterFactories = new ArrayList<>(
1 + this.converterFactories.size() + platform.defaultConverterFactoriesSize());
// Add the built-in converter factory first. This prevents overriding its behavior but also
// ensures correct behavior when using converters that consume all types.
// 翻译：首先添加内置转换器工厂。 这可以防止覆盖其行为，也可以确保使用使用所有类型的转换器时的正确行为。
converterFactories.add(new BuiltInConverters());
converterFactories.addAll(this.converterFactories);
converterFactories.addAll(platform.defaultConverterFactories());
return new Retrofit(callFactory, baseUrl, unmodifiableList(converterFactories),
unmodifiableList(callAdapterFactories), callbackExecutor, validateEagerly);
}
这一步主要涉及这几个变量的赋值：callFactory、callbackExecutor、callAdapterFactories、converterFactories。
需要注意的是，callAdapterFactories和converterFactories中，index越小的元素是越先被获取到的。另外可以看到，对于callAdapterFactories是优先加入用户配置的然后才加入默认的；而converterFactories则相反，它先加入了一个默认的，然后才加入用户配置的。
callbackExecutor是由platform提供的，根据上面的源码可以看到，这里返回了一个MainThreadExecutor。用于将非主线程任务回调到主线程中。
至此，Retrofit对象就创建好了，很明显使用了设计模式-建造者模式。
2. 生成服务端ApiInterface对象
去到Retrofit中的create()方法看看。
public <T> T create(final Class<T> service) {
validateServiceInterface(service);// 验证接口，以及判断是否要提前解析注解，默认为false
/**
* 动态代理的方式创建interface对象
* @param service.getClassLoader() 类加载器
* @param new Class<?>[] { service } 要实现的类接口
* @param new InvocationHandler() 处理调用方法的InvocationHandler
* @return 返回接口中声明的对象类型
*/
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 {
...省略部分代码
return loadServiceMethod(method).invoke(args != null ? args : emptyArgs);
}
});
}
这里的话，使用到了代理模式中的动态代理。关于代理模式，可以看看这篇文章：《【Java】小例子巧妙理解代理模式》。这样，服务端ApiInterface对象也创建好了，注意这里是创建的代理对象。
下面，看看调用其中的方法时，源码是如何执行的
3. 调用服务端ApiInterface中的方法
了解动态代理的话应该知道，当调用代理对象的方法的时候，实际上会调用到InvocationHandler中的invoke()。
那么这里的话，就是调用到上面create()中的invoke()方法了。
如果略过第一行的校验代码的话，可以看到整个方法关键之处在于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;
}
该方法会返回一个ServiceMethod对象，首先从缓存中查找是否有已经生成的，如果没有则调用ServiceMethod.parseAnnotations()去生成一个，再加入到缓存中。
那么继续看看这个生成ServiceMethod的方法。
static <T> ServiceMethod<T> parseAnnotations(Retrofit retrofit, Method method) {
/**这里解析注解*/
RequestFactory requestFactory = RequestFactory.parseAnnotations(retrofit, method);
...省略部分校验代码
return HttpServiceMethod.parseAnnotations(retrofit, method, requestFactory);
}
首先生成了一个RequestFactory对象，根据名字，猜测应该是用于构建请求的工厂。
然后调用HttpServiceMethod中的parseAnnotations()方法。注意，根据idea查看，HttpServiceMethod是ServiceMethod这个类的唯一子类。小技巧：idea系列的代码编辑器可以通过alt+h来查看当前类的子类以及父类。
那么根据先后顺序，先看看RequestFactory是如何生成的，进入RequestFactory.parseAnnotations()。
3.1 构建RequestFactory
static RequestFactory parseAnnotations(Retrofit retrofit, Method method) {
return new Builder(retrofit, method).build();
}
又是熟悉的Builder类，建造者模式。
Builder(Retrofit retrofit, Method method) {
this.retrofit = retrofit;
this.method = method;
this.methodAnnotations = method.getAnnotations();// 获取方法注解
this.parameterTypes = method.getGenericParameterTypes();// 获取参数值类型
this.parameterAnnotationsArray = method.getParameterAnnotations();// 获取参数注解
}
这里的Method就是上面的ApiInterface中的方法。即MyApi.queryByTitle()。
可以看到，在构造函数中，根据传入的方法，获取到了方法注解、返回值类型、参数注解。
然后看看建造者模式中最精华的build()方法。
RequestFactory build() {
// 解析方法注解
for (Annotation annotation : methodAnnotations) {
parseMethodAnnotation(annotation);
}
...省略部分校验代码
// 解析参数注解
int parameterCount = parameterAnnotationsArray.length;// 方法参数数量
parameterHandlers = new ParameterHandler<?>[parameterCount];
for (int p = 0, lastParameter = parameterCount - 1; p < parameterCount; p++) {
parameterHandlers[p] =
parseParameter(p, parameterTypes[p], parameterAnnotationsArray[p], p == lastParameter);
}
...省略部分校验代码
return new RequestFactory(this);
}
很显然，这里在忽略了校验代码之后，主要就是将ApiInterface中的方法注解和参数注解解析出来。
3.1.1解析方法注解
首先看看解析方法注解的方法。
private void parseMethodAnnotation(Annotation annotation) {
if (annotation instanceof DELETE) {
parseHttpMethodAndPath("DELETE", ((DELETE) annotation).value(), false);
} else if (annotation instanceof GET) {
parseHttpMethodAndPath("GET", ((GET) annotation).value(), false);
} else if (annotation instanceof HEAD) {
parseHttpMethodAndPath("HEAD", ((HEAD) annotation).value(), false);
} else if (annotation instanceof PATCH) {
parseHttpMethodAndPath("PATCH", ((PATCH) annotation).value(), true);
} else if (annotation instanceof POST) {
parseHttpMethodAndPath("POST", ((POST) annotation).value(), true);
} else if (annotation instanceof PUT) {
parseHttpMethodAndPath("PUT", ((PUT) annotation).value(), true);
} else if (annotation instanceof OPTIONS) {
parseHttpMethodAndPath("OPTIONS", ((OPTIONS) annotation).value(), false);
} else if (annotation instanceof HTTP) {
HTTP http = (HTTP) annotation;
parseHttpMethodAndPath(http.method(), http.path(), http.hasBody());
} else if (annotation instanceof retrofit2.http.Headers) {
// 解析请求头注解
String[] headersToParse = ((retrofit2.http.Headers) annotation).value();
if (headersToParse.length == 0) {
throw methodError(method, "@Headers annotation is empty.");
}
headers = parseHeaders(headersToParse);
} else if (annotation instanceof Multipart) {
if (isFormEncoded) {
throw methodError(method, "Only one encoding annotation is allowed.");
}
isMultipart = true;
} else if (annotation instanceof FormUrlEncoded) {
if (isMultipart) {
throw methodError(method, "Only one encoding annotation is allowed.");
}
isFormEncoded = true;
}
}
看上去很头疼，这么多的if else if语句。实际上的逻辑其实非常简单。
首先，判断注解是否属于请求方式类型的注解，如果是的话则调用parseHttpMethodAndPath()解析出请求方式以及请求参数。
其次，如果是Headers注解的话，就调用parseHeaders()将要设置的请求头解析出来。
最后，如果是关于设置content-type的注解的话，则将对应的标志位设置为true。
老规矩，根据代码顺序，看看调用的方法中的逻辑。
3.1.1.1 请求方式类注解解析
首先是parseHttpMethodAndPath()。
private void parseHttpMethodAndPath(String httpMethod, String value, boolean hasBody) {
if (this.httpMethod != null) {
// 之前已经定义过请求方式了，再重新定义就抛出异常
throw methodError(method, "Only one HTTP method is allowed. Found: %s and %s.",
this.httpMethod, httpMethod);
}
this.httpMethod = httpMethod;
this.hasBody = hasBody;
if (value.isEmpty()) {
return;
}
// Get the relative URL path and existing query string, if present.
// 翻译：获取相对URL路径和现有查询字符串（如果存在）。
int question = value.indexOf('?');// 第一个"?"出现的位置
if (question != -1 && question < value.length() - 1) {// 存在"?"，并且不在末尾
// Ensure the query string does not have any named parameters.
// 翻译：确保查询字符串没有任何命名参数。
String queryParams = value.substring(question + 1);// 所有查询参数
Matcher queryParamMatcher = PARAM_URL_REGEX.matcher(queryParams);
if (queryParamMatcher.find()) {
// 翻译：URL查询字符串“%s”不得包含replace块。对于动态查询参数，请使用@Query
throw methodError(method, "URL query string \"%s\" must not have replace block. "
+ "For dynamic query parameters use @Query.", queryParams);
}
}
this.relativeUrl = value;
this.relativeUrlParamNames = parsePathParameters(value);
}
首先判断是否已经定义了请求方式了，然后又一个正则判断，用于查看相对url中是否存在动态查询参数。
如果有查询字符串，如：“index.php?key=value&key1={param1}”，那么这里就会抛出异常，因为查询字符串应该使用@Query这个注解。
最后调用parsePathParameters()将请求参数解析出来。这个方法就不在这里贴代码了，有兴趣的可以自行去查看。逻辑很简单，也是使用正则表达式进行匹配的。
3.1.1.2 请求头注解解析
现在回到前面，再看看parseHeaders()这个方法是如何把@Headers注解解析出来的。
private Headers parseHeaders(String[] headers) {
Headers.Builder builder = new Headers.Builder();
for (String header : headers) {
int colon = header.indexOf(':');// 第一个冒号":"的位置
if (colon == -1 || colon == 0 || colon == header.length() - 1) {
// 冒号不存在、冒号在开头、冒号在结尾都会出错
throw methodError(method,
"@Headers value must be in the form \"Name: Value\". Found: \"%s\"", header);
}
String headerName = header.substring(0, colon);
String headerValue = header.substring(colon + 1).trim();
// 针对content-type的特殊处理，生成MediaType
if ("Content-Type".equalsIgnoreCase(headerName)) {
try {
contentType = MediaType.get(headerValue);
} catch (IllegalArgumentException e) {
throw methodError(method, e, "Malformed content type: %s", headerValue);
}
} else {
builder.add(headerName, headerValue);
}
}
return builder.build();
}
整个方法分为两个部分，第一部分利用冒号":"所在的位置，将请求头分割为headerName和headerValue。
第二部分是针对content-type的特殊处理，MediaType类型，注意：content-type这个请求头并没有加入到builder中，而是特地用一个contentType变量保存起来了。
OK，到这里，关于方法中的注解就解析完成了，下面就要准备去解析参数中的注解了。
3.1.2 解析参数注解
private @Nullable ParameterHandler<?> parseParameter(
int p, Type parameterType, @Nullable Annotation[] annotations, boolean allowContinuation) {
ParameterHandler<?> result = null;
if (annotations != null) {
for (Annotation annotation : annotations) {
ParameterHandler<?> annotationAction =
parseParameterAnnotation(p, parameterType, annotations, annotation);
if (annotationAction == null) {
continue;
}
if (result != null) {
// 多个参数注解将报错
throw parameterError(method, p,
"Multiple Retrofit annotations found, only one allowed.");
}
result = annotationAction;
}
}
...省略校验代码
return result;
}
这个方法主要是循环注解，为每个参数注解都生成一个ParameterHandler对象。
关键方法是parseParameterAnnotation()。
这个方法比前面解析方法注解那个方法还要长，所以这里只针对性的挑选部分代码贴出来。
private ParameterHandler<?> parseParameterAnnotation(
int p, Type type, Annotation[] annotations, Annotation annotation) {
if (annotation instanceof Url) {
validateResolvableType(p, type);
...省略部分校验代码
gotUrl = true;
// @Url这个注解所标注的参数类型只能是：
// HttpUrl,String,URI,Uri(Android平台特有)
if (type == HttpUrl.class
|| type == String.class
|| type == URI.class
|| (type instanceof Class && "android.net.Uri".equals(((Class<?>) type).getName()))) {
return new ParameterHandler.RelativeUrl(method, p);
} else {
throw parameterError(method, p,
"@Url must be okhttp3.HttpUrl, String, java.net.URI, or android.net.Uri type.");
}
}
else if (annotation instanceof Path) {
validateResolvableType(p, type);
...省略部分校验代码
gotPath = true;
Path path = (Path) annotation;
String name = path.value();
validatePathName(p, name);// 验证是否和url中声明的动态参数一致
Converter<?, String> converter = retrofit.stringConverter(type, annotations);
return new ParameterHandler.Path<>(method, p, name, converter, path.encoded());
}
else if (annotation instanceof Query) {
validateResolvableType(p, type);
Query query = (Query) annotation;
String name = query.value();
boolean encoded = query.encoded();// 是否需要urlEncode，默认false
Class<?> rawParameterType = Utils.getRawType(type);
gotQuery = true;
...这里简化了代码
return new ParameterHandler.Query<>(name, converter, encoded);
}
...省略部分代码
return null; // Not a Retrofit annotation.
}
即使只贴了部分代码，整个方法依然很长，但是整体逻辑很简单，就是根据注解类型返回对应的ParameterHandler即可。
那么ParameterHandler到底有什么作用呢？进去这个类看看就知道到了。
abstract class ParameterHandler<T>
是一个抽象类，那么老规矩，ctrl+h查看一下它的子类。
可以看到有很多子类，而且注意一下可以发现，和注解是一一对应的，每个注解都对应了一个ParameterHandler，这里的话就随便选一个进行分析吧。
static final class Field<T> extends ParameterHandler<T> {
private final String name;
private final Converter<T, String> valueConverter;
private final boolean encoded;
Field(String name, Converter<T, String> valueConverter, boolean encoded) {
this.name = Objects.requireNonNull(name, "name == null");
this.valueConverter = valueConverter;
this.encoded = encoded;
}
@Override void apply(RequestBuilder builder, @Nullable T value) throws IOException {
if (value == null) return; // Skip null values.
String fieldValue = valueConverter.convert(value);
if (fieldValue == null) return; // Skip null converted values
builder.addFormField(name, fieldValue, encoded);
}
}
关键方法是apply()，该方法接收两个参数，一个是RequestBuilder，一个是value。
首先将value用转换器转换成String类型，然后将其赋值给RequestBuilder。看过这么多建造者模式，看到这个很自然就知道，这里就是将参数注解解析后的值传给Request。
到这里，生成RequestFactory就完成了，然后回到前面，继续看看后面的代码。
static <T> ServiceMethod<T> parseAnnotations(Retrofit retrofit, Method method) {
/**这里解析注解*/
RequestFactory requestFactory = RequestFactory.parseAnnotations(retrofit, method);
...省略部分校验代码
return HttpServiceMethod.parseAnnotations(retrofit, method, requestFactory);
}
3.2 构建HttpServiceMethod
下面就是看看这个HttpServiceMethod.parseAnnotations()方法干了什么了。
static <ResponseT, ReturnT> HttpServiceMethod<ResponseT, ReturnT> parseAnnotations(
Retrofit retrofit, Method method, RequestFactory requestFactory) {
boolean isKotlinSuspendFunction = requestFactory.isKotlinSuspendFunction;
boolean continuationWantsResponse = false;
boolean continuationBodyNullable = false;
Annotation[] annotations = method.getAnnotations();
// 获取返回值的类型
Type adapterType;
if (isKotlinSuspendFunction) {
...kotlon协程相关
} else {
adapterType = method.getGenericReturnType();
}
/**创建请求适配器*/
CallAdapter<ResponseT, ReturnT> callAdapter =
createCallAdapter(retrofit, method, adapterType, annotations);
/**返回值类型，在Interface的方法中自己定义的*/
Type responseType = callAdapter.responseType();
// 校验返回值类型是否合法
...省略部分校验代码
/**创建返回值转换器*/
Converter<ResponseBody, ResponseT> responseConverter =
createResponseConverter(retrofit, method, responseType);
okhttp3.Call.Factory callFactory = retrofit.callFactory;// 这里就是配置okHttpClient
// 选择返回哪种HttpServiceMethod
if (!isKotlinSuspendFunction) {
return new CallAdapted<>(requestFactory, callFactory, responseConverter, callAdapter);
} else if (continuationWantsResponse) {
//noinspection unchecked Kotlin compiler guarantees ReturnT to be Object.
// 翻译：noinspection未经检查的Kotlin编译器保证ReturnT为Object。
return (HttpServiceMethod<ResponseT, ReturnT>) new SuspendForResponse<>(requestFactory,
callFactory, responseConverter, (CallAdapter<ResponseT, Call<ResponseT>>) callAdapter);
} else {
//noinspection unchecked Kotlin compiler guarantees ReturnT to be Object.
return (HttpServiceMethod<ResponseT, ReturnT>) new SuspendForBody<>(requestFactory,
callFactory, responseConverter, (CallAdapter<ResponseT, Call<ResponseT>>) callAdapter,
continuationBodyNullable);
}
}
这个方法主要是获取返回值转换器、请求适配器。
虽然获取的时候，函数名为create，然而实际是上调用到了Retrofit中的方法去获取之前配置的(没有配置则选择默认的)。
从代码最后面的部分可以看到，返回的类型有三种，然而实际上只需要关注CallAdapted这个即可，因为另外的两个是给kotlin的协程使用的。
OK，到这里，ServiceMethod也创建好了，回到最初的原点，看看获取到ServiceMethod之后的代码是怎么样的。
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 @Nullable Object invoke(Object proxy, Method method,
@Nullable Object[] args) throws Throwable {
...省略部分校验代码
// 当调用生成的ApiInterface中的方法的时候，实际上回调用到这里
return loadServiceMethod(method).invoke(args != null ? args : emptyArgs);
}
});
}
可以看到，当获取到ServiceMethod对象之后，立刻调用了它的invoke()方法，那么回到前面的源码，看看invoke()中又进行了什么操作。
3.3 构建OkHttpCall
@Override
final @Nullable ReturnT invoke(Object[] args) {
// 创建实际请求对象
Call<ResponseT> call = new OkHttpCall<>(requestFactory, args, callFactory, responseConverter);
return adapt(call, args);
}
这里创建了一个OkHttpCall，顾名思义，它就是用来发起请求的最终对象了。
另外还调用adapt()，因为之前说了只关注CallAdapted这个子类，所以这里直接分析CallAdapted的adapt()方法。
@Override
protected ReturnT adapt(Call<ResponseT> call, Object[] args) {
/**先调用callAdapter.Factory.get，获取到callAdapter
* 默认情况下是DefaultCallAdapterFactory*/
return callAdapter.adapt(call);
}
很简单，返回了一个由callAdapter生成的对象。
由于本次源码分析没有引入其他的callAdapter，因此这里的就是Retrofit默认的callAdapter了。那回到Retrofit.Builder.build()方法中，看看默认的callAdapter是谁？
List<CallAdapter.Factory> callAdapterFactories = new ArrayList<>(this.callAdapterFactories);
callAdapterFactories.addAll(platform.defaultCallAdapterFactories(callbackExecutor));
调用了platform.defaultCallAdapterFactories()，那么跟进看看方法里面是什么样子的。
List<? extends CallAdapter.Factory> defaultCallAdapterFactories(
@Nullable Executor callbackExecutor) {
DefaultCallAdapterFactory executorFactory = new DefaultCallAdapterFactory(callbackExecutor);
return hasJava8Types
? asList(CompletableFutureCallAdapterFactory.INSTANCE, executorFactory)
: singletonList(executorFactory);
}
实例化了一个DefaultCallAdapterFactory。
继续跟进，在它的get()方法中，发现返回了一个callAdapter。
@Override
public @Nullable CallAdapter<?, ?> get(
...省略部分代码
final Executor executor = Utils.isAnnotationPresent(annotations, SkipCallbackExecutor.class)
? null
: callbackExecutor;
return new CallAdapter<Object, Call<?>>() {
@Override public Type responseType() {
return responseType;
}
@Override public Call<Object> adapt(Call<Object> call) {
return executor == null
? call
: new ExecutorCallbackCall<>(executor, call);
}
};
}
首先判断了下是否有@SkipCallbackExecutor这个注解，如果有这个注解的话就不进过ExecutroCallback了，直接返回当前的call对象。否则则返回一个ExecutorCallbackCall。
至此，调用服务端ApiInterface中的方法也分析完成了，这一步主要就是将各种注解解析出来，然后拼接成一个RequestBuilder对象，最后生成一个call的子类ExecutorCallbackCall。
4. 发起请求
根据前面的分析，可以很明显的知道，其实调用发起请求的对象是ExecutorCallbackCall。
那么下面就来分别看看，它的异步请求和同步请求是如何执行的。
4.1 异步请求
@Override public void enqueue(final Callback<T> callback) {
Objects.requireNonNull(callback, "callback == null");
// 实际调用的是OkHttpCall的方法
delegate.enqueue(new Callback<T>() {
@Override public void onResponse(Call<T> call, final Response<T> response) {
callbackExecutor.execute(() -> {
// 这里就回到主线程了
if (delegate.isCanceled()) {
// Emulate OkHttp's behavior of throwing/delivering an IOException on cancellation.
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(() -> callback.onFailure(ExecutorCallbackCall.this, t));
}
});
}
这里可以看到，只是调用了delegate.enqueue()，并在回调函数中使用callbackExecutor执行。
通过前面的分析，可以知道callbackExecutor.execute()只是将任务交给主线程Handler而已，因此这里不再过多关注。更多的关注到delegate这个对象。
在前面构建OkHttpCall这一步的时候，传入到CallAdapter中的call是一个OkHttpCall。然后该call一直被原封不动的继续向下传递，一直传递到了ExecutorCallbackCall。那么显然这里的delegate就是前面构建的OkHttpCall了。既然如此delegate.enqueue()，也就是OkHttpCall.enqueue()。
@Override public void enqueue(final Callback<T> callback) {
Objects.requireNonNull(callback, "callback == null");
okhttp3.Call call;
Throwable failure;
synchronized (this) {
if (executed) throw new IllegalStateException("Already executed.");
executed = true;
...
call = rawCall = createRawCall();
...
...
call.enqueue(new okhttp3.Callback() {
@Override public void onResponse(okhttp3.Call call, okhttp3.Response rawResponse) {
Response<T> response;
...
// 解析response
response = parseResponse(rawResponse);
...
callback.onResponse(OkHttpCall.this, response);
...
}
@Override public void onFailure(okhttp3.Call call, IOException e) {
callFailure(e);
}
private void callFailure(Throwable e) {
...省略部分代码
}
});
}
到这里，如果以前用过OkHttp的话，就很熟悉啦。这不就是OkHttp的异步请求吗？
首先将Retrofit.Call转换成OkHttp.Call，调用了createRawCall()这个方法。
private okhttp3.Call createRawCall() throws IOException {
okhttp3.Call call = callFactory.newCall(requestFactory.create(args));
if (call == null) {
throw new NullPointerException("Call.Factory returned null.");
}
return call;
}
这个方法就利用到了前面构建的RequestFactory啦。将其变成了OkHttp.Request，这样OkHttp才能够发起正确的请求。
请求成功后，调用parseResponse()将OkHttp返回的响应结果解析成用户想要的返回结果。这个方法留在后面分析。
现在，来看看同步请求。
4.2 同步请求
@Override public Response<T> execute() throws IOException {
okhttp3.Call call;
synchronized (this) {
...省略部分校验代码
call = rawCall;
if (call == null) {
try {
call = rawCall = createRawCall();
} catch (IOException | RuntimeException | Error e) {
throwIfFatal(e); // Do not assign a fatal error to creationFailure.
creationFailure = e;
throw e;
}
}
}
if (canceled) {
call.cancel();
}
return parseResponse(call.execute());
}
同步请求就更简单了，没啥可说的了，转换后的OkHttp.Call直接调用execute()方法获取响应结果，然后同样调用parseResponse()去将响应结果转换成用户想要的形式。
5. 解析响应结果
Response<T> parseResponse(okhttp3.Response rawResponse) throws IOException {
ResponseBody rawBody = rawResponse.body();
// Remove the body's source (the only stateful object) so we can pass the response along.
// 翻译：删除主体的源（唯一的有状态对象），以便我们传递响应。
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.
// 翻译：缓冲整个主体以避免将来的I / O。
ResponseBody bufferedBody = Utils.buffer(rawBody);
return Response.error(bufferedBody, rawResponse);
} finally {
rawBody.close();
}
}
if (code == 204 || code == 205) {
// 204:请求没有数据返回，但是头信息有用。用户代理(浏览器)会更新缓存的头信息
// 205:告诉用户代理（浏览器）重置发送该请求的文档。
rawBody.close();
return Response.success(null, rawResponse);
}
ExceptionCatchingResponseBody catchingBody = new ExceptionCatchingResponseBody(rawBody);
try {
// 大部分情况下，不设置转换器的时候，返回类型都是ResponseBody
// 这个时候会使用到BuiltInConverters中的StreamingResponseBodyConverter或BufferingResponseBodyConverter
T body = responseConverter.convert(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;
}
}
这次没有省略代码了，因为这个方法里面的大部分代码都很有必要知道。
首先克隆了一个原响应，这一步如果用过OkHttp原生的话应该知道为什么。因为OkHttp原响应只允许你读取一次，读取完之后就关闭了，如果你还想再去读的话，则会抛出异常java.lang.IllegalStateException: closed。
然后根据响应状态码进行不同的处理，这里的话只分析一下正常的流程。
调用了一个responseConverter对响应进行转换。那么这个responseConverter又从哪里来呢？
回想之前在配置Retrofit的时候，似乎在Retrofit.Builder中有涉及到。
converterFactories.add(new BuiltInConverters());
converterFactories.addAll(this.converterFactories);
converterFactories.addAll(platform.defaultConverterFactories());
由于没有自己配置转换器，因此这里只有一个BuiltInConverters和平台默认的转换器。而平台默认转换器只有在**Java8和Android API 24+**才有，而且只能转换成Optional的形式，所以这里很显然会调用到BuiltInConverters中去进行转换。
进入BuiltInConverters中可以看到有这么几个内置的转换器，分别是：
-
BufferingResponseBodyConverter
-
RequestBodyConverter
-
StreamingResponseBodyConverter
-
ToStringConverter
-
UnitResponseBodyConverter
-
VoidResponseBodyConverter
分别查看后发现，只有BufferingResponseBodyConverter和StreamingResponseBodyConverter这两个转换器是转换成ResponseBody的。
它们两者的区别主要是这样的。BufferingResponseBodyConverter会将返回结果写入到内存中，如果响应结果过大的话就会发生内存溢出异常了，比如下载文件的时候。而StreamingResponseBodyConverter则不会将结果写入到内存。它们两个之间如何选用，是根据是否使用了@Streaming这个注释来判断的。
可以在BuiltInConverters.responseBodyConverter()中看到。
@Override public @Nullable Converter<ResponseBody, ?> responseBodyConverter(
Type type, Annotation[] annotations, Retrofit retrofit) {
if (type == ResponseBody.class) {
// 根据是否有@Streaming注解来觉得使用哪个转换器
return Utils.isAnnotationPresent(annotations, Streaming.class)
? StreamingResponseBodyConverter.INSTANCE
: BufferingResponseBodyConverter.INSTANCE;
}
if (type == Void.class) {
return VoidResponseBodyConverter.INSTANCE;
}
if (checkForKotlinUnit) {
try {
if (type == Unit.class) {
return UnitResponseBodyConverter.INSTANCE;
}
} catch (NoClassDefFoundError ignored) {
checkForKotlinUnit = false;
}
}
return null;
}
总结
基本源码分析到这里就结束了。当然在日常的开发中，经常会将Retrofit和RxJava、Gson、Kotlin协程等一起配合使用。这就涉及到请求与响应是如何进行转换的，这是这篇文章没有分析到的。
通过基本的分析，可以看到Retrofit使用了大量的设计模式，而这些设计模式也让它能够很快速的去适配其他框架。比如经典的适配Gson以及RxJava，就是因为它使用的策略模式。Retrofit本身并不负责转换请求以及响应，都交给了转换器去执行。而对用户而言，只需配置自己需要的转换器，即可轻松的完成转换，而不需要任何其他的代价。
另外，Retrofit本质上其实只是对OkHttp进行了封装，使用过OkHttp原生的人都知道，如果不进行封装的话，每次发起请求都要写一大堆的重复代码。如果有兴趣看看OKHttp的源码，可以关注我的这篇文章：《【Android】OkHttp系列目录》
