原文地址:http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0728/3228.html
原文:Glide – How Yelp’s Android App Loads Images
动态加载图片是很多安卓应用的基础。在Yelp(美国最大点评网站)中,图片在把消费者与商家联系起来的过程中至关重要。随着网络通信和硬件水平的越发强大,消费者对于图片数量和图片质量的期望日益增长。图片可以轻易的成为内存和网络流量的消耗大户,处理图片数据的下载和管理成为了一个让人望而却步的任务。我们探索了几种处理这个问题的解决办法,最终认为Glide在性能,使用方便性,稳定性上达到了相当好的平衡。
Glide最简单的使用案例就是从远程服务器或者本地文件系统加载图片,把它们放在磁盘与内存缓存中,然后加载到view上。它可以用在全市图片的app中,Glide为包含图片的滚动列表做了尽可能流畅的优化。
对象池
Glide原理的核心是为bitmap维护一个对象池。对象池的主要目的是通过减少大对象的分配以重用来提高性能(至于对象池的概览,可以查看 这个Android performance pattern 视频)。
Dalvik和ART虚拟机都没有使用compacting garbage collector,compacting garbage collector是一种模式,这种模式中GC会遍历堆,同时把活跃对象移到相邻内存区域,让更大的内存块可以用在后续的分配中。因为安卓没有这种模式,就可能会出现被分配的对象分散在各处,对象之间只有很小的内存可用。如果应用试图分配一个大于邻近的闲置内存块空间的对象,就会导致OutOfMemoryError,然后崩溃,即使总的空余内存空间大于对象的大小。
使用对象池还可以帮助提高滚动的性能,因为重用bitmap意味着更少的对象被创建与回收。垃圾回收会导致“停止一切(Stop The World)”事件,这个事件指的是回收器执行期间,所有线程(包括UI线程)都会暂停。这个时候,图像帧无法被渲染同时UI可能会停滞,这在滚动期间尤其明显。
Glide的使用
Glide使用起来很简单,而且不需要任何特别的配置就自动包含了bitmap pooling 。
1
2
|
DrawableRequestBuilder requestBuilder = Glide.
with
(context).load(imageUrl);
requestBuilder.into(imageView);
|
这就是加载一张图片的全部要求。就像安卓中的很多地方一样,with() 方法中的context到底是哪种类型是不清楚的。有一点很重要需要记住,就是传入的context类型影响到Glide加载图片的优化程度,Glide可以监视activity的生命周期,在activity销毁的时候自动取消等待中的请求。但是如果你使用Application context,你就失去了这种优化效果。
译者注:其实以上的代码是一种比较规范的写法,我们更熟悉的写法是:
1
2
3
|
Glide.
with
(context)
.into(ivImg);
|
优化特性
类似的是,如果相关的item已经滚出了屏幕的范围,Glide会自动取消列表中的悬着的图片请求 。因为绝大多数开发者都会在adapter中利用view的回收,Glide做到这点是通过在ImageView上设置一个tag,在加载另外一张图片之前检查这个tag,如果存在就取消第一次请求。
Glide提供了几个让你感觉图片加载速度变快的特性。第一个就是在图片显示在屏幕上之前就预先取出图片。它提供了一个ListPreloader类, 它被应该事先取出的item数目实例化。然后通过setOnScrollListener(OnScrollListener).被传递给ListView。你想在ListView之外也能预先取出图片吗?没问题,使用前面的builder对象就可以了,只需调用builder.downloadOnly()。
downloadOnly见:https://github.com/bumptech/glide/wiki/Loading-and-Caching-on-Background-Threads 。
我们发现了Glide提供的可以大大提高性能,稳定性的功能,以及安卓图片加载领域的一些设计哲学。这些特性和优化确实可以很好的将图片加载的体验变成一种享受。