閱讀450 返回首頁    go 技術社區[雲棲]

高效地顯示Bitmap圖片 3 - 兩種緩存Bitmap的方式

https://blog.csdn.net/kesenhoo/article/details/7491588

Caching Bitmaps [緩存位圖]

  • 加載單個Bitmap到UI是簡單直接的，但是如果你需要一次加載大量的圖片，事情則會變得複雜起來。在大多數情況下(例如在ListView,GridView or ViewPager), 顯示圖片的數量通常是沒有限製的。
  • 通過循環利用子視圖可以抑製內存的使用，GC(garbage collector)也會釋放那些不再需要使用的bitmap。這些機製都非常好，但是為了保持一個流暢的用戶體驗，你想要在屏幕滑回來時避免每次重複處理那些圖片。內存與磁盤緩存通常可以起到幫助的作用，允許組件快速的重新加載那些處理過的圖片。
  • 這一課會介紹在加載多張位圖時使用內存Cache與磁盤Cache來提高反應速度與UI的流暢度。

Use a Memory Cache [使用內存緩存]

  • 內存緩存以花費寶貴的程序內存為前提來快速訪問位圖。LruCache 類(在 Support Library 中也可以找到) 特別合適用來caching bitmaps，用一個strong referenced的 LinkedHashMap 來保存最近引用的對象，並且在Cache超出設置大小的時候踢出(evict)最近最少使用到的對象。
    • Note: 在過去, 一個比較流行的內存緩存實現方法是使用 SoftReference or WeakReference , 然而這是不推薦的。
    • 從Android 2.3 (API Level 9) 開始，GC變得更加頻繁的去釋放soft/weak references，這使得他們就顯得效率低下[容易被GC掉又不斷的創建]。 而且在Android 3.0 (API Level 11)之前，備份的bitmap是存放在native memory 中，它不是以可預知的方式被釋放，這樣可能導致程序超出它的內存限製而崩潰。
  • 為了給LruCache選擇一個合適的大小，有下麵一些因素需要考慮到：
    • 你的程序剩下了多少可用的內存?
    • 多少圖片會被一次呈現到屏幕上？有多少圖片需要準備好以便馬上顯示到屏幕？
    • 設備的屏幕大小與密度是多少? 一個具有特別高密度屏幕(xhdpi)的設備，像 Galaxy Nexus 會比 Nexus S (hdpi)需要一個更大的Cache來hold住同樣數量的圖片.
    • 位圖的尺寸與配置是多少，會花費多少內存？
    • 圖片被訪問的頻率如何？是其中一些比另外的訪問更加頻繁嗎？如果是，也許你想要保存那些最常訪問的到內存中，或者為不同組別的位圖(按訪問頻率分組)設置多個LruCache 對象。
    • 你可以平衡質量與數量嗎? 某些時候保存大量低質量的位圖會非常有用，在另外一個後台任務中加載更高質量的圖片。
  • 沒有指定的大小與公式能夠適用與所有的程序，那取決於分析你的使用情況後提出一個合適的解決方案。一個太小的Cache會導致額外的花銷卻沒有明顯的好處，一個太大的Cache同樣會導致java.lang.OutOfMemory的異常[Cache占用太多內存，其他活動則會因為內存不夠而異常]，並且使得你的程序隻留下小部分的內存用來工作。
  • 下麵是一個為bitmap建立LruCache 的示例：
  1. private LruCache mMemoryCache;  
  2.   
  3. @Override  
  4. protected void onCreate(Bundle savedInstanceState) {  
  5.     ...  
  6.     // Get memory class of this device, exceeding this amount will throw an  
  7.     // OutOfMemory exception.  
  8.     final int memClass = ((ActivityManager) context.getSystemService(  
  9.             Context.ACTIVITY_SERVICE)).getMemoryClass();  
  10.   
  11.     // Use 1/8th of the available memory for this memory cache.  
  12.     final int cacheSize = 1024 * 1024 * memClass / 8;  
  13.   
  14.     mMemoryCache = new LruCache(cacheSize) {  
  15.         @Override  
  16.         protected int sizeOf(String key, Bitmap bitmap) {  
  17.             // The cache size will be measured in bytes rather than number of items.  
  18.             return bitmap.getByteCount();  
  19.         }  
  20.     };  
  21.     ...  
  22. }  
  23.   
  24. public void addBitmapToMemoryCache(String key, Bitmap bitmap) {  
  25.     if (getBitmapFromMemCache(key) == null) {  
  26.         mMemoryCache.put(key, bitmap);  
  27.     }  
  28. }  
  29.   
  30. public Bitmap getBitmapFromMemCache(String key) {  
  31.     return mMemoryCache.get(key);  
  32. }  
    • Note:  在上麵的例子中, 有1/8的程序內存被作為Cache. 在一個常見的設備上(hdpi)，最小大概有4MB (32/8). 一個全屏的 GridView 組件，如果被800x480像素的圖片填滿大概會花費1.5MB (800*480*4 bytes), 因此這大概最少可以緩存2.5張圖片到內存中.
  • 當加載位圖到 ImageView 時，LruCache 會先被檢查是否存在這張圖片。如果找到有，它會被用來立即更新 ImageView 組件，否則一個後台線程則被觸發去處理這張圖片。
  1. public void loadBitmap(int resId, ImageView imageView) {  
  2.     final String imageKey = String.valueOf(resId);  
  3.   
  4.     final Bitmap bitmap = getBitmapFromMemCache(imageKey);  
  5.     if (bitmap != null) {  
  6.         mImageView.setImageBitmap(bitmap);  
  7.     } else {  
  8.         mImageView.setImageResource(R.drawable.image_placeholder);  
  9.         BitmapWorkerTask task = new BitmapWorkerTask(mImageView);  
  10.         task.execute(resId);  
  11.     }  
  12. }  
  • 上麵的程序中 BitmapWorkerTask 也需要做添加到內存Cache中的動作：
  1. class BitmapWorkerTask extends AsyncTask {  
  2.     ...  
  3.     // Decode image in background.  
  4.     @Override  
  5.     protected Bitmap doInBackground(Integer... params) {  
  6.         final Bitmap bitmap = decodeSampledBitmapFromResource(  
  7.                 getResources(), params[0], 100, 100));  
  8.         addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);  
  9.         return bitmap;  
  10.     }  
  11.     ...  
  12. }  

