动态加载图片是很多安卓应用的基础。在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 。
DrawableRequestBuilder requestBuilder = Glide.with(context).load(imageUrl); requestBuilder.into(imageView);
这就是加载一张图片的全部要求。就像安卓中的很多地方一样，with() 方法中的context到底是哪种类型是不清楚的。有一点很重要需要记住，就是传入的context类型影响到Glide加载图片的优化程度，Glide可以监视activity的生命周期，在activity销毁的时候自动取消等待中的请求。但是假如你使用Application context，你就失去了这种优化效果。
译者注：其实以上的代码是一种比较规范的写法，我们更熟悉的写法是：
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提供的可以大大提高性能，稳定性的功能，以及安卓图片加载领域的一些设计哲学。这些特性和优化确实可以很好的将图片加载的体验变成一种享受。