1. 背景
好早就在网上看网络框架源码的时候，突然看到有人在问Volley、OkHttp、Retrofit我到底应该用哪个呢？我其实想去回答但是又怕误导别人，今天随着项目的推进我们来对比一下，先上一张图：
上面的这些应该都认识，我们使用第三方的开源库，说好听一点是为了降低开发周期和难度，说得不好听一点就不说了，要我自己去写我还真不知道该怎么办，我们只能来分析分析碰到个女鬼我们几个汉子该怎么分。
2. 对比
**httpclient ：**6.0中已移除，其封装库async-http也早已停止更新白扯；
**httpurlconnection ：**sdk提供的网络类，我们可以用它结合asynctask封装自己的简单的网络库，自己写白扯；
android-async-http：停止更新白扯。
volley ：
功能：基于HttpUrlConnection，封装了URL图片加载框架，支持图片加载，Activity和生命周期可以联动；
性能：可扩展性好，可支持HttpClient、HttpUrlConnection和Okhttp;
应用场景：适合轻量级网络交互，网络请求频繁，传输数据量小，不适合大数据的网络操作（比如下载视频、音频），所以不适合用来上传文件；
使用：封装性好，简单易用；
**备注：**Volley的Request和Response都是把数据方法放到byte[]数组里，不支持输入输出流，把数据放到数组中，如果大文件多了，数组就会非常大且多消耗内存，所以不如直接返回Stream那样具备可操作性,比如下载一个大文件，不可能把每个文件都缓存到内存之后再写到文件里okhttp ：
功能：高性能Http请求库，可把它理解成是一个封装之后的类似HttpUrlConnection的一个东西，属于同级并不是基于二者，支持SPDY，共享同一个Scoket来处理同一个服务器的所有请求，支持同步异步，无缝的支持GZIP来减少数据流量；
性能：基于NIO和Okio，所以性能比较好，请求处理速度快（IO:阻塞式；NIO:非阻塞式；Okio是Square公司基于IO和NIO做的一个更简单、高效处理数据流的一个库）;
应用场景：重量级网络交互场景，网络请求频繁、传输数据量大（当然更推荐Retrofit，反正Retrofit是基于Okhttp的）；
**使用：**API调用简单方便，使用时需要进行多一层封装；
**备注：**Android4.4的源码可以看到HttpUrlConnection已经替换成Okhttp实现了，越来越强大。-
retrofit：
功能：基于Okhttp,restful Api设计风格，可通过注解配置请求包括请求方法，请求参数，请求头返回值等等，可以搭配多种Converter将获得的数据解析&序列化，提供对RxJava的支持；
性能：性能最好处理最快，因为是基于Okhttp封装所以扩展性差，这其实是高度封装所带来的后果;
应用场景：可以优先选择，特别是后台Api遵循restful的风格&项目中有使用RxJava；
使用：简洁易用（restful Api设计风格）代码简化（更加高度的封装性和注解用法），解耦得更彻底，职责更细分，易于其他框架联合使用（Retrofit + OkHttp + RxJava + Dagger2），使用方法多原理复杂存在一定的门槛；
3. 个人主观见解
Volley停止了更新，而OkHttp得到了官方的认可，并在不断优化。后面的新项目不建议使用了，推荐使用基于Retrofit2.0和OkHttp3的请求框架，老项目升级成本有点高，就不要再折腾了。但是没有最好只有更好后面还不知道出些什么逆天的网络框架，那如果随着版本迭代该使用新的网络框架怎么办？这是要思考的问题。
Retrofit因为也是square出的，所以大家可能对它更崇拜些。参与开源的有个哥们大家肯定认识就是Jake Wharton，其实Retrofit跟Volley是一个套路，但解耦的更彻底:比方说通过注解来配置请求参数，通过工厂来生成CallAdapter，Converter，你可以使用不同的请求适配器(CallAdapter), 比方说RxJava，Java8, Guava。你可以使用不同的反序列化工具(Converter)，比方说json, protobuff, xml, moshi等等。
超级解耦，里面涉及到超多设计模式，个人觉得是很经典的学习案例。虽然支持Java8， Guava你可能也不需要用到。xml，protobuff等数据格式你也可能不需要解析。but，万一遇到鬼了呢。至于性能上，个人觉得这完全取决于请求的client，也就是okhttp的性能，跟这些封装工具没太大关系。
至于RxJava，最好充分理解其原理之后再使用，别为了装B而人云亦云，特别team人数多的情况下，总得有个完全精通的吧，万一翻车掉坑里了呢？
总的来说，网络请求库没有说哪个最好，只有最合适，只有真的了解其使用场景才能很好的选择网络请求库，说了半天等于没说，总之选大多数人选择的，选简单易用的，就这么个标准。
既然第三方的如此多我们总得防止随着版本的迭代而去更换新的网络框架吧？那么下一期我们就来打造一套网络引擎用于随意切换第三方的开源框架。
所有分享大纲：2017Android进阶之路与你同行
视频讲解地址：周六晚上八点
