想必这样的问题，大家都有疑惑过。我想大部分的疑惑无非以下几点：
-
这个框架稳定吗？要是有bug怎么办？
-
这个框架能满足我的所有需求吗？如果用到一半发现不适用该怎么办？
-
这个框架耦合度高吗？是否能按照需求再去定制扩展？
先不看以上几点，我们先来说什么样的框架一定一定不要采纳：
-
聚合型框架一定要放弃(比如Afinal，xUtils)，why？越是大而全，越容易牵一发而动全身，而且在框架世界里没有1+1>2这一说。相反的可读性差，耦合高，难扩展。是Afinal中的图片缓存好还是fresco，Picasso等好，不言而喻了吧？
-
github上last commit超过一年以上或者issues一大堆没fix的一定不要使用。这其中会有很多坑，要是出问题了，你都不知道找谁问。相应的，我最怕别人问的问题就是：Stay，你用过xxx框架么？帮我看看这问题吧。。
-
仿 xxx UI效果大全，请慎重使用，如果可以，多跟产品经理沟通，尽量使用Material Design设计，另外可以参考InstaMaterial。别把大量时间跟精力花在了调UI效果上。UI性能与潜在bug是最不好调试的。大多数人对touch事件，view绘制都是一知半解。
通过上述条件，基本可以pass掉60%的开源项目。技术更新还是很快的，很多以前实现复杂或者根本无解的需求在未来都能有很好的解决方案。当你好几天都没找到你想要的解决方案，不妨去做沟通，选用其他替代需求。
如果你的项目在从0到1的初始阶段。
不妨先花上一周时间来做调研。这是款什么样的产品，做做竞品分析，考虑未来可能会有的扩展。根据产品业务来选择框架才是最优解。整体项目结构在未来重构的可能性非常小，所以一开始得尽可能得多去考虑扩展，不然会非常痛苦。
另外，你可以放心大胆的去尝试新出的开源lib，但凡写框架，都以简单易用为最根本目的，随着技术的推进，新出的框架也会吸收前人的经验而越来越成熟。而且用户量还很少，前期还有很长的过渡期，你有充足的时间来验证这个框架是否好用。
如果你的产品在从1到N的成熟阶段。
这个时候每个框架的更换都需要慎重考虑了，在用户基数大的情况下，任何一个bug都会导致严重的后果。尽可能的采用灰度发布，小规模测试后再统一升级。
比方说，你觉得universal-image-loader不够好用，经常oom，而且下载显示速度慢，那你可以选择fresco，picasso对吧。那么，如果你以前没有对图片缓存框架进行一次再封装，尽量在你换框架时做一下封装。即：别在代码中显示的调用UniversalImageLoader.display()或fresco.display()，因为这些代码被调用的地方太多了，一旦你要换框架，那么要改的地方就炒鸡多。为了以后再发生这样的问题，不妨将它们再包一层。以后就轻松些。你说对吧。
或者说，IM的消息收发，现在有那么多平台的云推送，如何选择也是个问题，如果拿不准，那么在使用之前要尽量去解耦和，别显式调用任何云推送API，自己再包装一层，这样随便你怎么换，都不需要去更改业务逻辑，只用替换云平台API就ok了。
至于类似框架之间该如何选择，其实都差不多，有一些准则，仅供参考：
-
如果框架A依赖另外的jar比较多，谨慎使用，学习也是要成本的。
-
如果框架B没有详细的文档，谨慎使用，理由同上。
-
如果框架C对你目前的App影响较大，改动的地方多，那么谨慎使用。
-
如果框架D耦合度高，不方便扩展，谨慎使用。
差不多就这些，开源lib太多了，你mark的那些lib，能用上10%就非常不错了，能熟读1%的源码并扩展，也算是个senior developer了。
说了这么多，好像什么也没讲，为什么会写这篇文章，是有同学问我该如何选。
如果上述都不能理解，那我就直说该用什么好了。我项目里差不多都用自己写的框架，除了一些UI会找lib，能自己写的基本自己动手，毕竟架构再完善也很难去满足一个特定的需求。
以下纯推荐，不代表我用过，要是出问题了，别来责问我哈。
网络层： Retrofit或者Volley＋OkHttp，async-http-lib尽量就别用了，比较老。另外这些都需要再进一步扩展的，可以自己搜下，有用的就集成进去。
数据库： Ormlite或者Realm，要加密的话用SqlCipher
图片缓存： Fresco， Picasso，如果集成的效果不理想，多看看配置参数是否正确
工具： 查内存泄漏（leakcanary）异步通知（RxJava谨慎使用）数学计算表达式（expression4j）日期处理（joda time）
至于UI层的lib我就不细说了，自行搜索。
知易行难，遇到问题耐心一些，在写代码之前多分析多google，务必把后期的重构花到前期去。
