注：本文翻譯自Google官方的Android Developers Training文檔，譯者技術一般，由于喜愛安卓而產生了翻譯的念頭，純屬個人興趣愛好。

原文鏈接：http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html

---

向你的應用中加載一個單一的位圖是很直接的行為，然而當你需要一次性加載一組圖像的大集合時，事情會變得更加復雜。在很多情況下（比如對于ListView，GridView或者ViewPager），屏幕上顯示的圖片以及會因加載動作而進入屏幕的圖片，這兩者的總數加起來是無法限制的。

通過對移除屏幕區域的子View進行回收，可以讓這類組件內存使用降低下來。垃圾回收器也會對那些假定你將不再需要的引用對象進行回收和釋放。這些措施都很好，但是為了保持流暢地和快速地加載UI，你會希望避免多次連續地處理這些圖片，當它們回到屏幕區域中來時。一個存儲或磁盤緩存可以在這方面提供幫助，它可以讓組件迅速的重新加載處理過的圖片。

這節課將會教你使用一個存儲和磁盤緩存，來提升你的UI加載多個圖片時的響應和流暢性。

---

一）. 使用一個內存緩存

一個內存緩存提供了快速訪問位圖的方法，但它的代價是需要消耗掉珍貴的應用內存。LruCache類（在Support Library也有，可以支持到API Level 4及以上的平臺）對于緩存圖片來說尤其適合，它能將最近引用的對象存儲在一個基于強引用的LinkedHashMap中，并且在緩存超出它的特定大小后，將最近最遲被引用的對象去除。

Note：

在過去，一個流行的內存緩存實現是SoftReference或者WeakReference的位圖緩存，然而，這并不是推薦的實現方法。從Android 2.3（API Level 9）開始，垃圾回收器對于軟引用和弱引用的回收變得更加地激進，從而使得它們的效用正在下降。從Android 3.0（API Level 11）開始，存儲于本機內存的位圖數據并不是以一個可預測的形式釋放的，這就有潛在的可能性導致一個應用超出它的內存限制進而崩潰。

為了為一個LruCache選擇合適的大小，一些因素需要考量，例如：

• 你的activity或應用剩余的存儲壓力是如何的？
• 同一時間有多少應用顯示在屏幕上？有多少需要準備就緒顯示到屏幕上？
• 設備的屏幕的尺寸和密度的大小是多少？一個極高密度的屏幕（xhdpi）的設備（比如Galaxy Nexus）可能相對于其他比如hdpi的設備（比如Nexus S）需要更大的緩存來容納同樣數量的照片。
• 位圖文件的尺寸和屬性是怎樣的，需要消耗多少大的內存空間？
• 圖片被訪問的頻率高不高？有沒有一些圖片被訪問你的頻率比其它的要高？如果有，也許你會期望讓這些項目一直保留在內存或者為不同被訪問頻率的圖片設置多組LruCache對象。
• 能否做到數量和質量間的平衡？有些時候存儲大量低質量的圖片時很有用的，而將更高質量的圖片加載任務放在后臺執行。

沒有什么特定的大小或者公式能夠適合所有的應用，你應該自己分析并決定你的用法和解決方案。一個過小的緩存會導致大量無益處的執行操作，而太大的緩存會導致java.lang.OutOfMemory異常，或者讓你剩下的應用只有有限的存儲來工作。

下面是一個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) {@Overrideprotected 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：

在這個例子中，八分之一的應用內存被分配給了我們的緩存。在一個標準或hdpi的設備上，這大約為4MB左右（32/8）。一個全屏的GridView，在一個分辨率為800x480的設備上，充滿圖片之后，會使用掉大約1.5MB（800*480*4字節），所以這個緩存至少大約能放下2.5個頁面數量的圖片在內存中。

當把一個圖片加載到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. @Overrideprotected Bitmap doInBackground(Integer... params) {final Bitmap bitmap = decodeSampledBitmapFromResource(getResources(), params[0], 100, 100));addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);return bitmap;}... }

---

二）. 使用磁盤緩存

