Glide的緩存策略

前言

眾所周知，圖片加載框架的基本模式就是三層緩存。內(nèi)存、文件和網(wǎng)絡(luò)。所有圖片加載框架的基本思路都是先從內(nèi)存中尋找需要的數(shù)據(jù)，如果找不到轉(zhuǎn)到文件中尋找，還是找不到，才會(huì)去網(wǎng)絡(luò)下載。但Glide在緩存策略上，花費(fèi)了很多心思，從而使得其在加載圖片過程中，對(duì)內(nèi)存的使用量非常小。

本文將分享Glide在緩存策略上使用的技巧。

內(nèi)存低消耗的秘密

在圖片加載過程中，通常來講，內(nèi)存消耗的部分在于圖片的解碼。我們需要根據(jù)圖片的尺寸，創(chuàng)建一個(gè)相應(yīng)尺寸的Bitmap，這個(gè)Bitmap會(huì)存入內(nèi)存緩存，然后通過setImageBitmap(Bitmap bitmap)顯示出來。這個(gè)Bitmap在圖片顯示時(shí)，是一個(gè)不可避免的內(nèi)存消耗。

在加載圖片之后，內(nèi)存緩存填滿，我們可以將Bitmap從內(nèi)存緩存中移出。但是，Bitmap還是存在于Java堆中，此時(shí)我們將失去對(duì)這個(gè)Bitmap的任何控制。（此時(shí)，我們無法判斷Bitmap是否還在顯示）。

下次我們?cè)亠@示相同的圖片，又需要?jiǎng)?chuàng)建新的Bitmap2，之前在Java堆中的Bitmap是否還在顯示，是否已被回收也是未知。這里，我們可以想到，如果之前在Java堆中的Bitmap不再顯示，也未被回收，是否可以拿來復(fù)用呢？

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.

復(fù)用之前Bitmap的想法雖好，但實(shí)施起來卻是有難度的。如果這個(gè)Bitmap還在被顯示，我們就拿去復(fù)用，無疑會(huì)造成顯示的錯(cuò)誤。那么，如何確定一個(gè)內(nèi)存中的Bitmap是否正在顯示，就成為了降低內(nèi)存消耗的關(guān)鍵。

內(nèi)存緩存的策略

既然要區(qū)分Bitmap是否正在顯示。Glide的策略是從源頭上，區(qū)分正在顯示和沒有顯示的Bitmap。Glide將內(nèi)存分為兩塊兒：ActiveCache和MemoryCache。MemoryCache中存放尚未顯示的Bitmap，而ActiveCache中則存放正在顯示的Bitmap的弱引用。

這樣，當(dāng)MemoryCache被填滿時(shí)，多余的Bitmap被擠出MemoryCache。 同時(shí)會(huì)以可復(fù)用Bitmap的形式加入到BitmapPool中。

這樣，我們可以在內(nèi)存中保存一定量的可復(fù)用Bitmap。在解碼圖片時(shí)，即可使用BitmapPool中的Bitmap進(jìn)行復(fù)用。

下面，我們就來看看，MemoryCache 和 ActiveCache之間是如何協(xié)作的。

從MemoryCache到ActiveCache

當(dāng)Glide需要加載一張圖片時(shí)，它優(yōu)先會(huì)在ActiveCache中尋找有沒有相同的圖片。如果在ActiveCache中沒有找到，Glide會(huì)到MemoryCache中尋找，再?zèng)]有走文件，再?zèng)]有走網(wǎng)絡(luò)。不論哪一步，最終得到的圖片，如果要被用于顯示，一定會(huì)將其從MemoryCache中移除，并將其放到ActiveCache中。

從ActiveCache到MemoryCache

從ActiveCache離開，即Bitmap從顯示到無需顯示的過程。這一過程，通常有兩種情景：

• ImageView需要顯示其他圖片
• ImageView自身被銷毀

ImageView需要顯示其他圖片

在ImageView需要顯示其他圖片時(shí)，Glide會(huì)去檢查Bitmap的引用計(jì)數(shù)。如果Bitmap的引用計(jì)數(shù)為0，則會(huì)將其從ActiveCache中引出，放入MemoryCache中。在放入MemoryCache的過程中，如果MemoryCache已滿，可能會(huì)將MemoryCache中老的圖片擠入BitmapPool中。

ImageView自身被銷毀

在Android中，通常ImageView不會(huì)自己銷毀，而是伴隨著Fragment或Activity的生命周期。我們需要在ImageView銷毀時(shí)去檢查Bitmap的引用計(jì)數(shù)。如果Bitmap的引用計(jì)數(shù)為0，則會(huì)將其從ActiveCache中引出，放入MemoryCache中。因此，我們需要監(jiān)聽Fragment和Activity的生命周期，這個(gè)點(diǎn)值得單獨(dú)一說。

監(jiān)聽生命周期

 Glide.with(this).load("http://goo.gl/gEgYUd").into(imageView);

這是Glide的典型用法。在調(diào)用with方法時(shí)，我們傳入了Activity或Fragment的實(shí)例。
Fragment不能直接從外部監(jiān)聽生命周期的變化，所以我們采用一種間接的辦法。

我們新建一個(gè)沒有界面的Fragment，稱之ListenerFragment。將ListenerFragment作為ChildFragment加入被監(jiān)聽的Fragment中。由于ListenerFragment沒有界面，那么ListenerFragment的生命周期一定與被監(jiān)聽的Fragment一致。

因此我們做成了這樣的結(jié)構(gòu)：

當(dāng)FragmentA生命周期發(fā)生變化時(shí)，ListenerFragmentA也會(huì)隨之變化。
同理，Glide對(duì)于生命周期的監(jiān)聽也是采用了這種方式。

通過這種方式，當(dāng)Glide監(jiān)聽到相關(guān)的生命周期結(jié)束時(shí)，它可以將與該生命周期相關(guān)的ImageView全部釋放掉，相關(guān)的圖片資源，則全部放進(jìn)內(nèi)存緩存中。

綜上，生命周期的監(jiān)聽、BitmapPool的復(fù)用、可見/不可見資源的分開緩存。是Glide緩存策略的精妙之處。

如有問題，歡迎指正。