前言

前段时间风风火火的流行起来这个基于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字节码生成框架，使用字节码技术生成代理类，比反射效率高。

所以，我们能不能使用这套机制来实现动态代理呢？这里留给你们思考。

解构

1. 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模式，只要实现对应的接口，其他自定义的模式也是可以实现的，只有想不到，没有做不到。

2. 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的存在的。好的设计便是这样，对外提供尽可能少的接口，保证接口的稳定性，而内部如何实现均可。

3. 注解
   ok，先上图为敬：

retrofit中使用到的注解

点进去可以看出他们都是运行时注解，说到运行时注解，肯定不能忘记反射，没错，确实是用到了反射，而我们知道，android开发中是不提倡用反射的，原因则是因为效率问题。
辣么有没有什么更优解呢？
能想到的有 编译时注解，即在编译的时候通过apt生成相应的代码，这样就解决了反射的问题，但是呢？很麻烦，需要手动写生成类，另外扩展性也是问题，如果没有比较良好的设计的话，相信最后的代码会惨不忍睹。但是，如果能够完善，想必也会相当的优雅，这里就留给小伙伴们自行发挥了。

总结

其实，对于普通的网络请求，我们也可以普通的实现，但是作为一个有追求的人，都会希望自己写的简洁，易扩展，解耦合，能够经得起时间的考验，编码犹如艺术，希望能够写出这样的代码，前提便是更多的去阅读这类优秀的代码，毕竟只有站在巨人的肩膀上才能看的更远。

参考

• 深入浅出 Retrofit，这么牛逼的框架你们还不来看看？
• 谜之RxJava（四）—— Retrofit和RxJava的基情