OkHttp, Retrofit, Volley应该选择哪一个？

今天在知乎看到一个问题，忍不住去回答了。

也在这里写一份：okhttp,retrofit,android-async-http,volley应该选择哪一个？

我们来先说一个常识性的错误：

volley, retrofit, android-async-http 帮你封装了具体的请求，线程切换以及数据转换。

而OkHttp 是基于http协议封装的一套请求客户端，虽然它也可以开线程，但根本上它更偏向真正的请求，跟HttpClient, HttpUrlConnection的职责是一样的。

所以不要混淆。

-----以下纯个人主观见解

首先，我想即使你单纯使用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人数多的情况下，总得有个完全精通的吧，万一掉坑里了呢。。。

就说这么多啦，选最适合项目的，选大多数人选择的，选简单易用的，就这么个标准。

关于Retrofit源码分析可以看我另外一些文章
Retrofit分析-漂亮的解耦套路
Retrofit分析-经典设计模式案例

没耐心自己分析源码的同学，还可以参考Stay录制的视频版
Retrofit分析-漂亮的解耦套路(视频版)

另外怎么选择开源library，可以参考我的简书 这么多开源框架，该用哪个好？

这么多开源框架，该用哪个好？

想必这样的问题，大家都有疑惑过。我想大部分的疑惑无非以下几点：

1. 这个框架稳定吗？要是有bug怎么办？
2. 这个框架能满足我的所有需求吗？如果用到一半发现不适用该怎么办？
3. 这个框架耦合度高吗？是否能按照需求再去定制扩展？

先不看以上几点，我们先来说什么样的框架一定一定不要采纳：

1. 聚合型框架一定要放弃(比如Afinal，xUtils)，why？越是大而全，越容易牵一发而动全身，而且在框架世界里没有1+1>2这一说。相反的可读性差，耦合高，难扩展。是Afinal中的图片缓存好还是fresco，Picasso等好，不言而喻了吧？
2. github上last commit超过一年以上或者issues一大堆没fix的一定不要使用。这其中会有很多坑，要是出问题了，你都不知道找谁问。相应的，我最怕别人问的问题就是：Stay，你用过xxx框架么？帮我看看这问题吧。。
3. 仿 xxx UI效果大全，请慎重使用，如果可以，多跟产品经理沟通，尽量使用Material Design设计，另外可以参考InstaMaterial。别把大量时间跟精力花在了调UI效果上。UI性能与潜在bug是最不好调试的。大多数人对touch事件，view绘制都是一知半解。

通过上述条件，基本可以pass掉60%的开源项目。技术更新还是很快的，很多以前实现复杂或者根本无解的需求在未来都能有很好的解决方案。当你好几天都没找到你想要的解决方案，不妨去做沟通，选用其他替代需求。

如果你的项目在从0到1的初始阶段。

不妨先花上一周时间来做调研。这是款什么样的产品，做做竞品分析，考虑未来可能会有的扩展。根据产品业务来选择框架才是最优解。整体项目结构在未来重构的可能性非常小，所以一开始得尽可能得多去考虑扩展，不然会非常痛苦。

另外，你可以放心大胆的去尝试新出的开源lib，但凡写框架，都以简单易用为最根本目的，随着技术的推进，新出的框架也会吸收前人的经验而越来越成熟。而且用户量还很少，前期还有很长的过渡期，你有充足的时间来验证这个框架是否好用。

如果你的产品在从1到N的成熟阶段。

这个时候每个框架的更换都需要慎重考虑了，在用户基数大的情况下，任何一个bug都会导致严重的后果。尽可能的采用灰度发布，小规模测试后再统一升级。

比方说，你觉得universal-image-loader不够好用，经常oom，而且下载显示速度慢，那你可以选择fresco，glide对吧。那么，如果你以前没有对图片缓存框架进行一次再封装，尽量在你换框架时做一下封装。即：别在代码中显示的调用UniversalImageLoader.display()或fresco.display()，因为这些代码被调用的地方太多了，一旦你要换框架，那么要改的地方就炒鸡多。为了以后再发生这样的问题，不妨将它们再包一层。以后就轻松些。你说对吧。

或者说，IM的消息收发，现在有那么多平台的云推送，如何选择也是个问题，如果拿不准，那么在使用之前要尽量去解耦和，别显式调用任何云推送API，自己再包装一层，这样随便你怎么换，都不需要去更改业务逻辑，只用替换云平台API就ok了。

至于类似框架之间该如何选择，其实都差不多，有一些准则，仅供参考：

1. 如果框架A依赖另外的jar比较多，谨慎使用，学习也是要成本的。
2. 如果框架B没有详细的文档，谨慎使用，理由同上。
3. 如果框架C对你目前的App影响较大，改动的地方多，那么谨慎使用。
4. 如果框架D耦合度高，不方便扩展，谨慎使用。

差不多就这些，开源lib太多了，你mark的那些lib，能用上10%就非常不错了，能熟读1%的源码并扩展，也算是个senior developer了。

说了这么多，好像什么也没讲，为什么会写这篇文章，是有同学问我该如何选。

如果上述都不能理解，那我就直说该用什么好了。我项目里差不多都用自己写的框架，除了一些UI会找lib，能自己写的基本自己动手，毕竟架构再完善也很难去满足一个特定的需求。

以下纯推荐，不代表我用过，要是出问题了，别来责问我哈。

网络层： Retrofit或者Volley＋OkHttp，async-http-lib尽量就别用了，比较老。另外这些都需要再进一步扩展的，可以自己搜下，有用的就集成进去。
数据库： GreenDao, Ormlite或者Realm，要加密的话用SqlCipher
图片缓存： Fresco， glide，如果集成的效果不理想，多看看配置参数是否正确
工具： 查内存泄漏（leakcanary）异步通知（RxJava谨慎使用）数学计算表达式（expression4j）日期处理（joda time android）

至于UI层的lib我就不细说了，自行搜索。

知易行难，遇到问题耐心一些，在写代码之前多分析多google，务必把后期的重构花到前期去。