Bitmap的高效載入和LruCache快取

本部落格：

android應用程式都是有一定記憶體限制的，程式占用了過高的記憶體就容易出現oom(outofmemory)異常。

因此在展示高解析度的時候，最好先將進行壓縮。壓縮後的大小應該和用來展示它的控制項大小相近。

bitmapfactory類提供了四類方法： decodefile、decoderesource、decodestream和decodebytearray,分別用於支援從檔案系統、資源、輸入流以及位元組陣列中載入bitmap物件。

比如，你的imageview只有128* 96畫素的大小，只是為了顯示一張縮圖，這時候把一張1024 * 768畫素的完全載入到記憶體中顯然是不值得的。

高效載入bitmap的核心思想

獲取取樣率的流程

通過取樣率即可有效地載入

具體**

目前比較常用的快取策略是lrucache和disklrucache,其中lrucache常被用作記憶體快取，disklrucache常被用作儲存快取。lru是least recently used的縮寫，即最近最少使用演算法，核心思想：當快取快滿時，會淘汰近期最少使用的快取目標。

lrucache是乙個泛型類，它內部採用了乙個linkedhashmap以強引用的方式儲存外界的快取物件，其提供了get和put方法來提供完成快取的獲取和操作新增，當快取滿時，lrucache會移除較早使用的快取物件，然後再新增新的快取物件。

disklrucache用於實現儲存裝置快取，即磁碟快取，通過將快取物件寫入檔案系統從而實現快取的效果。

使用方式：

disklrucache的快取新增

disklrucache的快取新增的操作是通過editor完成的，editor表示乙個快取物件的編輯物件。這裡仍然以快取舉例，首先需要獲取url所對應的key，然後根據key就可以通過edit()來獲取editor物件，如果這個快取正在被編輯，那麼返回edit()會返回null,即disklrucache不允許同時編輯乙個快取物件。之所以要把url轉換成key,是因為的url中很可能有特殊字元，這將影響url在android中直接使用，一般採用url的md5作為key。

將的url轉成key以後，就可以獲取editor物件。對於這個key來說，如果當前不存在其他editor物件，那麼edit()就會返回乙個新的editor物件，通過它就可以得到檔案輸出流。需要注意的是，由於前面在disklrucache的open方法中設定了乙個節點只能有乙個資料，因此下面的disk_cache_index常量直接設定為0即可。

string key = hashkeyfromurl(url);
disklrucache.editor editor = mdisklrucache.edit(key);
if(editor != null)

disklrucache的快取查詢

快取查詢過程也需要將url轉換為key,通過disklrucache的get方法得到乙個snapshot物件，接著再通過snapshot物件即可得到快取的檔案輸入流，有了檔案輸出流，就可以得到bitmap物件。為了避免載入過程中導致的oom問題，一般不建議直接載入原始。通過bitmapfactory.options物件來載入一張縮放後的，但那種方法對fileinputstream的縮放存在問題，原因是fileinputstream是一種有序的檔案流，而兩次decodestream 呼叫影響了檔案流的位置屬性，導致了第二次decodestream時的得到的是null。為了解決這個問題，可以通過檔案流來得到它所對應的檔案描述符，然後再通過bitmapfactory.decodefiledescriptor方法來載入一張縮放後的

在很多情況下，（比如使用listview, gridview 或者 viewpager 這樣的元件），螢幕上顯示的可以通過滑動螢幕等事件不斷地增加，最終導致oom。

為了保證記憶體的使用始終維持在乙個合理的範圍，通常會把被移除螢幕的進行**處理。此時垃圾**器也會認為你不再持有這些的引用，從而對這些進行gc操作。用這種思路來解決問題是非常好的，可是為了能讓程式快速執行，在介面上迅速地載入，你又必須要考慮到某些被**之後，使用者又將它重新滑入螢幕這種情況。這時重新去載入一遍剛剛載入過的無疑是效能的瓶頸，你需要想辦法去避免這個情況的發生。

記憶體快取技術對那些大量占用應用程式寶貴記憶體的提供了快速訪問的方法。其中最核心的類是lrucache (此類在android-support-v4的包中提供) 。這個類非常適合用來快取，它的主要演算法原理是把最近使用的物件用強引用儲存在 linkedhashmap 中，並且把最近最少使用的物件在快取值達到預設定值之前從記憶體中移除。

在過去，我們經常會使用一種非常流行的記憶體快取技術的實現，即軟引用或弱引用 (softreference or weakreference)。但是現在已經不再推薦使用這種方式了，因為從 android 2.3 (api level 9)開始，垃圾**器會更傾向於**持有軟引用或弱引用的物件，這讓軟引用和弱引用變得不再可靠。另外，android 3.0 (api level 11)中，的資料會儲存在本地的記憶體當中，因而無法用一種可預見的方式將其釋放，這就有潛在的風險造成應用程式的記憶體溢位並崩潰。

為了能夠選擇乙個合適的快取大小給lrucache, 有以下多個因素應該放入考慮範圍內，例如：

你的裝置的螢幕大小和解析度分別是多少？乙個超高解析度的裝置（例如 galaxy nexus) 比起乙個較低解析度的裝置（例如 nexus s），在持有相同數量的時候，需要更大的快取空間。

的尺寸和大小，還有每張會佔據多少記憶體空間。

被訪問的頻率有多高？會不會有一些的訪問頻率比其它要高？如果有的話，你也許應該讓一些常駐在記憶體當中，或者使用多個lrucache 物件來區分不同組的。

你能維持好數量和質量之間的平衡嗎？有些時候，儲存多個低畫素的，而在後台去開執行緒載入高畫素的會更加的有效。

private lrucachemmemorycache;  
@override 
protected void oncreate(bundle s**edinstancestate) 
}; 
} public void addbitmaptomemorycache(string key, bitmap bitmap) 
} public bitmap getbitmapfrommemcache(string key)

在這個例子當中，使用了系統分配給應用程式的八分之一記憶體來作為快取大小。在中高配置的手機當中，這大概會有4兆(32/8)的快取空間。乙個全螢幕的 gridview 使用4張 800x480解析度的來填充，則大概會占用1.5兆的空間(800*480*4)。因此，這個快取大小可以儲存2.5頁的。

當向 imageview 中載入一張時,首先會在 lrucache 的快取中進行檢查。如果找到了相應的鍵值，則會立刻更新imageview ，否則開啟乙個後台執行緒來載入這張。

public void loadbitmap(int resid, imageview imageview)  else   
}

bitmapworkertask 還要把新載入的的鍵值對放到快取中。

class bitmapworkertask extends asynctask  
}

Bitmap的高效載入和LruCache快取

Bitmap的高效載入

如何高效載入bitmap

Bitmap的優化及高效載入

Bitmap的高效載入和LruCache快取

Bitmap的高效載入

如何高效載入bitmap

Bitmap的優化及高效載入

相關推薦