Glide的缓存策略
前言
众所周知，图片加载框架的基本模式就是三层缓存。内存、文件和网络。所有图片加载框架的基本思路都是先从内存中寻找需要的数据，如果找不到转到文件中寻找，还是找不到，才会去网络下载。但Glide在缓存策略上，花费了很多心思，从而使得其在加载图片过程中，对内存的使用量非常小。
本文将分享Glide在缓存策略上使用的技巧。
内存低消耗的秘密
在图片加载过程中，通常来讲，内存消耗的部分在于图片的解码。我们需要根据图片的尺寸，创建一个相应尺寸的Bitmap，这个Bitmap会存入内存缓存，然后通过setImageBitmap(Bitmap bitmap)显示出来。这个Bitmap在图片显示时，是一个不可避免的内存消耗。
在加载图片之后，内存缓存填满，我们可以将Bitmap从内存缓存中移出。但是，Bitmap还是存在于Java堆中，此时我们将失去对这个Bitmap的任何控制。（此时，我们无法判断Bitmap是否还在显示）。
下次我们再显示相同的图片，又需要创建新的Bitmap2，之前在Java堆中的Bitmap是否还在显示，是否已被回收也是未知。这里，我们可以想到，如果之前在Java堆中的Bitmap不再显示，也未被回收，是否可以拿来复用呢？
inBitmap
inBitmap
added in API level 11
Bitmap inBitmap
If set, decode methods that take the Options object will attempt to reuse this bitmap when loading content. If the decode operation cannot use this bitmap, the decode method will throw an
IllegalArgumentException. The current implementation necessitates that the reused bitmap be mutable, and the resulting reused bitmap will continue to remain mutable even when decoding a resource which would normally result in an immutable bitmap.You should still always use the returned Bitmap of the decode method and not assume that reusing the bitmap worked, due to the constraints outlined above and failure situations that can occur. Checking whether the return value matches the value of the inBitmap set in the Options structure will indicate if the bitmap was reused, but in all cases you should use the Bitmap returned by the decoding function to ensure that you are using the bitmap that was used as the decode destination.
复用之前Bitmap的想法虽好，但实施起来却是有难度的。如果这个Bitmap还在被显示，我们就拿去复用，无疑会造成显示的错误。那么，如何确定一个内存中的Bitmap是否正在显示，就成为了降低内存消耗的关键。
内存缓存的策略
既然要区分Bitmap是否正在显示。Glide的策略是从源头上，区分正在显示和没有显示的Bitmap。Glide将内存分为两块儿：ActiveCache和MemoryCache。MemoryCache中存放尚未显示的Bitmap，而ActiveCache中则存放正在显示的Bitmap的弱引用。
这样，当MemoryCache被填满时，多余的Bitmap被挤出MemoryCache。 同时会以可复用Bitmap的形式加入到BitmapPool中。
这样，我们可以在内存中保存一定量的可复用Bitmap。在解码图片时，即可使用BitmapPool中的Bitmap进行复用。
下面，我们就来看看，MemoryCache 和 ActiveCache之间是如何协作的。
从MemoryCache到ActiveCache
当Glide需要加载一张图片时，它优先会在ActiveCache中寻找有没有相同的图片。如果在ActiveCache中没有找到，Glide会到MemoryCache中寻找，再没有走文件，再没有走网络。不论哪一步，最终得到的图片，如果要被用于显示，一定会将其从MemoryCache中移除，并将其放到ActiveCache中。
从ActiveCache到MemoryCache
从ActiveCache离开，即Bitmap从显示到无需显示的过程。这一过程，通常有两种情景：
- ImageView需要显示其他图片
- ImageView自身被销毁
ImageView需要显示其他图片
在ImageView需要显示其他图片时，Glide会去检查Bitmap的引用计数。如果Bitmap的引用计数为0，则会将其从ActiveCache中引出，放入MemoryCache中。在放入MemoryCache的过程中，如果MemoryCache已满，可能会将MemoryCache中老的图片挤入BitmapPool中。
ImageView自身被销毁
在Android中，通常ImageView不会自己销毁，而是伴随着Fragment或Activity的生命周期。我们需要在ImageView销毁时去检查Bitmap的引用计数。如果Bitmap的引用计数为0，则会将其从ActiveCache中引出，放入MemoryCache中。因此，我们需要监听Fragment和Activity的生命周期，这个点值得单独一说。
监听生命周期
Glide.with(this).load("http://goo.gl/gEgYUd").into(imageView);
这是Glide的典型用法。在调用with方法时，我们传入了Activity或Fragment的实例。
Fragment不能直接从外部监听生命周期的变化，所以我们采用一种间接的办法。
我们新建一个没有界面的Fragment，称之ListenerFragment。将ListenerFragment作为ChildFragment加入被监听的Fragment中。由于ListenerFragment没有界面，那么ListenerFragment的生命周期一定与被监听的Fragment一致。
因此我们做成了这样的结构：
当FragmentA生命周期发生变化时，ListenerFragmentA也会随之变化。
同理，Glide对于生命周期的监听也是采用了这种方式。
通过这种方式，当Glide监听到相关的生命周期结束时，它可以将与该生命周期相关的ImageView全部释放掉，相关的图片资源，则全部放进内存缓存中。
综上，生命周期的监听、BitmapPool的复用、可见/不可见资源的分开缓存。是Glide缓存策略的精妙之处。
如有问题，欢迎指正。
