Android高效載入大圖、多圖解決方案，有效避免程式OOM

lostinai發表於2014-03-04
Android圖解OOM

轉載請註明出處：http://blog.csdn.net/guolin_blog/article/details/9316683

本篇文章主要內容來自於Android Doc，我翻譯之後又做了些加工，英文好的朋友也可以直接去讀原文。

http://developer.android.com/training/displaying-bitmaps/index.html

高效載入大圖片

我們在編寫Android程式的時候經常要用到許多圖片，不同圖片總是會有不同的形狀、不同的大小，但在大多數情況下，這些圖片都會大於我們程式所需要的大小。比如說系統圖片庫裡展示的圖片大都是用手機攝像頭拍出來的，這些圖片的解析度會比我們手機螢幕的解析度高得多。大家應該知道，我們編寫的應用程式都是有一定記憶體限制的，程式佔用了過高的記憶體就容易出現OOM(OutOfMemory)異常。我們可以通過下面的程式碼看出每個應用程式最高可用記憶體是多少。
[java] view plaincopy
  1. int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);  
  2. Log.d("TAG", "Max memory is " + maxMemory + "KB");  
因此在展示高解析度圖片的時候，最好先將圖片進行壓縮。壓縮後的圖片大小應該和用來展示它的控制元件大小相近，在一個很小的ImageView上顯示一張超大的圖片不會帶來任何視覺上的好處，但卻會佔用我們相當多寶貴的記憶體，而且在效能上還可能會帶來負面影響。下面我們就來看一看，如何對一張大圖片進行適當的壓縮，讓它能夠以最佳大小顯示的同時，還能防止OOM的出現。

BitmapFactory這個類提供了多個解析方法(decodeByteArray, decodeFile, decodeResource等)用於建立Bitmap物件，我們應該根據圖片的來源選擇合適的方法。比如SD卡中的圖片可以使用decodeFile方法，網路上的圖片可以使用decodeStream方法，資原始檔中的圖片可以使用decodeResource方法。這些方法會嘗試為已經構建的bitmap分配記憶體，這時就會很容易導致OOM出現。為此每一種解析方法都提供了一個可選的BitmapFactory.Options引數，將這個引數的inJustDecodeBounds屬性設定為true就可以讓解析方法禁止為bitmap分配記憶體，返回值也不再是一個Bitmap物件，而是null。雖然Bitmap是null了，但是BitmapFactory.Options的outWidth、outHeight和outMimeType屬性都會被賦值。這個技巧讓我們可以在載入圖片之前就獲取到圖片的長寬值和MIME型別，從而根據情況對圖片進行壓縮。如下程式碼所示：

[java] view plaincopy
  1. BitmapFactory.Options options = new BitmapFactory.Options();  
  2. options.inJustDecodeBounds = true;  
  3. BitmapFactory.decodeResource(getResources(), R.id.myimage, options);  
  4. int imageHeight = options.outHeight;  
  5. int imageWidth = options.outWidth;  
  6. String imageType = options.outMimeType;  
為了避免OOM異常，最好在解析每張圖片的時候都先檢查一下圖片的大小，除非你非常信任圖片的來源，保證這些圖片都不會超出你程式的可用記憶體。

現在圖片的大小已經知道了，我們就可以決定是把整張圖片載入到記憶體中還是載入一個壓縮版的圖片到記憶體中。以下幾個因素是我們需要考慮的：

  • 預估一下載入整張圖片所需佔用的記憶體。
  • 為了載入這一張圖片你所願意提供多少記憶體。
  • 用於展示這張圖片的控制元件的實際大小。
  • 當前裝置的螢幕尺寸和解析度。

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

那我們怎樣才能對圖片進行壓縮呢？通過設定BitmapFactory.Options中inSampleSize的值就可以實現。比如我們有一張2048*1536畫素的圖片，將inSampleSize的值設定為4，就可以把這張圖片壓縮成512*384畫素。原本載入這張圖片需要佔用13M的記憶體，壓縮後就只需要佔用0.75M了(假設圖片是ARGB_8888型別，即每個畫素點佔用4個位元組)。下面的方法可以根據傳入的寬和高，計算出合適的inSampleSize值：

[java] view plaincopy
  1. public static int calculateInSampleSize(BitmapFactory.Options options,  
  2.         int reqWidth, int reqHeight) {  
  3.     // 源圖片的高度和寬度  
  4.     final int height = options.outHeight;  
  5.     final int width = options.outWidth;  
  6.     int inSampleSize = 1;  
  7.     if (height > reqHeight || width > reqWidth) {  
  8.         // 計算出實際寬高和目標寬高的比率  
  9.         final int heightRatio = Math.round((float) height / (float) reqHeight);  
  10.         final int widthRatio = Math.round((float) width / (float) reqWidth);  
  11.         // 選擇寬和高中最小的比率作為inSampleSize的值，這樣可以保證最終圖片的寬和高  
  12.         // 一定都會大於等於目標的寬和高。  
  13.         inSampleSize = heightRatio < widthRatio ? heightRatio : widthRatio;  
  14.     }  
  15.     return inSampleSize;  
  16. }  
