前言
前段时间风风火火的流行起来这个基于OkHttp的RESTFUL Api请求工具，大家都说这个设计好nb的说，恩，实现上的思路确实很精巧。然后呢，如何精巧？怎么使用动态代理？怎么简洁？怎么拥有良好的拓展性？，另外，阅读本文前，建议先将参考的两篇文章先看下。
动态代理
ok,分析文章需要先来说明原理，show you the code:
public<T> T getProxy(Class<T> clazz){
return (T) Proxy.newProxyInstance(clazz.getClassLoader(), clazz.getInterfaces(), new InvocationHandler() {
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
//porxy 被代理的对象
//method 被代理的对象的方法
//args 传进来的参数变量
//这里可以获取到方法 ，获取其上的运行时注解，根据注解以及参数来拼接生成请求的对象
return null;
}
});
}
上面便是一个很简单的java代理的实现，看到了没clazz.getInterfaces(),哈哈，java的动态代理基于接口，所以这也是retrofit 里面只是定义了接口的原因！当然，说到了java的动态代理，当然要全面的看问题，需要了解好处以及不足，根据不同的需求采取不同的方案：
使用Java动态代理机制的好处：
1、减少编程的工作量：假如需要实现多种代理处理逻辑，只要写多个代理处理器就可以了，无需每种方式都写一个代理类。
2、系统扩展性和维护性增强，程序修改起来也方便多了(一般只要改代理处理器类就行了)。
使用Java动态代理机制的限制：
目前根据GOF的代理模式，代理类和委托类需要都实现同一个接口。也就是说只有实现了某个接口的类可以使用Java动态代理机制。但是，事实上使用中并不是遇到的所有类都会给你实现一个接口。因此，对于没有实现接口的类，目前无法使用该机制。
动态代理，本质是代理了某个对象内方法的实现。
我们会发现，这种方式的代理，必须要有一个接口，并且实现上是通过反射机制，局限性和效率都是问题，这样就引出了动态代理的另一种实现：CGLib
CGlib 没有接口的限制，并且底层是采用ASM字节码生成框架，使用字节码技术生成代理类，比反射效率高。
所以，我们能不能使用这套机制来实现动态代理呢？这里留给你们思考。
解构
- CallAdapter
顾名思义，应该是一个请求适配器，何谓请求适配器呢？
我们先来看下它是怎么被用到的吧：
```java
public Object invoke(Object proxy, Method method, 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 serviceMethod = loadServiceMethod(method);
//可以发现这里是和okhttp耦合的，其实改下这里的实现，也可以使用其他的网络请求库
OkHttpCall okHttpCall = new OkHttpCall<>(serviceMethod, args);
//这里，这里，将okHttpCall 通过adapt 转换为了另外一个类型的对象。这个对象就是你的方法的返回值
return serviceMethod.callAdapter.adapt(okHttpCall);
}
```
所以，其实请求适配器的作用就是将一个网络请求的封装对象（callAdapter）,转化为另外一个类型，满足定制化的需求。整个流程理一下：
在创建网络请求时，我们一般会传入一个适配器，以 rxjava模式举例如下：
public static WordSegmentService getWordSegmentService(){
Retrofit retrofit = new Retrofit.Builder()
.baseUrl(BASE_URL)
.client(mOkHttpClient)
.addCallAdapterFactory(RxJavaCallAdapterFactory.create())//添加了一个请求适配器
.addConverterFactory(GsonConverterFactory.create())
.build();
return retrofit.create(WordSegmentService.class);
}
然后这个适配器对象会在动态代理时，最后一步被使用：
//这里，这里，将okHttpCall 通过adapt 转换为了另外一个类型的对象。这个对象就是你的方法的返回值。
//里面其实逻辑没有多么复杂，重点关注 Retrofit 和 ServiceMethod 这两个类
return serviceMethod.callAdapter.adapt(okHttpCall);
至此，我们来理一理整个动态代理的流程，接口--->具体方法--->获取方法参数和变量进行包装--->生成新的对象--->调用新的方法--->调用并返回 被代理的方法 的 返回值。
哈哈，最后一个步骤有点绕，但是想必大家知道最后一步应该是重点吧。如何确保返回值是类型兼容的呢？这里便有了addCallAdapterFactory,so我们便可以将轻松的将okhttpcall对象转化为Observable对象啦。
我们可以看到，这里其实除了rxjava模式，只要实现对应的接口，其他自定义的模式也是可以实现的，只有想不到，没有做不到。
- Converter
顾名思义，转换器，什么的转换器呢？来，看源码：
可以看到，转换器的作用是允许我们自己定义入参和返回的类型,我们需要重点关注下ResponseBody和RequestBody，而这些都是okhttp中的抽象类，确实是耦合的。
具体哪里使用到了呢？，可以参考MethodService,里面无处不在，毕竟这里是和网络请求参数相关的，肯定要放在生成网络请求参数 的类中，有兴趣的小伙伴可以看下。
Class<?> rawParameterType = Utils.getRawType(type);
if (Iterable.class.isAssignableFrom(rawParameterType)) {
if (!(type instanceof ParameterizedType)) {
throw parameterError(p, rawParameterType.getSimpleName()
+ " must include generic type (e.g., "
+ rawParameterType.getSimpleName()
+ "<String>)");
}
ParameterizedType parameterizedType = (ParameterizedType) type;
Type iterableType = Utils.getParameterUpperBound(0, parameterizedType);
Converter<?, String> converter =
retrofit.stringConverter(iterableType, annotations);
return new ParameterHandler.Field<>(name, converter, encoded).iterable();
} else if (rawParameterType.isArray()) {
Class<?> arrayComponentType = boxIfPrimitive(rawParameterType.getComponentType());
Converter<?, String> converter =
retrofit.stringConverter(arrayComponentType, annotations);
return new ParameterHandler.Field<>(name, converter, encoded).array();
} else {
Converter<?, String> converter =
retrofit.stringConverter(type, annotations);
return new ParameterHandler.Field<>(name, converter, encoded);
}
然后呢，我们再来理一下逻辑，Retrofit-->addConverterFactory-->MethodService-->getConverter-->处理请求或者返回参数。这里，对外只提供Retrofit,你是不会了解到MethodService的存在的。好的设计便是这样，对外提供尽可能少的接口，保证接口的稳定性，而内部如何实现均可。
- 注解
ok，先上图为敬：
点进去可以看出他们都是运行时注解，说到运行时注解，肯定不能忘记反射，没错，确实是用到了反射，而我们知道，android开发中是不提倡用反射的，原因则是因为效率问题。
辣么有没有什么更优解呢？
能想到的有 编译时注解，即在编译的时候通过apt生成相应的代码，这样就解决了反射的问题，但是呢？很麻烦，需要手动写生成类，另外扩展性也是问题，如果没有比较良好的设计的话，相信最后的代码会惨不忍睹。但是，如果能够完善，想必也会相当的优雅，这里就留给小伙伴们自行发挥了。
总结
其实，对于普通的网络请求，我们也可以普通的实现，但是作为一个有追求的人，都会希望自己写的简洁，易扩展，解耦合，能够经得起时间的考验，编码犹如艺术，希望能够写出这样的代码，前提便是更多的去阅读这类优秀的代码，毕竟只有站在巨人的肩膀上才能看的更远。
