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)

    .load("http://inthecheesefactory.com/uploads/source/glidepicasso/cover.jpg")

    .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提供的可以大大提高性能，稳定性的功能，以及安卓图片加载领域的一些设计哲学。这些特性和优化确实可以很好的将图片加载的体验变成一种享受。 

来自：http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0728/3228.html