Android Glide數據更新及內存緩存、硬盤緩存清理

[轉] 原文 

 

                                        Android Glide數據更新及內存緩存、硬盤緩存清理

Android的Glide在加載圖片時候內部默認使用了緩存機制，Glide的緩存機制分爲兩級，第一級是內存緩存，而後第二級是硬盤緩存。緩存的過程首先是在內存中緩存，而後將加載的圖片資源緩存到硬盤，這樣就能夠在隨後的再次加載中使用緩存了，Glide使用緩存時候首先要檢查內存這一層級是否緩存了相應的緩存，若是有，則直接使用，若是沒有，則深刻到硬盤緩存中檢查是否有，若是有，則加載之，若是到這一步驟尚未，那麼就只能做爲一個全新的資源加載了。
從這個過程當中，Glide使用緩存無疑大大提升了上層代碼的性能，可是，有些狀況下，這種緩存策略則可能並不適用。好比，APP中有一個頭像，該頭像是從一個固定連接http://xxx.xxx.jpg讀取，假設代碼第一次讀取後，緩存到了本地。然而，幾分鐘後該圖片更新了，可是連接仍然是http://xxx.xxx.jpg。隨後，假設，三小時或三天或三十天後一樣的連接http://xxx.xxx.jpg讀取，此時Glide加載時候檢查緩存，發現針對http://xxx.xxx.jpg的資源已經緩存，那麼Glide再也不從服務器讀取，而是直接加載本地緩存使用，這樣就形成了Glide加載出來的圖片資源不是最新的。
總結：Glide的緩存機制雖然提高了性能，可是若是針對固定資源路徑的請求，將致使請求獲得的資源是緩存的，這樣就不能保證最新。換句話說，若是給定資源地址下的資源的頻繁更新的，而資源地址是固定，則Glide此時的緩存策略就顯得不太合適。
致使這種問題的緣由有二：
一， Glide自己使用了緩存。
二， Glide在緩存資源使用<K,V>鍵值對模型，若是每次都使用http://xxx.xxx.jpg這個URL，那麼鍵相同，意味着Glide匹配鍵時候，永遠能夠從緩存中返回鍵對應的值。

針對這個問題的解決方案：
解決方案1：
從Glide提供的緩存鍵值對<K,V>結構模型入手，重寫緩存的<K,V>鍵值策略，就能夠避免相同資源地址下資源更新問題了，可是這種方案實現比較複雜，也無十分必要。不推薦，除非必需。

解決方案2：
Glide.get(this).clearMemory();
清理內存中的緩存。

Glide.get(this).clearDiskCache();
清理硬盤中的緩存。

以上兩個方法清除全局的內存緩存和硬盤緩存，雖然能夠一勞永逸的解決緩存致使的資源陳舊問題，可是將嚴重影響全局性能，因此慎用，除非是在APP總體要作全新的開始或者恢復原始狀態，不然儘可能避免使用。

解決方案3（推薦）：
代碼形如：

[java]  view plain  copy

1. ImageView image= (ImageView) findViewById(R.id.image);  
2.         Glide.with(this).load("http://avatar.csdn.net/9/7/A/1_zhangphil.jpg")  
3.                 .skipMemoryCache(true)  
4.                 .diskCacheStrategy(DiskCacheStrategy.NONE)  
5.                 .into(image);  

關鍵代碼：skipMemoryCache(true).diskCacheStrategy(DiskCacheStrategy.NONE)
skipMemoryCache(true) ，跳過內存緩存。
diskCacheStrategy(DiskCacheStrategy.NONE) ，不要在disk硬盤中緩存。

這兩個函數同時聯合使用，使得Glide針對這一次的資源加載放棄內存緩存和硬盤緩存，至關於一次全新的請求。這樣就迫使Glide從給定的資源地址發起全新的數據加載，而非從舊有的緩存中取緩存使用。

附錄：
1，《Android圖片加載與緩存開源框架：Android Glide》連接：http://blog.csdn.net/zhangphil/article/details/45535693 
2，《Android Glide加載圖片時轉換爲圓形、圓角、毛玻璃等圖片效果》連接：http://blog.csdn.net/zhangphil/article/details/52806374