Use a Disk Cache [使用磁盤緩存]

  • 內存緩存能夠提高訪問最近查看過的位圖，但是你不能保證這個圖片會在Cache中。像類似 GridView 等帶有大量數據的組件很容易就填滿內存Cache。你的程序可能會被類似Phone call等任務而中斷，這樣後台程序可能會被殺死，那麼內存緩存就會被銷毀。一旦用戶恢複前麵的狀態，你的程序就又需要為每個圖片重新處理。
  • 磁盤緩存磁盤緩存可以用來保存那些已經處理好的位圖，並且在那些圖片在內存緩存中不可用時減少加載的次數。當然從磁盤讀取圖片會比從內存要慢，而且讀取操作需要在後台線程中處理，因為磁盤讀取操作是不可預期的。
    • Note:  如果圖片被更頻繁的訪問到，也許使用 ContentProvider 會更加的合適，比如在Gallery程序中。
  • 在下麵的sample code中實現了一個基本的 DiskLruCache 。然而，Android 4.0 的源代碼提供了一個更加robust並且推薦使用的DiskLruCache 方案。(libcore/luni/src/main/java/libcore/io/DiskLruCache.java). 因為向後兼容，所以在前麵發布的Android版本中也可以直接使用。 (quick search 提供了一個實現這個解決方案的示例)。
  1. private DiskLruCache mDiskCache;  
  2. private static final int DISK_CACHE_SIZE = 1024 * 1024 * 10; // 10MB  
  3. private static final String DISK_CACHE_SUBDIR = "thumbnails";  
  4.   
  5. @Override  
  6. protected void onCreate(Bundle savedInstanceState) {  
  7.     ...  
  8.     // Initialize memory cache  
  9.     ...  
  10.     File cacheDir = getCacheDir(this, DISK_CACHE_SUBDIR);  
  11.     mDiskCache = DiskLruCache.openCache(this, cacheDir, DISK_CACHE_SIZE);  
  12.     ...  
  13. }  
  14.   
  15. class BitmapWorkerTask extends AsyncTask {  
  16.     ...  
  17.     // Decode image in background.  
  18.     @Override  
  19.     protected Bitmap doInBackground(Integer... params) {  
  20.         final String imageKey = String.valueOf(params[0]);  
  21.   
  22.         // Check disk cache in background thread  
  23.         Bitmap bitmap = getBitmapFromDiskCache(imageKey);  
  24.   
  25.         if (bitmap == null) { // Not found in disk cache  
  26.             // Process as normal  
  27.             final Bitmap bitmap = decodeSampledBitmapFromResource(  
  28.                     getResources(), params[0], 100, 100));  
  29.         }  
  30.   
  31.         // Add final bitmap to caches  
  32.         addBitmapToCache(String.valueOf(imageKey, bitmap);  
  33.   
  34.         return bitmap;  
  35.     }  
  36.     ...  
  37. }  
  38.   
  39. public void addBitmapToCache(String key, Bitmap bitmap) {  
  40.     // Add to memory cache as before  
  41.     if (getBitmapFromMemCache(key) == null) {  
  42.         mMemoryCache.put(key, bitmap);  
  43.     }  
  44.   
  45.     // Also add to disk cache  
  46.     if (!mDiskCache.containsKey(key)) {  
  47.         mDiskCache.put(key, bitmap);  
  48.     }  
  49. }  
  50.   
  51. public Bitmap getBitmapFromDiskCache(String key) {  
  52.     return mDiskCache.get(key);  
  53. }  
  54.   
  55. // Creates a unique subdirectory of the designated app cache directory. Tries to use external  
  56. // but if not mounted, falls back on internal storage.  
  57. public static File getCacheDir(Context context, String uniqueName) {  
  58.     // Check if media is mounted or storage is built-in, if so, try and use external cache dir  
  59.     // otherwise use internal cache dir  
  60.     final String cachePath = Environment.getExternalStorageState() == Environment.MEDIA_MOUNTED  
  61.             || !Environment.isExternalStorageRemovable() ?  
  62.                     context.getExternalCacheDir().getPath() : context.getCacheDir().getPath();  
  63.   
  64.     return new File(cachePath + File.separator + uniqueName);  
  65. }  
  • 內存緩存的檢查是可以在UI線程中進行的，磁盤緩存的檢查需要在後台線程中處理。磁盤操作永遠都不應該在UI線程中發生。當圖片處理完成後，最後的位圖需要添加到內存緩存與磁盤緩存中，方便之後的使用。

