标签（空格分隔）： Android
我们来先说一个常识性的错误：
volley, retrofit, android-async-http 帮你封装了具体的请求，线程切换以及数据转换。他们是网络底层实现库的封装库
而OkHttp 是基于http协议封装的一套请求客户端，虽然它也可以开线程，但根本上它更偏向真正的请求，跟HttpClient,HttpUrlConnection的职责是一样的。所以不要混淆
网络底层的实现库：
HttpURLConnection：是Java中的标准类，是对Java中socket的封装。
Httpclient：是Apache的开源框架，是对HttpURLConnection的封装。
Okhttp：是Square公司开发的开源网络访问框架，是对socket的封装。
以下是Stay的见解：
作者：Stay Zhang
链接：https://www.zhihu.com/question/35189851/answer/93973482
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
首先，我想即使你单纯使用OkHttp，还是会再包一层的，这样就等价于Volley之流的框架，只是封装的好与坏而已。
android-async-http内部实现是基于HttpClient, 想必你肯定知道6.0之后HttpClient是不是系统自带的了，不过它在最近的更新中将HttpClient的所有代码copy了一份进来，所以还能使用。
Volley是官方出的，volley在设计的时候是将具体的请求客户端做了下封装：HurlStack，也就是说可以支持HttpUrlConnection, HttpClient, OkHttp，相当于模版模式吧，这样解耦还是非常方便的，可以随意切换，如果你之前使用过Volley，并习惯使用，那直接写个OkHttp扩展就行了。
Retrofit因为也是square出的，所以大家可能对它更崇拜些。Retrofit的跟Volley是一个套路，但解耦的更彻底:比方说通过注解来配置请求参数，通过工厂来生成CallAdapter，Converter，你可以使用不同的请求适配器(CallAdapter), 比方说RxJava，Java8, Guava。你可以使用不同的反序列化工具(Converter)，比方说json, protobuff, xml, moshi等等。
炒鸡解耦，里面涉及到超多设计模式，个人觉得是很经典的学习案例。虽然支持Java8， Guava你可能也不需要用到。xml，protobuff等数据格式你也可能不需要解析。but，万一遇到鬼了呢。
至于性能上，个人觉得这完全取决于请求client，也就是okhttp的性能，跟这些封装工具没太大关系。
至于RxJava，最好充分理解其原理之后再使用，别人云亦云，特别team人数多的情况下，总得有个完全精通的吧，万一掉坑里了呢。。。
就说这么多啦，选最适合项目的，选大多数人选择的，选简单易用的，就这么个标准。
一片综合性很强的文章，包括Http原理，各个网络库比较，图片库比较，图床
总结
终于到了总结的时候了，一般来说，这都是干货的时候，哈哈～
Volley对比优势
1.缓存处理；Volley自己就提供了一套完整的缓存处理方案，默认使用文件存储到磁盘中，并且提供了TTL SOFTTTL这么体贴入微的机制；一个Request可能存在两个Response,对于需要显示缓存，再显示网络数据的场景真是爽的不要不要的。而Retrofit中并没有提供任何和缓存相关的方案。
2.代码简单，可读性高。Volley的代码是写的如此的直接了当，让你看起代码来都不需要喝口茶，这样的好处是我们我们需要修改代码时不太容易引入bug....囧
3.同一个请求如果同时都在发送，那么实际上只会有一个请求真正发出去， 其它的请求会等待这个结果回来，算小小优化吧。实际上这种场景不是很多哈，如果有，可能是你代码有问题...
4.请求发送的时候提供了优先级的概念，但是是只保证顺序出去，不保证顺序回来，然并卵。
5.支持不同的Http客户端实现，默认提供了HttpClient和HttpUrlConnection的实现，而Retrofit在2.0版本之后，锁死在OkHttp上了。
6.支持请求取消
Retrofit对比优势
1.发送请求真简单，定义一个方法就可以了，这么简单的请求框架还有谁？Volley?
2.较好的可扩展性，Volley中每一个新建一个Request时都需要指定一个父类，告知序列化数据的方式，而Retrofit中只需要在配置时，指定各种转换器即可。CallAdapter的存在，可以使你随意代理调用的Call，不错不错。。。
3.OkHttpClient自带并发光环，而Volley中的工作线程是自己维护的，那么就有可能存在线程由于异常退出之后，没有下一个工作线程补充的风险(线程池可以弥补这个缺陷)，这在Retrofit中不存在，因为即使有问题，这个锅也会甩给OkHttp，嘿嘿
4.支持请求取消
再次说明的是，Retrofit没有对缓存提供任何额外支持，也就是说它只能通过HTTP的Cache control做文件存储，这样就会有一些问题：
1.需要Server通过Cache control头部来控制缓存，需要修改后台代码
2.有些地方比较适合使用数据库来存储，比如关系存储，此时，Retrofit就无能为力了
3.缓存不在我们的控制范围之内，而是完全通过OkHttp来管理，多少有些不便，比如我们要删除某一个指定的缓存，或者更新某一个指定缓存，代码写起来很别扭(自己hack请求头里面的cache contrl)
而在我们项目的实际使用过程中，缓存是一个比较重要的角色，Retrofit对缓存的支持度不是很好，真是让人伤心。。。
但是，我们还是觉得在使用中Retrofit真心比较方便，容易上手，通过注解代码可读性和可维护性提升了N个档次，几乎没有样板代码(好吧，如果你觉得每个请求都需要定义一个方法，那这也算。。)，所以最后的决定是选择Retrofit。
有人说了，Volley中的两次响应和缓存用起来很happy怎么办？嗯，我们会修改Retrofit，使它支持文件存储和ORM存储，并将Volley的缓存 网络两次响应回调移接过来，这个项目正在测试阶段，待我们项目做完小白鼠，上线稳定之后，我会把代码开源，大家敬请关注。
文／楚云之南（简书作者）
原文链接：//www.greatytc.com/p/07dac989272c
著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。
