Android緩存處理

Android緩存：

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

1. 提供網絡服務的應用

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

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

這樣所帶來的優勢：

1. 減少server的壓力

2. 提升client的響應速度(本地數據提取嘛)

3. 必定程度上支持離線瀏覽(可以參考網易的那個新聞應用,我的感受離線閱讀作得很棒。

)

 

1、緩存管理的方法

緩存管理的原理很是簡：經過時間的設置來推斷是否讀取緩存仍是又一次下載；斷網下就沒什麼好說的，直接去緩存就能夠。如圖：

裏面會有一些細節的處理。後面會具體闡述。

基於這個原理，眼下我的用過的兩種比較常見的緩存管理方法是:數據庫和文件(txt)。

 

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

這樣的方法是在下載完數據文件後。把文件的相關信息如url，路經，下載時間。過時時間等存放到數據庫，固然我我的建議把url做爲惟一的標識。下次下載的時候依據url先從數據庫中查詢，假設查詢到當前時間並未過時。就依據路徑讀取本地文件，從而實現緩存的效果。

從實現上咱們可以看到這樣的方法可以靈活存放文件的屬性，進而提供了很是大的擴展性，可以爲其餘的功能提供必定的支持。

從操做上需要建立數據庫。每次查詢數據庫，假設過時還需要更新數據庫，清理緩存的時候還需要刪除數據庫數據，稍顯麻煩，而數據庫操做不當又easy出現一系列的性能，ANR問題。指針錯誤問題，實現的時候要慎重。詳細做的話，但也僅僅是添加一個工具類或方法的事情。

另外一個問題，緩存的數據庫是存放在/data/data/<package>/databases/文件夾下，是佔用內存空間的，假設緩存累計。easy浪費內存，需要及時清理緩存。

固然這樣的方法從眼下一些應用的有用上看。我沒有發現什麼問題,預計使用的量還比較少吧。

本文本人不太喜歡數據庫，緣由操做麻煩，尤爲是要本身寫建表那些語句，你懂的。我側重文件緩存方式。

 

3、文件緩存方式

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

實現上僅僅能使用這一個屬性。沒有爲其餘的功能提供技術支持的可能。

操做上卻是簡單，比較時間就能夠。而且取的數據也就是文件中的JSON數據而已。

自己處理也不easy帶來其餘問題，代價低廉。

 

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

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

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

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

無網絡環境下。咱們僅僅能讀取緩存文件。爲了應用有東西顯示。沒有什麼過時之說了。

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

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

GPS就別說更新什麼的，已經夠慢的了。

緩存時間能多長就多長把。

固然。做爲一款好的應用。不會死定一種狀況，針對於不一樣網絡變換不一樣形式的緩存功能是必須有的。而且這個時間依據本身的實際狀況來設置：數據的更新頻率，數據的重要性等。

 

5、什麼時候刷新

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

事實上什麼時候刷新我也不知道，這裏我提供兩點建議：

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

       比方，你的數據更新時間爲4小時，則緩存時間設置爲1~2小時比較合適。也就是更新時間/緩存時間=2,但用戶我的改動、站點編輯人員等一些人爲的更新就另說。

一天用戶總會看到更新。即使有延遲也好，視你產品的用途了；假設你認爲你是資訊類應用，再下降，2~4小時，假設你認爲數據比較重要或者比較受歡迎，用戶會經常把玩，再下降，1~2小時，依次類推。

 固然相似這個界面的數據我以爲更新時間能多長就多長了。儘量長。

假設你拿後邊那個有多少數據會變更來搪塞。我會告訴你：這個僅僅是一個引導性的界面。你有多少款遊戲跟用戶半毛錢關係都沒有，10億也跟他沒關，他僅僅要肯定這裏能找到他要找的 湯姆貓 便可。

不然你又失去了一個用戶。

2. 提供刷新button。

       必要時候或最保險的方法使在相關界面提供一個刷新button。或者當下流行的下拉列表刷新方式。

爲緩存，爲載入失敗提供一次又一次來過的機會。畢竟喝骨頭湯的時候。我也不介意碗旁多雙筷子。

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

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

圖片緩存：

譯文：

        載入一個Bitmap(位圖)到你的UI界面是很easy的，但是假設你要一次載入一大批，事情就變得複雜多了。在大多數的狀況下(如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異常或僅僅留下很是小的空間給應用的其它程序執行。 

（參考網址：http://my.oschina.net/ryanhoo/blog/88443）