android緩存詳解

Android緩存：

采用緩存，可以進一步大大緩解數據交互的壓力，又能提供一定的離線浏覽。下邊我簡略列舉一下緩存管理的適用環境：

1. 提供網絡服務的應用

2. 數據更新不需要實時更新，哪怕是3-5分鐘的延遲也是可以采用緩存機制。

3. 緩存的過期時間是可以接受的(類似網易的新聞閱讀,支持離線離線閱讀)

這樣所帶來的好處：

1. 減小服務器的壓力

2. 提高客戶端的響應速度(本地數據提取嘛)

3. 一定程度上支持離線浏覽(可以參考網易的那個新聞應用,個人感覺離線閱讀做得非常棒。)

一、緩存管理的方法

緩存管理的原理很簡：通過時間的設置來判斷是否讀取緩存還是重新下載；斷網下就沒什麼好說的，直接去緩存即可。如圖：

裡面會有一些細節的處理，後面會詳細闡述。基於這個原理，目前個人用過的兩種比較常見的緩存管理方法是:數據庫和文件(txt)。

二、數據庫(SQLite)緩存方式

這種方法是在下載完數據文件後，把文件的相關信息如url，路經，下載時間，過期時間等存放到數據庫，當然我個人建議把url作為唯一的標識。下次下載的時候根據url先從數據庫中查詢，如果查詢到當前時間並未過期，就根據路徑讀取本地文件，從而實現緩存的效果。

從實現上我們可以看到這種方法可以靈活存放文件的屬性，進而提供了很大的擴展性，可以為其它的功能提供一定的支持。

從操作上需要創建數據庫，每次查詢數據庫，如果過期還需要更新數據庫，清理緩存的時候還需要刪除數據庫數據，稍顯麻煩，而數據庫操作不當又容易出現一系列的性能，ANR問題，指針錯誤問題，實現的時候要謹慎，具體作的話，但也只是增加一個工具類或方法的事情。

還有一個問題，緩存的數據庫是存放在/data/data//databases/目錄下，是占用內存空間的，如果緩存累計，容易浪費內存，需要及時清理緩存。

當然這種方法從目前一些應用的實用上看，我沒有發現什麼問題,估計使用的量還比較少吧。

本文本人不太喜歡數據庫，原因操作麻煩，尤其是要自己寫建表那些語句，你懂的。我側重文件緩存方式。

三、文件緩存方式

這種方法，使用File.lastModified()方法得到文件的最後修改時間，與當前時間判斷是否過期，從而實現緩存效果。

實現上只能使用這一個屬性，沒有為其它的功能提供技術支持的可能。操作上倒是簡單，比較時間即可，而且取的數據也就是文件裡的JSON數據而已。本身處理也不容易帶來其它問題，代價低廉。

四、文件法緩存方式的兩點說明

1. 不同類型的文件的緩存時間不一樣。

笼統的說，不變文件的緩存時間是永久，變化文件的緩存時間是最大忍受不變時間。說白點，圖片文件內容是不變的，一般存在SD卡上直到被清理，我們是可以永遠讀取緩存的。配置文件內容是可能更新的，需要設置一個可接受的緩存時間。

2. 不同環境下的緩存時間標准不一樣。

無網絡環境下，我們只能讀取緩存文件，為了應用有東西顯示，沒有什麼過期之說了。

WiFi網絡環境下，緩存時間可以設置短一點，一是網速較快，而是流量不要錢。

3G流量環境下，緩存時間可以設置長一點，節省流量，就是節省金錢，而且用戶體驗也更好。

GPS就別說更新什麼的，已經夠慢的了。緩存時間能多長就多長把。

當然，作為一款好的應用，不會死定一種情況，針對於不同網絡變換不同形式的緩存功能是必須有的。而且這個時間根據自己的實際情況來設置：數據的更新頻率，數據的重要性等。

五、何時刷新

開發者一方面希望盡量讀取緩存，用戶一方面希望實時刷新，但是響應速度越快越好，流量消耗越少越好(關於這塊，的確開發中我沒怎麼想到，畢竟接口就是這麼多，現在公司的產品幾乎點一下就訪問一下，而且還有些雞肋多余的功能。慢慢修改哈哈)，是一個矛盾。

其實何時刷新我也不知道，這裡我提供兩點建議：

1. 數據的最長多長時間不變，對應用無大的影響。

