在上一篇文章Retrofit源码初探中，我们分析到了Retrofit的信息封装主要是下面这句代码搞定的
ServiceMethod<Object, Object> serviceMethod =
(ServiceMethod<Object, Object>) loadServiceMethod(method);
现在，我们详细去探究如何拼装的的。
惯例猜测
看源码之前，我们最好是带着问题去看，不然很容易一头扎进源码细节出不来。那么要带哪些疑问呢？所以我们先来猜测，对于一个http请求来说，我们通常关心的就是请求url，请求方法（post?get?delete?)，请求头header，请求表单body，所以我们主要就是看这些如何拼装的。
loadServiceMethod干了什么?
看到那句关键代码，我们也大致猜到了，我们在接口中定义的每个方法肯定都会被组装成一个个的ServiceMethod,为了验证猜测，我们看下ServiceMethod到底有哪些属性：
private final HttpUrl baseUrl;
private final Converter<ResponseBody, R> responseConverter;
private final String httpMethod;
private final String relativeUrl;
private final Headers headers;
private final MediaType contentType;
private final boolean hasBody;
private final boolean isFormEncoded;
private final boolean isMultipart;
private final ParameterHandler<?>[] parameterHandlers;
看到这些属性，baseUrl,relativeUrl,httpMethod,很明显，这些就是一个http请求所要的信息，所以基本可以确定我们猜测没错。
然后，我们看看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 = new ServiceMethod.Builder<>(this, method).build();
serviceMethodCache.put(method, result);
}
}
return result;
}
源码很清晰，这里采用缓存机制，这个不难理解，因为一个方法定义的请求有可能调用多次，而每次调用只有参数的value不一样，其他的都是一模一样，根本没必要重新拼装一次。
所以这个方法核心就是从缓存中去取这个method拼装后的ServiceMethod对象，如果之前没有缓存过就自己构造一个，并缓存起来。ok,loadServiceMethod()方法是干什么的解决！！！
ServiceMethod对象构建过程中拼装了什么？
通过上面的分析，我们发现真正的拼装就是这句完成的：
result = new ServiceMethod.Builder<>(this, method).build();
这里采用了建造者模式，我们去看看核心代码build（）方法中干了什么：
//省略无关紧要代码
for (Annotation annotation : methodAnnotations) {
parseMethodAnnotation(annotation); //重点关注
}
//省略无关紧要代码
for (int p = 0; p < parameterCount; p++) {
Type parameterType = parameterTypes[p];
if (Utils.hasUnresolvableType(parameterType)) {
throw parameterError(p, "Parameter type must not include a type variable or wildcard: %s",
parameterType);
}
Annotation[] parameterAnnotations = parameterAnnotationsArray[p];
if (parameterAnnotations == null) {
throw parameterError(p, "No Retrofit annotation found.");
}
parameterHandlers[p] = parseParameter(p, parameterType, parameterAnnotations); //重点关注
//省略无关紧要代码
}
此处回顾下我们的接口定义中方法是怎么写的：
@FormUrlEncoded
@POST("users/stven0king/repos")
Call<List<Repo>> listRepos(@Field("time") long time);
这里注解分为2种，一种是加在方法之上的，比如@FormUrlEncoded、@POST,一种是加在参数上的，比如@Field。这两种注解刚好对应于代码中的ParseMethodAnnotation方法和parseParameter方法。
也就是说，整个ServiceMethod对象的构造过程其实主要就是对以上两种注解的解析。所以，又一个问题解决！！！
方法级别的注解解析
上面我们分析了两种注解的解析对应的方法，这里，我们详细探讨下parseMethodAnnotation方法中如何处理各种注解的：
private void parseMethodAnnotation(Annotation annotation) {
//这类主要是处理http协议对应的各种请求方法
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);
if (!Void.class.equals(responseType)) {
throw methodError("HEAD method must use Void as response type.");
}
} 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) {
//此处主要处理Header
String[] headersToParse = ((retrofit2.http.Headers) annotation).value();
if (headersToParse.length == 0) {
throw methodError("@Headers annotation is empty.");
}
headers = parseHeaders(headersToParse);
} else if (annotation instanceof Multipart) {
if (isFormEncoded) {
throw methodError("Only one encoding annotation is allowed.");
}
isMultipart = true;
} else if (annotation instanceof FormUrlEncoded) {
if (isMultipart) {
throw methodError("Only one encoding annotation is allowed.");
}
isFormEncoded = true;
}
}
可以看到这里主要将注解分成了三类，其中一类@Multipart和@FormUrlEncoded主要是为了设置标志位，第二种是htt协议对应的各种方法，比如DELETE、GET、POST、HEAD等，最后一种是@Headers标签。标志位的设置没什么好说的，我们主要是看parseHttpMethodAndPath方法以及parseHeader方法。
parseHttpMethodAndPath方法解析
其实从名字就可以看出来，这个方法应该主要拼装当前的请求是采用了http的何种方法（POST或GET之类）以及url的设置：
private void parseHttpMethodAndPath(String httpMethod, String value, boolean hasBody) {
if (this.httpMethod != null) {
throw methodError("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.
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()) {
throw methodError("URL query string \"%s\" must not have replace block. "
+ "For dynamic query parameters use @Query.", queryParams);
}
}
this.relativeUrl = value;
this.relativeUrlParamNames = parsePathParameters(value);
}
这里对于http方法的解析没什么好说的，直接根据注解类型直接记录即可，也就是
this.httpMethod = httpMethod
但对于url的解析就没那么简单了,这句this.relativeUrl = value没有什么问题，直接记录整个url，这里比较难理解的代码主要就是那段正则的检查，正则的完整表达式如下：
\{([a-zA-Z][a-zA-Z0-9_-]*)\}
要理解这段正则，我们先看下Retrofit接口的一种定义方式：
public interface IpServiceForPath {
@GET("{path}/getIpInfo.php?ip=59.108.54.37")
Call<IpModel> getIpMsg(@Path("path") String path);
}
此处的url中其实是可以放置占位符的，而这段正则就是为了防止下面这种情况：
public interface IpServiceForPath {
@GET("{path}/getIpInfo.php?ip={ip}")
Call<IpModel> getIpMsg(@Path("path") String path);
}
在？后面的参数中不允许占位符。那么对于url中有占位符的情况怎么处理呢？看这一句：
this.relativeUrlParamNames = parsePathParameters(value);
这个方法就不细究了，很简单，主要就是把url中的占位符，比如”{path}/getIpInfo“中的”path”加入到了relativeUrlParamNames的Set中。
我们总结下这个方法做了什么：
以这个接口为例：
public interface IpServiceForPath {
@GET("{path}/getIpInfo.php?ip=59.108.54.37")
Call<IpModel> getIpMsg(@Path("path") String path);
}
其中@GET变成了ServiceMethod.httpMethod,
“{path}/getIpInfo.php?ip=59.108.54.37″变成了ServiceMethod.relativeUrl,
“{path}”中的”path”加入到了ServiceMethod.relativeUrlParamNames中。
parseHeader方法解析
先看下源码：
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(
"@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();
if ("Content-Type".equalsIgnoreCase(headerName)) {
MediaType type = MediaType.parse(headerValue);
if (type == null) {
throw methodError("Malformed content type: %s", headerValue);
}
contentType = type;
} else {
builder.add(headerName, headerValue);
}
}
return builder.build();
}
首先这个方法返回值大家注意下，不是返回通常意义上的map，而是直接返回了OkHttp的Headers。整个方法没什么难以理解的，就是检查了下格式，然后把一个个键值对放进去而已，当然对于“Content-Type”做了特殊处理，根据这个type的value值设置了ServiceMethod.contentType。
参数级别注解解析
之前我们在ServiceMethod 中的内部类的build方法中有这样一段：
int parameterCount = parameterAnnotationsArray.length;
parameterHandlers = new ParameterHandler<?>[parameterCount];
for (int p = 0; p < parameterCount; p++) {
Type parameterType = parameterTypes[p];
if (Utils.hasUnresolvableType(parameterType)) {
throw parameterError(p, "Parameter type must not include a type variable or wildcard: %s",
parameterType);
}
Annotation[] parameterAnnotations = parameterAnnotationsArray[p];
if (parameterAnnotations == null) {
throw parameterError(p, "No Retrofit annotation found.");
}
parameterHandlers[p] = parseParameter(p, parameterType, parameterAnnotations);
}
可以看到，这里对参数注解的拼装其实就是遍历每个参数，为每一个参数生成一个ParameterHandler, 核心就是parseParameter方法。但在分析这个方法之前，我们要弄清楚ParameterHandler是什么，为什么要这个东西。
ParameterHandler分析
首先，我们之前分析过对参数注解的解析就是为每个参数生成一个ParameterHandler,但是，能够放在参数中的注解有多少？@Url、@Path、@Query、@QueryName、@QueryMap、@Header、@HeaderMap、@Field、@FiledMap、@Part、@PartMap、@Body 一共11种注解，最终，这些注解的值都是要设置到http请求中去的，那我们怎么保存这些注解的值？
当然，我们可以设置11个单独变量来存，然后一个个的取，这样的操作要重复11次，身为一名程序员怎么可以这么low？我们当然是利用抽象功能，提供一种统一的对外接口，使得能够将这11个注解的值设置到对应的地方去。
abstract void apply(RequestBuilder builder, @Nullable T value) throws IOException;
这是定义在ParameterHandler中的抽象方法，这个apply方法就是将每个注解对应的值设置到RequestBuilder中去，这样我们就不用一个个的设置每个注解的值，而是利用循环去设置就可以了，这就是为何要为每个注解参数都生成一个ParameterHandler的原因。
这样，每个注解都会有一个对应的ParameterHandler，实现这个apply方法。事实也确实是这样：
[站外图片上传中…(image-846a0a-1522067731692)]
parseParameter如何为每个注解构造ParameterHandler
写到这里，本文就有点长了，后面还要对每种注解是如何生成ParameterHandler一一进行分析，所以放到下篇中进行。
