Bitmap緩存機制

阿新 • • 發佈：2017-06-19

mean set wake instance ads images obj hat 內存大小

Bitmap緩存機制

載入一個bitmap到UI裏面比較簡單直接。可是，假設我們一次載入大量的bitmap數據的時候就變得復雜了。很多情況下（比方這些組件：ListVIew，GridView或者ViewPager），顯示的圖片和將要滾動顯示的圖片通常是沒有限制的。內存的使用量能夠被降下來。通過回收那些移出屏幕之外的組件。Android的垃圾回收機制相同會釋放你的資源，假設它們沒有被引用。這樣的機制是好的，可是為了獲得流暢高速的UI體驗，我們想避免反復下載圖片。一種本地內存緩存的方法提供了非常大的幫助。能夠高速的又一次載入本地緩存的資源。本章將帶你使用內存緩存的機制來提高UI的響應速度和流暢的體驗，當載入多張圖片的時候。

原文：http://wear.techbrood.com/training/displaying-bitmaps/cache-bitmap.html#config-changes

使用內存緩存

內存緩存使用有限的應用內存去緩存bitmap。LruCache這個類（also available in the Support Li brary for use back to API Level 4），很適合緩存bitmaps。他使用LinkedHashMap，它會在超過緩存大小的時候回收近期最少使用的指向。

Note：過去。我們常使用 SoftReference or WeakReference 來緩存。可是如今不推薦了。從Android2.3（API Level 9），垃圾回收器抵制使用它們。

Android3.0（11）之後。bitmap被存儲在有效的緩存裏面。在可預測的情況下並不能被釋放。這樣導致超過內存限制而且導致崩潰。

為了為LrcCache選擇合適的內存空間，以下幾個因素要被大家重視的：

你應用的空余內存是多大？
一次將要載入多少張圖片顯示？如今已經顯示了多少張圖片？
屏幕的尺寸大小和密度是多少？高密度的是被比方Galaxy Nexus要比低密度的設備須要更大的緩存。
bitmap的尺寸和配置是什麽。沒一張圖片所占資源的大小是多少？
你須要什麽樣的用戶體驗？還是有一部分須要流暢的體驗？假設是這種話，你能夠把他們長久的放到內存裏面或者使用LrcCache緩存。
你須要在質量（內存大小）和“質量”（圖片的質量）上做出選擇？有時候，我們能夠選擇存儲縮略圖，後臺載入更高質量的圖片。

沒有一個特定大小的內存能夠使用全部的應用。他取決於你去分析內存的使用情況尋找一個合適的解決方法。緩存太小的話沒有什麽意義，緩存太大easy引起java.lang.OutOfMemory exceptions而且僅僅留給你的應用非常少的一部分內存。這裏有個使用LruCache的樣例：

private LruCache<String, Bitmap> mMemoryCache;

@Override
protected void onCreate(Bundle savedInstanceState) {
    ...
    // Get max available VM memory, exceeding this amount will throw an
    // OutOfMemory exception. Stored in kilobytes as LruCache takes an
    // int in its constructor.
    final int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);

    // Use 1/8th of the available memory for this memory cache.
    final int cacheSize = maxMemory / 8;

    mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {
        @Override
        protected int sizeOf(String key, Bitmap bitmap) {
            // The cache size will be measured in kilobytes rather than
            // number of items.
            return bitmap.getByteCount() / 1024;
        }
    };
    ...
}

public void addBitmapToMemoryCache(String key, Bitmap bitmap) {
    if (getBitmapFromMemCache(key) == null) {
        mMemoryCache.put(key, bitmap);
    }
}

public Bitmap getBitmapFromMemCache(String key) {
    return mMemoryCache.get(key);
}

Note: In this example, one eighth of the application memory is allocated for our cache. On a normal/hdpi device this is a minimum of around 4MB (32/8). A fullscreen GridView filled with images on a device with 800x480 resolution would use around 1.5MB (800*480*4 bytes), so this would cache a minimum of around 2.5pages of images in memory.
當我們載入一張圖片到ImageView，首先檢查Lrucache。

假設一旦找到接口。我們能夠非常高速的更新這個ImageView,否則，我們啟動一個線程去運行載入這張圖片。

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);
    }
}

BitmapWorkerTask須要更新資源和資源的緩存接口：

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;
    }
    ...
}

使用本地緩存

內存緩存是一種非常好的提快速度的方法，可是你不能全然依靠它。像GridView組件非常快的占用掉大量內存。你的應用可能會被其它任務打斷。比方來電，而且後臺進程可能會被終止，內存緩存也可能會被釋放。當你的應用再次啟動時候，你不得不又一次載入。本地緩存能夠解決問題，幫助你存儲那些緩存不須要的資源來降低反復載入的次數，當然，本地緩存的使用要比內存緩存的速度要慢，須要在後臺操作。擔任果然讀取的事件是不可預知的 Note: A ContentProvider might be a more appropriate place to store cached images if they are accessed more frequently, for example in an image gallery application. 以下的代碼DiskLrcCache。是從本地載入的一個樣例：

private DiskLruCache mDiskLruCache;
private final Object mDiskCacheLock = new Object();
private boolean mDiskCacheStarting = true;
private static final int DISK_CACHE_SIZE = 1024 * 1024 * 10; // 10MB
private static final String DISK_CACHE_SUBDIR = "thumbnails";