比如，你的數據更新時間為4小時，則緩存時間設置為1~2小時比較合適。也就是更新時間/緩存時間=2,但用戶個人修改、網站編輯人員等一些人為的更新就另說。一天用戶總會看到更新，即便有延遲也好，視你產品的用途了；如果你覺得你是資訊類應用，再減少，2~4小時，如果你覺得數據比較重要或者比較受歡迎，用戶會經常把玩，再減少，1~2小時，依次類推。

當然類似這個界面的數據我認為更新時間能多長就多長了，盡可能長。如果你拿後邊那個有多少數據會變動來搪塞。我會告訴你：這個只是一個引導性的界面，你有多少款游戲跟用戶半毛錢關系都沒有，10億也跟他沒關，他只要確定這裡能找到他要找的 湯姆貓 就行。否則你又失去了一個用戶。

2. 提供刷新按鈕。

必要時候或最保險的方法使在相關界面提供一個刷新按鈕，或者當下流行的下拉列表刷新方式。為緩存，為加載失敗提供一次重新來過的機會。畢竟喝骨頭湯的時候，我也不介意碗旁多雙筷子。

總而言之，一切用戶至上，為了更好的用戶體驗，方法也會層出不窮。期待更好的辦法

（參考代碼：http://blog.csdn.net/lnb333666/article/details/8460159）

圖片緩存：

譯文：

加載一個Bitmap(位圖)到你的UI界面是非常簡單的，但是如果你要一次加載一大批，事情就變得復雜多了。在大多數的情況下(如ListView、GridView或者ViewPager這樣的組件)，屏幕上的圖片以及馬上要在滾動到屏幕上顯示的圖片的總量，在本質上是不受限制的。

像這樣的組件在子視圖移出屏幕後會進行視圖回收，內存使用仍被保留。但假設你不保留任何長期存活的引用，垃圾回收器也會釋放你所加載的Bitmap。這自然再好不過了，但是為了保持流暢且快速加載的UI，你要避免繼續在圖片回到屏幕上的時候重新處理。使用內存和硬盤緩存通常能解決這個問題，使用緩存允許組件快速加載並處理圖片。

這節課將帶你使用內存和硬盤緩存Bitmap，以在加載多個Bitmap的時候提升UI的響應性和流暢性。

使用內存緩存

以犧牲寶貴的應用內存為代價，內存緩存提供了快速的Bitmap訪問方式。LruCache類(可以在Support Library中獲取並支持到API Level 4以上，即1.6版本以上)是非常適合用作緩存Bitmap任務的，它將最近被引用到的對象存儲在一個強引用的LinkedHashMap中，並且在緩存超過了指定大小之後將最近不常使用的對象釋放掉。

注意：以前有一個非常流行的內存緩存實現是SoftReference(軟引用)或者WeakReference(弱引用)的Bitmap緩存方案，然而現在已經不推薦使用了。自Android2.3版本(API Level 9)開始，垃圾回收器更著重於對軟/弱引用的回收，這使得上述的方案相當無效。此外，Android 3.0(API Level 11)之前的版本中，Bitmap的備份數據直接存儲在本地內存中並以一種不可預測的方式從內存中釋放，很可能短暫性的引起程序超出內存限制而崩潰。

為了給LruCache選擇一個合適的大小，要考慮到很多原因，例如：

其他的Activity(活動)和(或)程序都是很耗費內存的嗎？

屏幕上一次會顯示多少圖片？有多少圖片將在屏幕上顯示？

設備的屏幕大小和密度是多少？一個超高清屏幕(xhdpi)的設備如Galaxy Nexus，相比Nexus S(hdpi)來說，緩存同樣數量的圖片需要更大的緩存空間。

Bitmap的尺寸、配置以及每張圖片需要占用多少內存？

圖片的訪問是否頻繁？有些會比其他的更加被頻繁的訪問到嗎？如果是這樣，也許你需要將某些圖片一直保留在內存中，甚至需要多個LruCache對象分配給不同組的Bitmap。

你能平衡圖片的質量和數量麼？有的時候存儲大量低質量的圖片更加有用，然後可以在後台任務中加載另一個高質量版本的圖片。

對於設置緩存大小，並沒有適用於所有應用的規范，它取決於你在內存使用分析後給出的合適的解決方案。緩存空間太小並無益處，反而會引起額外的開銷，而太大了又可能再次引起java.lang.OutOfMemory異常或只留下很小的空間給應用的其他程序運行。