版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/u011033906/article/details/89762086
原文链接： https://www.jianshu.com/p/f3227c7008d4
在这仅作一个自己的学习总结
不能用的一些框架
- 聚合型框架一定要放弃
- github上last commit超过一年以上或者issues一大堆没fix的一定不要使用
- xxx UI效果大全，请慎重使用，如果可以，多跟产品经理沟通，尽量使用Material Design设计，另外可以参考InstaMaterial
如果你的项目在从0到1的初始阶段
先做调研。这是款什么样的产品，考虑未来可能会有的扩展。根据产品业务来选择框架才是最优解。整体项目结构在未来重构的可能性非常小，所以一开始得尽可能得多去考虑扩展，不然会非常痛苦。
另外，你可以放心大胆的去尝试新出的开源lib，但凡写框架，都以简单易用为最根本目的，随着技术的推进，新出的框架也会吸收前人的经验而越来越成熟。而且用户量还很少，前期还有很长的过渡期，你有充足的时间来验证这个框架是否好用
总结：
- 根据产品业务来选择框架才是最优解
- 整体项目结构在未来重构的可能性非常小，所以一开始得尽可能得多去考虑扩展
- 放心大胆的去尝试新出的开源lib，但凡写框架，都以简单易用为最根本目的
如果你的产品在从1到N的成熟阶段。
这个时候每个框架的更换都需要慎重考虑了，在用户基数大的情况下，任何一个bug都会导致严重的后果。尽可能的采用灰度发布，小规模测试后再统一升级。
比方说，你觉得 universal-image-loader 不够好用，经常 oom，而且下载显示速度慢，那你可以选择fresco，glide对吧。那么，如果你以前没有对图片缓存框架进行一次再封装，尽量在你换框架时做一下封装。即：别在代码中显示的调用 UniversalImageLoader.display() 或 fresco.display()，因为这些代码被调用的地方太多了，一旦你要换框架，那么要改的地方就炒鸡多。为了以后再发生这样的问题，不妨将它们再包一层。以后就轻松些。你说对吧。
或者说，IM 的消息收发，现在有那么多平台的云推送，如何选择也是个问题，如果拿不准，那么在使用之前要尽量去解耦和，别显式调用任何云推送API，自己再包装一层，这样随便你怎么换，都不需要去更改业务逻辑，只用替换云平台API就ok了。
总结：
- 尽可能的采用灰度发布，小规模测试后再统一升级
- 使用之前要尽量去解耦和，别显式调用任何云推送
API，自己再包装一层
一些准则
- 如果框架A依赖另外的jar比较多，谨慎使用，学习也是要成本的。
- 如果框架B没有详细的文档，谨慎使用，理由同上。
- 如果框架C对你目前的App影响较大，改动的地方多，那么谨慎使用。
- 如果框架D耦合度高，不方便扩展，谨慎使用。
推荐
- 网络层： Retrofit或者Volley＋OkHttp。另外这些都需要再进一步扩展的，有用的就集成进去。
- 数据库： GreenDao, Ormlite或者Realm，要加密的话用SqlCipher
- 图片缓存： Fresco， glide，如果集成的效果不理想，多看看配置参数是否正确
- 工具： 查内存泄漏（leakcanary）异步通知（RxJava谨慎使用）数学计算表达式（expression4j）日期处理（joda time android）