Android緩衝處理

標籤：data   相關資訊   href   weakref   evel   效果   常見   服務   品質   

Android緩衝：

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

1. 提供網路服務的應用

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

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

這樣所帶來的優點：

1. 減小server的壓力

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

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

)

 

一、緩衝管理的方法

緩衝管理的原理非常簡：通過時間的設定來推斷是否讀取緩衝還是又一次下載；斷網下就沒什麼好說的，直接去緩衝就可以。

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

基於這個原理，眼下個人用過的兩種比較常見的緩衝管理方法是:資料庫和檔案(txt)。

 

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

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

從實現上我們能夠看到這樣的方法能夠靈活存放檔案的屬性，進而提供了非常大的擴充性，能夠為其他的功能提供一定的支援。

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

另一個問題，緩衝的資料庫是存放在/data/data/<package>/databases/檔案夾下，是佔用記憶體空間的，假設緩衝累計。easy浪費記憶體，須要及時清理緩衝。

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

本文本人不太喜歡資料庫，原因操作麻煩，尤其是要自己寫建表那些語句，你懂的。我側重檔案快取方式。

 

三、檔案快取方式

這樣的方法，使用File.lastModified()方法得到檔案的最後改動時間。與目前時間推斷是否到期，從而實現緩衝效果。

實現上僅僅能使用這一個屬性。沒有為其他的功能提供支援人員的可能。

操作上倒是簡單，比較時間就可以。並且取的資料也就是檔案中的JSON資料而已。

本身處理也不easy帶來其他問題，代價低廉。

 

四、檔案法緩衝方式的兩點說明

1. 不同類型的檔案的緩衝時間不一樣。

籠統的說。不變檔案的緩衝時間是永久，變化檔案的緩衝時間是最大忍受不變時間。說白點，圖片檔案內容是不變的，一般存在SD卡上直到被清理。我們是能夠永遠讀取緩衝的。設定檔內容是可能更新的，須要設定一個可接受的緩衝時間。

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

無網路環境下。我們僅僅能讀取快取檔案。為了應用有東西顯示。沒有什麼到期之說了。

WiFi網路環境下，緩衝時間能夠設定短一點，一是網速較快，而是流量不要錢。

3G流量環境下，緩衝時間能夠設定長一點。節省流量。就是節省金錢，並且使用者體驗也更好。

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

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

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

 

五、何時重新整理

       開發人員一方面希望盡量讀取緩衝，使用者一方面希望即時重新整理。可是響應速度越快越好，流量消耗越少越好(關於這塊。的確開發中我沒怎麼想到。畢竟介面就是這麼多。如今公司的產品差點兒點一下就訪問一下，並且還有些雞肋多餘的功能。慢慢改動哈哈)，是一個矛盾。

事實上何時重新整理我也不知道，這裡我提供兩點建議：

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任務的，它將近期被引用到的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異常或僅僅留下非常小的空間給應用的其它程式執行。 

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

Android緩衝處理