图片框架的可能更换

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

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

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

1. 如果框架A依赖另外的jar比较多，谨慎使用，学习也是要成本的。

2. 如果框架B没有详细的文档，谨慎使用，理由同上。

3. 如果框架C对你目前的App影响较大，改动的地方多，那么谨慎使用。

4. 如果框架D耦合度高，不方便扩展，谨慎使用。

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

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