一個內存緩存對于加速訪問最近查看的位圖是很有效果的，然而你不能依賴于它，因為無法做到所有圖片都放置在該緩存中。如GridView這樣的組件其較大的數據集可以迅速填充內存緩存。同時，你的應用可能會被另一個事務打斷，如一個來電，此時在后臺中，它可能會被殺掉，這樣的話內存緩存就被銷毀了。一旦這個用戶恢復了，你的應用不得不重新處理這些圖片。

一個磁盤緩存可以在這種情況下發揮效用，它能保持處理過的位圖文件，并減少在內存緩存中不再可以獲得的加載時間。當然，從磁盤獲取圖片比從內存獲取圖片要慢，由于磁盤讀寫的速度有很多不確定性，故應該在后臺線程中執行。

Note：

一個ContentProvider是一個比較合適的存儲緩存圖片的地方，對于那些訪問頻率較高的圖片來說，例如在圖庫的應用中。

下面的代碼使用了DiskLruCache的實現，它來自于Android source。并且添加到內存緩存的代碼中，更新其功能：

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 threadFile cacheDir = getDiskCacheDir(this, DISK_CACHE_SUBDIR);new InitDiskCacheTask().execute(cacheDir);... }class InitDiskCacheTask extends AsyncTask<File, Void, Void> {@Overrideprotected Void doInBackground(File... params) {synchronized (mDiskCacheLock) {File cacheDir = params[0];mDiskLruCache = DiskLruCache.open(cacheDir, DISK_CACHE_SIZE);mDiskCacheStarting = false; // Finished initializationmDiskCacheLock.notifyAll(); // Wake any waiting threads }return null;} }class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> {...// Decode image in background. @Overrideprotected Bitmap doInBackground(Integer... params) {final String imageKey = String.valueOf(params[0]);// Check disk cache in background threadBitmap bitmap = getBitmapFromDiskCache(imageKey);if (bitmap == null) { // Not found in disk cache// Process as normalfinal 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 beforeif (getBitmapFromMemCache(key) == null) {mMemoryCache.put(key, bitmap);}// Also add to disk cachesynchronized (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 threadwhile (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) {// Check if media is mounted or storage is built-in, if so, try and use external cache dir// otherwise use internal cache dirfinal String cachePath =Environment.MEDIA_MOUNTED.equals(Environment.getExternalStorageState()) ||!isExternalStorageRemovable() ? getExternalCacheDir(context).getPath() :context.getCacheDir().getPath();return new File(cachePath + File.separator + uniqueName); }

Note：

因為初始化磁盤緩存也需要磁盤操作所以它也不能再主線程中執行。然而，這其實意味著緩存有可能在還未初始化的時候就被訪問了。為了解決這個問題，在上面的代碼實現中，一個信號量（lock）保證了應用會在初始化完成之后才去讀取緩存。

雖然內存緩存在UI線程中檢查，磁盤緩存是在后臺線程中檢查。磁盤操作不應該發生在UI線程中執行。當圖片處理完成了，最后位圖將會同時添加到內存和磁盤緩存中，以備將來使用。

---

三）. 處理配置變更

運行時的配置變更，如屏幕方向變化，會導致Android銷毀當前activity，并以新的配置重啟activity（可以閱讀：Handling Runtime Changes）。你一定希望避免重復處理圖像，這樣的話用戶就能在配置改變時，擁有平滑快速地使用體驗。

幸運的是，你在之前的章節中，已經擁有了一個很出色的圖片內存緩存了。這個緩存可以通過使用一個Fragment（該Fragment通過調用setRetainInstance(true)將其自身保留），傳遞給新的activity實例。在activity重新創建之后，這個保留的Fragment就完成了重新依附（reattach），同時你獲得了現有緩存對象的訪問，允許圖片快速提取并填充到ImageView對象中。

下面是一個使用Fragment，在配置變更發生時保留LruCache對象的例子：

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;}@Overridepublic void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setRetainInstance(true);} }

要測試這段代碼，嘗試分別在保留Fragment和不保留Fragment的情況下旋轉設備。你應該能注意到當保留了緩存時，圖片填充到activity時幾乎沒有延遲。那些在內存緩存中找不到的圖片一般都會在磁盤緩存中找到，如果找不到，這些圖片就會像平常一樣處理。

轉載于:https://www.cnblogs.com/jdneo/p/3522538.html

總結

以上是生活随笔為你收集整理的【Android Developers Training】 58. 缓存位图的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。