android緩衝詳解

標籤：開發人員   解決方案   緩衝機制   使用者體驗   

Android緩衝：

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

1. 提供網路服務的應用

2. 資料更新不需要即時更新，哪怕是3-5分鐘的延遲也是可以採用緩衝機制。

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

這樣所帶來的好處：

1. 減小伺服器的壓力

2. 提高用戶端的響應速度(本機資料提取嘛)

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

 

一、緩衝管理的方法

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

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

 

二、資料庫(SQLite)緩衝方式

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

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

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

還有一個問題，緩衝的資料庫是存放在/data/data/<package>/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任務的，它將最近被引用到的Object Storage Service在一個強引用的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異常或只留下很小的空間給應用的其他程式運行。 

android緩衝詳解