贝壳找房安卓端用Glide替换Picasso

现状

操作步骤：打开贝壳找房，设置城市为“徐州”， 然后点击“二手房”图标进入“二手房列表页”， 向上滑动列表。

使用Picasso

使用Glide

上图是Android Profiler抓取的运行时内存， 使用Picasso时Java堆占用了220.7M字节， 使用Glide时Java堆占用了85.8M。 直观上内存使用减少了一半。

Android8.0及后续版本将Bitmap缓存在Native层， 理论上不会因为缓存图片导致OOM； 而贝壳找房安卓app用户Android8.0以下占比64%左右， 优化图片内存管理对这部分用户有意义。

改造成本

因为Glide比Picasso多了一个Context参数， 所有原来调用Picasso方法的地方都要修改。

适配Glide

二手房业务都使用LJImageLoader.java显示图片， 只需要扩展方法加个Context参数， 调用时多传入一个context即可。

原理

Glide在内存上使用二级缓存， 即当前正在使用的activeResources(其实就是个map，保存了图片的弱引用)和LruCache(界面未显示的图片)。 在测试机魅族上LruCache默认只有16M字节， 而Picasso的LruCache在160M左右。
列表向上滑动时观察内存基本不变， 这是因为Glide及时回收了内存。

滑动listview/recyclerview

复用item使用相同ImageView显示图片时会先释放其在Glide中的资源

因为ListView复用了view，在数据不变情况下，内存中ListView缓存的itemView个数是固定的， 从而Glide的activeResources缓存的个数也是固定的。 前提：ListView数据个数很多且要向上滑动一下。

对于ListView滑动时activeResources数量是不变的

在滑动列表时，将移出屏幕item的图片从activeResources中移除，并添加到LruCache中， 如果LruCache达到上限则自动清理。

Glide比Picasso的2个优势：
1、因为Glide支持Activity/Fragment的生命周期， Glide在生命周期onStart函数里注册连接状态变化广播并继续处理当前界面图片任务； 在生命周期onStop函数里取消注册连接状态广播并暂停处理当前界面图片任务； 在生命周期onDestroy函数里将当前界面使用的activeResources里的资源移出并添加到LruCache中。

2、当前Activity A有很多个图片， 这时再启动Activity B、C、D， 虚拟机可能会gc隐藏的activity，从而释放当前app的内存。。

展望

安卓主流图片三方框架Glide、Picasso、Fresco各有特点， 而Glide是谷歌推荐的图片库。 贝壳找房app安卓端用Glide替换Picasso的成本较小， 收益是64%使用android8.0以下用户不再出现OOM问题。