原文链接: 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)