不同网络请求框架之间的对比

easyhttp、retrofit与okgo的对比

• Retrofit 在我看来并不是那么好用，因为很多常用的功能实现起来比较麻烦，动态 Host 要写拦截器，日志打印要写拦截器，就连最常用的添加全局参数也要写拦截器，一个拦截器意味着要写很多代码，如果写得不够严谨还有可能出现 Bug，从而影响整个 OkHttp 请求流程，我经常在想这些功能能不能都用一句代码搞定，因为我觉得这些功能是设计框架的时候本应该考虑的，这便是我做这个框架的初心。
• OkGo 其实也存在一些弊端，例如会把参数的 key 引用放到外层去，这样会引发一些问题：

1. 1. Key 管理问题：这个 key 可能会在外层被使用很多次，这样参数的 key 管理就会变得不可控，后续接口改动可能会出现漏改的风险，尽管这种情况比较少见，但是也不容忽视，而 EasyHttp 没有这个问题，因为 EasyHttp 不会将参数 key 值放置到外层中去。
   2. 接口参数注释的问题：站在代码的规范角度上讲，我们应该在代码中注明参数的含义及作用，如果一旦将 key 放到外层，那么每一处调用的地方都需要写一遍注释，而 EasyHttp 是将参数字段化，只需要写一次注释到字段上即可。
   3. 接口信息完整信息展示：使用 OkGo 请求网络，只能在调用的地方看到传递的接口参数，而一些被其他地方引用的参数，我们无法很直观的看到，只能通过追踪代码或者查看文档来得知，而 EasyHttp 将一个接口的信息全部通过一个类来管理的，这个类其实就相当于一个接口文档。
   4. 接口的动态化配置：除了接口的参数之外，一个接口还有可能单独配置 OkHttpClient 对象、参数的提交方式、接口响应处理方式等，这些用 OkGo 是可以实现，但是每个地方都要写一次，而 EasyHttp 可以直接在 API 类中配置，真正做到一劳永逸。

• EasyHttp 采用了 OOP 思想，一个请求代表一个对象，通过类继承和实现的特性来对接口进行动态化配置，几乎涵盖接口开发中所有的功能，使用起来非常简单灵活。而 Retrofit 采用的是注解方式，缺点是灵活性极低，因为注解上面只能放常量，也就会限定你在注解上面的一切参数只能是事先定义好的，这对接口的动态化配置极不利的。
• 有很多人觉得写一个接口类很麻烦，关于这个问题我后面已经想到一个好方案了，大家可以将 Api 类和 Bean 类写在一起，这样大家就不需要多写一个类了，具体写法示例如下：

public final class XxxApi implements IRequestApi {
 
    @Override
    public String getApi() {
        return "xxx/xxx";
    }
 
    private int xxx;
 
    public XxxApi setXxx(int xxx) {
        this.xxx = xxx;
        return this;
    }
 
    ......
 
    public final static class Bean {
 
        private int xyz;
 
        public int getXyz() {
            return xyz;
        }
 
        ......
    }
}

• 是不是很机智？这样不仅很好地解决了这一问题，还能将一个接口所有的信息都包裹在这个类中，非常直观，一览如云，妥妥的一箭双雕。