使用這個方法，首先你要將BitmapFactory.Options的inJustDecodeBounds屬性設定為true，解析一次圖片。然後將BitmapFactory.Options連同期望的寬度和高度一起傳遞到到calculateInSampleSize方法中，就可以得到合適的inSampleSize值了。之後再解析一次圖片，使用新獲取到的inSampleSize值，並把inJustDecodeBounds設定為false，就可以得到壓縮後的圖片了。
[java] view plaincopy
  1. public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId,  
  2.         int reqWidth, int reqHeight) {  
  3.     // 第一次解析將inJustDecodeBounds設定為true，來獲取圖片大小  
  4.     final BitmapFactory.Options options = new BitmapFactory.Options();  
  5.     options.inJustDecodeBounds = true;  
  6.     BitmapFactory.decodeResource(res, resId, options);  
  7.     // 呼叫上面定義的方法計算inSampleSize值  
  8.     options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);  
  9.     // 使用獲取到的inSampleSize值再次解析圖片  
  10.     options.inJustDecodeBounds = false;  
  11.     return BitmapFactory.decodeResource(res, resId, options);  
  12. }  
下面的程式碼非常簡單地將任意一張圖片壓縮成100*100的縮圖，並在ImageView上展示。
[java] view plaincopy
  1. mImageView.setImageBitmap(  
  2.     decodeSampledBitmapFromResource(getResources(), R.id.myimage, 100, 100));  

使用圖片快取技術

在你應用程式的UI介面載入一張圖片是一件很簡單的事情，但是當你需要在介面上載入一大堆圖片的時候，情況就變得複雜起來。在很多情況下，（比如使用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 物件來區分不同組的圖片。
  • 你能維持好數量和質量之間的平衡嗎？有些時候，儲存多個低畫素的圖片，而在後臺去開執行緒載入高畫素的圖片會更加的有效。

並沒有一個指定的快取大小可以滿足所有的應用程式，這是由你決定的。你應該去分析程式記憶體的使用情況，然後制定出一個合適的解決方案。一個太小的快取空間，有可能造成圖片頻繁地被釋放和重新載入，這並沒有好處。而一個太大的快取空間，則有可能還是會引起 java.lang.OutOfMemory 的異常。

下面是一個使用 LruCache 來快取圖片的例子：

[java] view plaincopy
  1. private LruCache<String, Bitmap> mMemoryCache;  
  2.   
  3. @Override  
  4. protected void onCreate(Bundle savedInstanceState) {  
  5.     // 獲取到可用記憶體的最大值，使用記憶體超出這個值會引起OutOfMemory異常。  
  6.     // LruCache通過建構函式傳入快取值，以KB為單位。  
  7.     int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);  
  8.     // 使用最大可用記憶體值的1/8作為快取的大小。  
  9.     int cacheSize = maxMemory / 8;  
  10.     mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {  
  11.         @Override  
  12.         protected int sizeOf(String key, Bitmap bitmap) {  
  13.             // 重寫此方法來衡量每張圖片的大小，預設返回圖片數量。  
  14.             return bitmap.getByteCount() / 1024;  
  15.         }  
  16.     };  
  17. }  
  18.   
  19. public void addBitmapToMemoryCache(String key, Bitmap bitmap) {  
  20.     if (getBitmapFromMemCache(key) == null) {  
  21.         mMemoryCache.put(key, bitmap);  
  22.     }  
  23. }  
  24.   
  25. public Bitmap getBitmapFromMemCache(String key) {  
  26.     return mMemoryCache.get(key);  
  27. }  
在這個例子當中，使用了系統分配給應用程式的八分之一記憶體來作為快取大小。在中高配置的手機當中，這大概會有4兆(32/8)的快取空間。一個全螢幕的 GridView 使用4張 800x480解析度的圖片來填充，則大概會佔用1.5兆的空間(800*480*4)。因此，這個快取大小可以儲存2.5頁的圖片。
當向 ImageView 中載入一張圖片時,首先會在 LruCache 的快取中進行檢查。如果找到了相應的鍵值，則會立刻更新ImageView ，否則開啟一個後臺執行緒來載入這張圖片。
[java] view plaincopy
  1. public void loadBitmap(int resId, ImageView imageView) {  
  2.     final String imageKey = String.valueOf(resId);  
  3.     final Bitmap bitmap = getBitmapFromMemCache(imageKey);  
  4.     if (bitmap != null) {  
  5.         imageView.setImageBitmap(bitmap);  
  6.     } else {  
  7.         imageView.setImageResource(R.drawable.image_placeholder);  
  8.         BitmapWorkerTask task = new BitmapWorkerTask(imageView);  
  9.         task.execute(resId);  
  10.     }  
  11. }  
BitmapWorkerTask 還要把新載入的圖片的鍵值對放到快取中。
[java] view plaincopy
  1. class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> {  
  2.     // 在後臺載入圖片。  
  3.     @Override  
  4.     protected Bitmap doInBackground(Integer... params) {  
  5.         final Bitmap bitmap = decodeSampledBitmapFromResource(  
  6.                 getResources(), params[0], 100, 100);  
  7.         addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);  
  8.         return bitmap;  
  9.     }  
  10. }  

掌握了以上兩種方法，不管是要在程式中載入超大圖片，還是要載入大量圖片，都不用擔心OOM的問題了!不過僅僅是理論地介紹不知道大家能不能完全理解，在後面的文章中我會演示如何在實際程式中靈活運用上述技巧來避免程式OOM，感興趣的朋友請繼續閱讀 Android照片牆應用實現，再多的圖片也不怕崩潰 。

相關文章