@Override
protected void onCreate(Bundle savedInstanceState) {
    ...
    // Initialize memory cache
    ...
    // Initialize disk cache on background thread
    File cacheDir = getDiskCacheDir(this, DISK_CACHE_SUBDIR);
    new InitDiskCacheTask().execute(cacheDir);
    ...
}

class InitDiskCacheTask extends AsyncTask<File, Void, Void> {
    @Override
    protected Void doInBackground(File... params) {
        synchronized (mDiskCacheLock) {
            File cacheDir = params[0];
            
mDiskLruCache = DiskLruCache.open(cacheDir, DISK_CACHE_SIZE);
            mDiskCacheStarting = false; // Finished initialization
            mDiskCacheLock.notifyAll(); // Wake any waiting threads
        }
        return null;
    }
}

class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> {
    ...
    // Decode image in background.
    @Override
    protected Bitmap doInBackground(Integer... params) {
        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(imageKey, bitmap);

        return bitmap;
    }
    ...
}

public void addBitmapToCache(String key, Bitmap bitmap) {
    // Add to memory cache as before
    if (getBitmapFromMemCache(key) == null) {
        mMemoryCache.put(key, bitmap);
    }

    // Also add to disk cache
    synchronized (mDiskCacheLock) {
        if (mDiskLruCache != null && mDiskLruCache.get(key) == null) {
            mDiskLruCache.put(key, bitmap);
        }
    }
}

public Bitmap getBitmapFromDiskCache(String key) {
    synchronized (mDiskCacheLock) {
        // Wait while disk cache is started from background thread
        while (mDiskCacheStarting) {
            try {
                mDiskCacheLock.wait();
            } catch (InterruptedException e) {}
        }
        if (mDiskLruCache != null) {
            return mDiskLruCache.get(key);
        }
    }
    return null;
}

// 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 getDiskCacheDir(Context context, String uniqueName) {<pre name="code" class="java">private LruCache<String, Bitmap> mMemoryCache;

@Override
protected void onCreate(Bundle savedInstanceState) {
    ...
    RetainFragment retainFragment =
            RetainFragment.findOrCreateRetainFragment(getFragmentManager());
    mMemoryCache = retainFragment.mRetainedCache;
    if (mMemoryCache == null) {
        mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {
            ... // Initialize cache here as usual
        }
        retainFragment.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();
            fm.beginTransaction().add(fragment, TAG).commit();
        }
        return fragment;
    }

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setRetainInstance(true);
    }
}

Note: Even initializing the disk cache requires disk operations and therefore should not take place on the main thread. However, this does mean there‘s a chance the cache is accessed before initialization. To address this, in the above implementation, a lock object ensures that the app does not read from the disk cache until the cache has been initialized. 內存緩存在UI線程裏面檢測。本地緩存須要在後臺使用，本地緩存不能代替內存緩存在UI線程裏面的地位，終於，為了以後的使用bitmap同事被放到內存和本地

處理配置的變化

執行時的配置變化。比方屏幕方向的變化會引起Android摧毀和重新啟動Activity(For more information about this behavior, see Handling Runtime Changes)，你想避免再次process你的圖片，為了更快的體驗。幸運的是，你有一個非常好的內存緩存機制，你能夠使用Fragment來忽略這些通過使用setRetainInstance(true)，當Activity被又一次創建的時候，該保留的Fragment相同會被又一次附著到你的應用上面。

以下是一個應對配置改變時的樣例：

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();
            fm.beginTransaction().add(fragment, TAG).commit();
        }
        return fragment;
    }

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setRetainInstance(true);
    }
}

為了測試它，我們能夠旋轉屏幕在保留和不保留Fragment的情況下。你應該會註意到。當你保留Fragment的時候。你會註意到圖片會毫無滯留的從內存緩存載入。內存中沒有找到的會被緩存到本地。假設不這種話，和常規一樣。

緩存的圖片的優化請看上一篇：多線程處理Bitmaps

Bitmap緩存機制

mean set wake instance ads images obj hat 內存大小 Bitmap緩存機制載入一個bitmap到UI裏面比較簡單直接。可是，假設我們一次載入大量的bitmap數據的時候就變得復雜了。很多情況下（比方這些組件：ListVIe

Bitmap緩存機制

Bitmap緩存機制

使用內存緩存

使用本地緩存

處理配置的變化

緩存的圖片的優化請看上一篇：多線程處理Bitmaps

Bitmap緩存機制

緩存機制與局部性原理

Hibernate 緩存機制淺析

mybatis 之緩存機制

Android性能優化之ListView緩存機制

九種瀏覽器端緩存機制知多少（轉）

大規模網站架構的緩存機制

Shiro學習（11）緩存機制

php利用ob緩存機制實現頁面靜態化方法全解

hibernate緩存機制詳細分析

http緩存機制

linux學習之緩存機制

Map實現java緩存機制的簡單實例

mybatis的緩存機制

MyBatis-緩存機制

關於億級流量網站架構一書緩存機制的探討

html緩存機制，http頭部控制

瀏覽器 HTTP 協議緩存機制詳解

【Web緩存機制系列】2 – Web瀏覽器的緩存機制-(新鮮度校驗值)

Mybatis——緩存機制

Bitmap緩存機制

Bitmap緩存機制

使用內存緩存

使用本地緩存

處理配置的變化

緩存的圖片的優化請看上一篇：多線程處理Bitmaps

相關推薦