在您的ui中顯示單個圖檔是非常簡單的，如果您需要一次顯示很多圖檔就有點複雜了。在很多情況下
顯示在螢幕上的圖檔以及即将顯示在螢幕上的圖檔數量是非常大的(例如在圖庫中浏覽大量圖檔)。
在這些控件中，當一個子控件不顯示的時候，系統會重用該控件來循環顯示 以便減少對記憶體的消耗。同時垃圾回收機制還會
釋放那些已經載入記憶體中的bitmap資源(假設您沒有強引用這些bitmap)。一般來說這樣都是不錯的，但是在使用者來回滑動螢幕的時候，為了保證ui
的流暢性和載入圖檔的效率，您需要避免重複的處理這些需要顯示的圖檔。 使用記憶體緩存和磁盤緩存可以解決這個問題，使用緩存可以讓控件快速的加載已經處理過的圖檔。
這節内容介紹如何使用緩存來提高ui的載入輸入和滑動的流暢性。
使用記憶體緩存
不經常使用的對象删除。
注意: 過去，實作記憶體緩存的常用做法是使用
但是不推薦使用這種方式。從android 2.3 (api level 9) 開始，垃圾回收開始強制的回收掉 soft/weak 引用 進而導緻這些緩存沒有任何效率的提升。
另外，在 android 3.0 (api level 11)之前，這些緩存的bitmap資料儲存在底層記憶體(native memory)中，并且達到預定條件後也不會釋放這些對象，進而可能導緻
程式超過記憶體限制并崩潰。
程式中還有多少記憶體可用
同時在螢幕上顯示多少圖檔？要先緩存多少圖檔用來顯示到即将看到的螢幕上？
圖檔的尺寸和格式決定了每個圖檔需要占用多少記憶體
圖檔通路的頻率如何？一些圖檔的通路頻率要比其他圖檔高很多？如果是這樣的話，您可能需要把這些經常通路的圖檔放到記憶體中。
在品質和數量上如何平衡？有些情況下儲存大量的低品質的圖檔是非常有用的，當需要的情況下使用背景線程來加入一個高品質版本的圖檔。
這裡沒有萬能配方可以适合所有的程式，您需要分析您的使用情況并在指定自己的緩存政策。使用太小的緩存并不能起到應有的效果，而使用太大的緩存會消耗更多
的記憶體進而有可能導緻 java.lang.outofmemory 異常或者留下很少的記憶體供您的程式其他功能使用。
private lrucache<string, bitmap=""> mmemorycache;
@override
protected void oncreate(bundle savedinstancestate) {
...
// get memory class of this device, exceeding this amount will throw an
// outofmemory exception.
final int memclass = ((activitymanager) context.getsystemservice(
context.activity_service)).getmemoryclass();
// use 1/8th of the available memory for this memory cache.
final int cachesize = 1024 * 1024 * memclass / 8;
mmemorycache = new lrucache<string, bitmap="">(cachesize) {
@override
protected int sizeof(string key, bitmap bitmap) {
// the cache size will be measured in bytes rather than number of items.
return bitmap.getbytecount();
}
};
}
public void addbitmaptomemorycache(string key, bitmap bitmap) {
if (getbitmapfrommemcache(key) == null) {
mmemorycache.put(key, bitmap);
}
public bitmap getbitmapfrommemcache(string key) {
return mmemorycache.get(key);
注意: 在這個示例中，該程式的1/8記憶體都用來做緩存用了。在一個normal/hdpi裝置中，這至少有4mb(32/8)記憶體。
的記憶體，是以這樣差不多在記憶體中緩存了2.5頁的圖檔。
public void loadbitmap(int resid, imageview imageview) {
final string imagekey = string.valueof(resid);
final bitmap bitmap = getbitmapfrommemcache(imagekey);
if (bitmap != null) {
mimageview.setimagebitmap(bitmap);
} else {
mimageview.setimageresource(r.drawable.image_placeholder);
bitmapworkertask task = new bitmapworkertask(mimageview);
task.execute(resid);
class bitmapworkertask extends asynctask<integer, void,="" bitmap=""> {
// decode image in background.
@override
protected bitmap doinbackground(integer... params) {
final bitmap bitmap = decodesampledbitmapfromresource(
getresources(), params[0], 100, 100));
addbitmaptomemorycache(string.valueof(params[0]), bitmap);
return bitmap;
使用磁盤緩存
在通路最近使用過的圖檔中，記憶體緩存速度很快，但是您無法确定圖檔是否在緩存中存在。像
同時您的程式還可能被其他任務打斷，比如打進的電話 — 當您的程式位于背景的時候，系統可能會清楚到這些圖檔緩存。一旦使用者恢複使用您的程式，您還需要重新處理這些圖檔。
在這種情況下，可以使用磁盤緩存來儲存這些已經處理過的圖檔，當這些圖檔在記憶體緩存中不可用的時候，可以從磁盤緩存中加載進而省略了圖檔處理過程。
當然， 從磁盤載入圖檔要比從記憶體讀取慢很多，并且應該在非ui線程中載入磁盤圖檔。
注意: 如果緩存的圖檔經常被使用的話，可以考慮使用
在示例代碼中有個簡單的 disklrucache 實作。然後，在android 4.0中包含了一個更加可靠和推薦使用的disklrucache(libcore/luni/src/main/java/libcore/io/disklrucache.java)
。您可以很容易的把這個實作移植到4.0之前的版本中使用(來 href="http://www.google.com/search?q=disklrucache">google一下 看看其他人是否已經這樣幹了！)。
這裡是一個更新版本的 disklrucache ：
private disklrucache mdiskcache;
private static final int disk_cache_size = 1024 * 1024 * 10; // 10mb
private static final string disk_cache_subdir = "thumbnails";
// initialize memory cache
file cachedir = getcachedir(this, disk_cache_subdir);
mdiskcache = disklrucache.opencache(this, cachedir, disk_cache_size);
final string imagekey = string.valueof(params[0]);
// check disk cache in background thread
bitmap bitmap = getbitmapfromdiskcache(imagekey);
if (bitmap == null) { // not found in disk cache
// process as normal
final bitmap bitmap = decodesampledbitmapfromresource(
getresources(), params[0], 100, 100));
// add final bitmap to caches
addbitmaptocache(string.valueof(imagekey, bitmap);
public void addbitmaptocache(string key, bitmap bitmap) {
// add to memory cache as before
// also add to disk cache
if (!mdiskcache.containskey(key)) {
mdiskcache.put(key, bitmap);
public bitmap getbitmapfromdiskcache(string key) {
return mdiskcache.get(key);
// creates a unique subdirectory of the designated app cache directory. tries to use external
// but if not mounted, falls back on internal storage.
public static file getcachedir(context context, string uniquename) {
// check if media is mounted or storage is built-in, if so, try and use external cache dir
// otherwise use internal cache dir
final string cachepath = environment.getexternalstoragestate() == environment.media_mounted
|| !environment.isexternalstorageremovable() ?
context.getexternalcachedir().getpath() : context.getcachedir().getpath();
return new file(cachepath + file.separator + uniquename);
在ui線程中檢測記憶體緩存，在背景線程中檢測磁盤緩存。磁盤操作從來不應該在ui線程中實作。當圖檔處理完畢後，最終的結果會同時添加到
記憶體緩存和磁盤緩存中以便将來使用。
處理配置改變事件
運作時的配置變更 — 例如 螢幕方向改變 — 導緻android摧毀正在運作的activity，然後使用
您需要注意避免在配置改變的時候導緻重新處理所有的圖檔，進而提高使用者體驗。
當activity重新啟動 後，fragment 被重新附加到activity中，您可以通過該fragment來擷取緩存對象。
下面是一個在 fragment中儲存緩存的示例:
retainfragment mretainfragment =
retainfragment.findorcreateretainfragment(getfragmentmanager());
mmemorycache = retainfragment.mretainedcache;
if (mmemorycache == null) {
mmemorycache = new lrucache<string, bitmap="">(cachesize) {
... // initialize cache here as usual
mretainfragment.mretainedcache = mmemorycache;
class retainfragment extends fragment {
private static final string tag = "retainfragment";
public lrucache<string, bitmap=""> mretainedcache;
public retainfragment() {}
public static retainfragment findorcreateretainfragment(fragmentmanager fm) {
retainfragment fragment = (retainfragment) fm.findfragmentbytag(tag);
if (fragment == null) {
fragment = new retainfragment();
return fragment;
public void oncreate(bundle savedinstancestate) {
super.oncreate(savedinstancestate);
<strong>setretaininstance(true);</strong>
您可以嘗試分别使用和不使用fragment來旋轉裝置的螢幕方向來檢視具體的圖檔載入情況。
![Java String.format方法的簡單使用[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)