Handle Configuration Changes [處理配置改變]

  • 運行時配置改變，例如屏幕方向的改變會導致Android去destory並restart當前運行的Activity。(關於這一行為的更多信息，請參考 Handling Runtime Changes). 你想要在配置改變時避免重新處理所有的圖片，這樣才能提供給用戶一個良好的平滑過度的體驗。
  • 幸運的是，在前麵介紹 Use a Memory Cache 的部分，你已經知道如何建立一個內存緩存。這個緩存可以通過使用一個Fragment去調用 setRetainInstance(true) 傳遞到新的Activity中。在這個activity被recreate之後, 這個保留的 Fragment 會白重新附著上。這樣你就可以訪問Cache對象，從中獲取到圖片信息並快速的重新添加到ImageView對象中。
  • 下麵配置改變時使用Fragment來重新獲取LruCache 的示例：
  1. private LruCache mMemoryCache;  
  2.   
  3. @Override  
  4. protected void onCreate(Bundle savedInstanceState) {  
  5.     ...  
  6.     RetainFragment mRetainFragment =  
  7.             RetainFragment.findOrCreateRetainFragment(getFragmentManager());  
  8.     mMemoryCache = RetainFragment.mRetainedCache;  
  9.     if (mMemoryCache == null) {  
  10.         mMemoryCache = new LruCache(cacheSize) {  
  11.             ... // Initialize cache here as usual  
  12.         }  
  13.         mRetainFragment.mRetainedCache = mMemoryCache;  
  14.     }  
  15.     ...  
  16. }  
  17.   
  18. class RetainFragment extends Fragment {  
  19.     private static final String TAG = "RetainFragment";  
  20.     public LruCache mRetainedCache;  
  21.   
  22.     public RetainFragment() {}  
  23.   
  24.     public static RetainFragment findOrCreateRetainFragment(FragmentManager fm) {  
  25.         RetainFragment fragment = (RetainFragment) fm.findFragmentByTag(TAG);  
  26.         if (fragment == null) {  
  27.             fragment = new RetainFragment();  
  28.         }  
  29.         return fragment;  
  30.     }  
  31.   
  32.     @Override  
  33.     public void onCreate(Bundle savedInstanceState) {  
  34.         super.onCreate(savedInstanceState);  
  35.         setRetainInstance(true);  
  36.     }  
  37. }  
  • 為了測試上麵的效果，嚐試對比retaining 這個 Fragment.與沒有這樣做的時候去旋轉屏幕。你會發現從內存緩存中重新繪製幾乎沒有卡的現象，而從磁盤緩存則顯得稍慢，如果兩個緩存中都沒有，則處理速度像平時一樣。

最後更新：2017-04-04 07:03:06

  上一篇：go 高效地顯示Bitmap圖片 4 - 使用ViewPager與GridView顯示圖片
  下一篇：go 高效地顯示Bitmap圖片 2 - 在UI線程之外處理Bitmaps