91亚洲精华国内精华精华液_国产高清在线精品一区不卡_精品特级一级毛片免费观看_欧美日韩中文制服有码_亚洲精品无码你懂的网站369

采用緩存，可以進(jìn)一步大大緩解數(shù)據(jù)交互的壓力，又能提供一定的離線瀏覽。下邊我簡略列舉一下緩存管理的適用環(huán)境：

1. 提供網(wǎng)絡(luò)服務(wù)的應(yīng)用

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

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

這樣所帶來的好處：

1. 減小服務(wù)器的壓力

2. 提高客戶端的響應(yīng)速度(本地?cái)?shù)據(jù)提取嘛)

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

一、緩存管理的方法

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

里面會(huì)有一些細(xì)節(jié)的處理，后面會(huì)詳細(xì)闡述?；谶@個(gè)原理，目前個(gè)人用過的兩種比較常見的緩存管理方法是:數(shù)據(jù)庫和文件(txt)。

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

這種方法是在下載完數(shù)據(jù)文件后，把文件的相關(guān)信息如url，路經(jīng)，下載時(shí)間，過期時(shí)間等存放到數(shù)據(jù)庫，當(dāng)然我個(gè)人建議把url作為唯一的標(biāo)識(shí)。下次下載的時(shí)候根據(jù)url先從數(shù)據(jù)庫中查詢，如果查詢到當(dāng)前時(shí)間并未過期，就根據(jù)路徑讀取本地文件，從而實(shí)現(xiàn)緩存的效果。

從實(shí)現(xiàn)上我們可以看到這種方法可以靈活存放文件的屬性，進(jìn)而提供了很大的擴(kuò)展性，可以為其它的功能提供一定的支持。

從操作上需要?jiǎng)?chuàng)建數(shù)據(jù)庫，每次查詢數(shù)據(jù)庫，如果過期還需要更新數(shù)據(jù)庫，清理緩存的時(shí)候還需要?jiǎng)h除數(shù)據(jù)庫數(shù)據(jù)，稍顯麻煩，而數(shù)據(jù)庫操作不當(dāng)又容易出現(xiàn)一系列的性能，ANR問題，指針錯(cuò)誤問題，實(shí)現(xiàn)的時(shí)候要謹(jǐn)慎，具體作的話，但也只是增加一個(gè)工具類或方法的事情。

還有一個(gè)問題，緩存的數(shù)據(jù)庫是存放在/data/data/<package>/databases/目錄下，是占用內(nèi)存空間的，如果緩存累計(jì)，容易浪費(fèi)內(nèi)存，需要及時(shí)清理緩存。

當(dāng)然這種方法從目前一些應(yīng)用的實(shí)用上看，我沒有發(fā)現(xiàn)什么問題,估計(jì)使用的量還比較少吧。

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

三、文件緩存方式

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

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

四、文件法緩存方式的兩點(diǎn)說明

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

籠統(tǒng)的說，不變文件的緩存時(shí)間是永久，變化文件的緩存時(shí)間是最大忍受不變時(shí)間。說白點(diǎn)，圖片文件內(nèi)容是不變的，一般存在SD卡上直到被清理，我們是可以永遠(yuǎn)讀取緩存的。配置文件內(nèi)容是可能更新的，需要設(shè)置一個(gè)可接受的緩存時(shí)間。

2. 不同環(huán)境下的緩存時(shí)間標(biāo)準(zhǔn)不一樣。

無網(wǎng)絡(luò)環(huán)境下，我們只能讀取緩存文件，為了應(yīng)用有東西顯示，沒有什么過期之說了。

WiFi網(wǎng)絡(luò)環(huán)境下，緩存時(shí)間可以設(shè)置短一點(diǎn)，一是網(wǎng)速較快，而是流量不要錢。

3G流量環(huán)境下，緩存時(shí)間可以設(shè)置長一點(diǎn)，節(jié)省流量，就是節(jié)省金錢，而且用戶體驗(yàn)也更好。

GPS就別說更新什么的，已經(jīng)夠慢的了。緩存時(shí)間能多長就多長把。

當(dāng)然，作為一款好的應(yīng)用，不會(huì)死定一種情況，針對(duì)于不同網(wǎng)絡(luò)變換不同形式的緩存功能是必須有的。而且這個(gè)時(shí)間根據(jù)自己的實(shí)際情況來設(shè)置：數(shù)據(jù)的更新頻率，數(shù)據(jù)的重要性等。

五、何時(shí)刷新

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

其實(shí)何時(shí)刷新我也不知道，這里我提供兩點(diǎn)建議：

1. 數(shù)據(jù)的最長多長時(shí)間不變，對(duì)應(yīng)用無大的影響。

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

 當(dāng)然類似這個(gè)界面的數(shù)據(jù)我認(rèn)為更新時(shí)間能多長就多長了，盡可能長。如果你拿后邊那個(gè)有多少數(shù)據(jù)會(huì)變動(dòng)來搪塞。我會(huì)告訴你：這個(gè)只是一個(gè)引導(dǎo)性的界 面，你有多少款游戲跟用戶半毛錢關(guān)系都沒有，10億也跟他沒關(guān)，他只要確定這里能找到他要找的 湯姆貓 就行。否則你又失去了一個(gè)用戶。

2. 提供刷新按鈕。

       必要時(shí)候或最保險(xiǎn)的方法使在相關(guān)界面提供一個(gè)刷新按鈕，或者當(dāng)下流行的下拉列表刷新方式。為緩存，為加載失敗提供一次重新來過的機(jī)會(huì)。畢竟喝骨頭湯的時(shí)候，我也不介意碗旁多雙筷子。

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

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

圖片緩存：

譯文：

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

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

       這節(jié)課將帶你使用內(nèi)存和硬盤緩存Bitmap，以在加載多個(gè)Bitmap的時(shí)候提升UI的響應(yīng)性和流暢性。

使用內(nèi)存緩存

        以犧牲寶貴的應(yīng)用內(nèi)存為代價(jià)，內(nèi)存緩存提供了快速的Bitmap訪問方式。LruCache類(可以在Support Library中獲取并支持到API  Level 4以上，即1.6版本以上)是非常適合用作緩存Bitmap任務(wù)的，它將最近被引用到的對(duì)象存儲(chǔ)在一個(gè)強(qiáng)引用的LinkedHashMap中，并且在緩存 超過了指定大小之后將最近不常使用的對(duì)象釋放掉。

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

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

其他的Activity(活動(dòng))和(或)程序都是很耗費(fèi)內(nèi)存的嗎？

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

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

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

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

你能平衡圖片的質(zhì)量和數(shù)量么？有的時(shí)候存儲(chǔ)大量低質(zhì)量的圖片更加有用，然后可以在后臺(tái)任務(wù)中加載另一個(gè)高質(zhì)量版本的圖片。

        對(duì)于設(shè)置緩存大小，并沒有適用于所有應(yīng)用的規(guī)范，它取決于你在內(nèi)存使用分析后給出的合適的解決方案。緩存空間太小并無益處，反而會(huì) 引起額外的開銷，而太大了又可能再次引起java.lang.OutOfMemory異?；蛑涣粝潞苄〉目臻g給應(yīng)用的其他程序運(yùn)行。