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緩存策略的精妙之處。
如有問題，歡迎指正。
