android 記憶體溢出處理辦法（出現java.lang.OutOfMemoryError: bitmap size exceeds VM budget 異常）

昨天在模擬器上給gallery放入圖片的時候，出現java.lang.OutOfMemoryError: bitmap size exceeds VM budget 異常，映像大小超過了RAM記憶體。
      模擬器RAM比較小，只有8M記憶體，當我放入的大量的圖片（每個100多K左右），就出現上面的原因。
由於每張圖片先前是壓縮的情況，放入到Bitmap的時候，大小會變大，導致超出RAM記憶體，具體解決辦法如下：
//解決載入圖片記憶體溢出的問題
                    //Options 只儲存圖片尺寸大小，不儲存圖片到記憶體
                BitmapFactory.Options opts = new BitmapFactory.Options();
                //縮放的比例，縮放是很難按準備的比例進行縮放的，其值表明縮放的倍數，SDK中建議其值是2的指數值,值越大會導致圖片不清晰
                opts.inSampleSize = 4;
                Bitmap bmp = null;
                bmp = BitmapFactory.decodeResource(getResources(), mImageIds[position],opts);                             
                ...              
               //回收
                bmp.recycle();
通過上面的方式解決了，但是這並不是最完美的解決方式。
通過一些瞭解，得知如下：
最佳化Dalvik虛擬機器的堆記憶體配置
對於Android平台來說，其託管層使用的Dalvik Java VM從目前的表現來看還有很多地方可以最佳化處理，比如我們在開發一些大型遊戲或耗資源的應用中可能考慮手動幹涉GC處理，使用 dalvik.system.VMRuntime類提供的setTargetHeapUtilization方法可以增強程式堆記憶體的處理效率。當然具體原理我們可以參考開源工程，這裡我們僅說下使用方法:   private final static float TARGET_HEAP_UTILIZATION = 0.75f; 在程式onCreate時就可以調用 VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 即可。
Android堆記憶體也可自己定義大小
    對於一些Android項目，影響效能瓶頸的主要是Android自己記憶體管理機制問題，目前手機廠商對RAM都比較吝嗇，對於軟體的流暢性來說RAM對效能的影響十分敏感，除了最佳化Dalvik虛擬機器的堆記憶體配置外，我們還可以強制定義自己軟體的對記憶體大小，我們使用Dalvik提供的 dalvik.system.VMRuntime類來設定最小堆記憶體為例:
private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); //設定最小heap記憶體為6MB大小。當然對於記憶體吃緊來說還可以通過手動幹涉GC去處理
bitmap 設定圖片尺寸，避免記憶體溢出 OutOfMemoryError的最佳化方法
★android 中用bitmap 時很容易記憶體溢出，報如下錯誤：Java.lang.OutOfMemoryError : bitmap size exceeds VM budget
● 主要是加上這段：
BitmapFactory.Options options = new BitmapFactory.Options();
                options.inSampleSize = 2;
● eg1：(通過Uri取圖片)
private ImageView preview;
BitmapFactory.Options options = new BitmapFactory.Options();
                    options.inSampleSize = 2;//圖片寬高都為原來的二分之一，即圖片為原來的四分之一
                    Bitmap bitmap = BitmapFactory.decodeStream(cr
                            .openInputStream(uri), null, options);
                    preview.setImageBitmap(bitmap);
以上代碼可以最佳化記憶體溢出，但它只是改變圖片大小，並不能徹底解決記憶體溢出。
● eg2:（通過路徑去圖片）
private ImageView preview;
private String fileName= "/sdcard/DCIM/Camera/2010-05-14 16.01.44.jpg";
BitmapFactory.Options options = new BitmapFactory.Options();
                options.inSampleSize = 2;//圖片寬高都為原來的二分之一，即圖片為原來的四分之一
                        Bitmap b = BitmapFactory.decodeFile(fileName, options);
                        preview.setImageBitmap(b);
                        filePath.setText(fileName);

 

 

 

進公司的第一個項目就遇到了一個比較難纏的客戶，不過總算對付過去了。在第一個項目中由於app載入的圖片、報表比較多，所以經常報出記憶體溢出的錯誤，很是頭疼。不過在project leader的帶領下，基本算是解決了。在此感謝一下my leader，Samuel.Cai辛苦了。哈哈......
以下是一些總結，ps：從我leader那邊搞過來的，和大家分享一下，哈哈
1. 當項目中包含大量圖片，或者圖片過大，可能會oom
 
方法1 ：  等比例縮小圖片  
 
                BitmapFactory.Options options = new BitmapFactory.Options();
                options.inSampleSize = 4;

 
方法2 ：  對圖片採用軟引用，及時地進行recyle()操作
 
                SoftReference<Bitmap> bitmap;
                bitmap = new SoftReference<Bitmap>(pBitmap);
    if(bitmap != null){
 
            if(bitmap.get() != null && !bitmap.get().isRecycled()){
                bitmap.get().recycle();
                bitmap = null;
            }
        }

 
方法3 ：  對複雜的listview進行合理設計與編碼：
              1.   注意重用Adapter裡面的 convertView  以及holder機制的運用   －－－－－ 參考資料： api demo list 14. Efficient Adapter
 
 public View getView(int position, View convertView, ViewGroup parent) {
 if (convertView == null) {
            v = mInflater.inflate(resource, parent, false);

            final int[] to = mTo;
            final int count = to.length;
            final View[] holder = new View[count];

            for (int i = 0; i < count; i++) {
                holder[i] = v.findViewById(to[i]);
            }

            v.setTag(holder);
        } else {
        ｝
 
｝
          2.  上述方法嘗試還未成功，可用 lazy loading data   ----- 參考資料：api demo  list 13

 
方法4 ：單個頁面，橫豎屏切換N次後 OOM
         1. 看看頁面配置當中有沒有大的圖片，比如背景圖之類的。去除xml中相關設定，改在程式中設定背景圖（放在onCreate()方法中）：
          Drawable bg = getResources().getDrawable(R.drawable.bg);
          XXX.setBackgroundDrawable(rlAdDetailone_bg);
          在Activity destory時注意，bg.setCallback(null); 防止Activity得不到及時的釋放

 
         2. 跟上面方法相似，直接把xml設定檔載入成view 再放到一個容器裡，然後直接調用 this.setContentView(View view);方法
 
         避免xml的重複載入
 
       
 
方法5 ： 在頁面切換時儘可能少地重複使用一些代碼，比如：重複調用資料庫，反覆使用某些對象等等......
 
方法6 ：Android堆記憶體也可自己定義大小 和  最佳化Dalvik虛擬機器的堆記憶體配置 

    注意若使用這種方法：project build target 只能選擇 <= 2.2 版本，否則編譯將通不過。 所以不建議用這種方式 
 
    private final static int CWJ_HEAP_SIZE= 6*1024*1024;
    private final static float TARGET_HEAP_UTILIZATION = 0.75f;
    VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE);
    VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);
  
作者“這一秒不放棄

 

 

 

android 記憶體溢出問題分析

www.diybl.com    時間： 2012-01-11  作者：網路   編輯：hawk 點擊：  36 [ 評論 ]

-

-

 

 

最近的項目中，記憶體一直再增長，但是不知道是什麼問題，導致記憶體溢出，在網上看到了這麼一篇關於記憶體分析與管理的文章，解決了部分問題，感覺這篇文章還不錯，就轉帖到我的blog上了，希望對大家有所協助。如果哪裡有不好的地方，給留下言，然後我們大家繼續完善記憶體泄露的問題，對大家都會有所協助的，呵呵

 

一、概述 1

二、Android(Java)中常見的容易引起記憶體流失的不良代碼 1

(一) 查詢資料庫沒有關閉遊標 2

(二) 構造Adapter時，沒有使用緩衝的 convertView 3

(三) Bitmap對象不在使用時調用recycle()釋放記憶體 4

(四) 釋放對象的引用 4

(五) 其他 5

三、記憶體監測工具 DDMS --> Heap 5

四、記憶體分析工具 MAT(Memory Analyzer Tool) 7

(一) 產生.hprof檔案 7

(二) 使用MAT匯入.hprof檔案 8

(三) 使用MAT的視圖工具分析記憶體 8

 一、概述

  Java編程中經常容易被忽視，但本身又十分重要的一個問題就是記憶體使用量的問題。Android應用主要使用Java語言編寫，因此這個問題也同樣會在 Android開發中出現。本文不對Java編程問題做探討，而是對於在Android中，特別是應用開發中的此類問題進行整理。

  由於作者接觸Android時間並不是很長，因此如有敘述不當之處，歡迎指正。

二、Android(Java)中常見的容易引起記憶體流失的不良代碼

  Android主要應用在嵌入式裝置當中，而嵌入式裝置由於一些眾所周知的條件限制，通常都不會有很高的配置，特別是記憶體是比較有限的。如果我們編寫的代碼當中有太多的對記憶體使用量不當的地方，難免會使得我們的裝置運行緩慢，甚至是死機。為了能夠使得Android應用程式安全且快速的運行，Android 的每個應用程式都會使用一個專有的Dalvik虛擬機器執行個體來運行，它是由Zygote服務進程孵化出來的，也就是說每個應用程式都是在屬於自己的進程中啟動並執行。一方面，如果程式在運行過程中出現了記憶體流失的問題，僅僅會使得自己的進程被kill掉，而不會影響其他進程（如果是system_process 等系統進程出問題的話，則會引起系統重啟）。另一方面Android為不同類型的進程分配了不同的記憶體使用量上限，如果應用進程使用的記憶體超過了這個上限，則會被系統視為記憶體流失，從而被kill掉。Android為應用進程分配的記憶體上限如下所示：

位置： /ANDROID_SOURCE/system/core/rootdir/init.rc 部分指令碼

# Define the oom_adj values for the classes of processes that can be

# killed by the kernel. These are used in ActivityManagerService.

  setprop ro.FOREGROUND_APP_ADJ 0

  setprop ro.VISIBLE_APP_ADJ 1

  setprop ro.SECONDARY_SERVER_ADJ 2

  setprop ro.BACKUP_APP_ADJ 2

  setprop ro.HOME_APP_ADJ 4

  setprop ro.HIDDEN_APP_MIN_ADJ 7

  setprop ro.CONTENT_PROVIDER_ADJ 14

  setprop ro.EMPTY_APP_ADJ 15

# Define the memory thresholds at which the above process classes will

# be killed. These numbers are in pages (4k).

  setprop ro.FOREGROUND_APP_MEM 1536

  setprop ro.VISIBLE_APP_MEM 2048

  setprop ro.SECONDARY_SERVER_MEM 4096

  setprop ro.BACKUP_APP_MEM 4096

  setprop ro.HOME_APP_MEM 4096

  setprop ro.HIDDEN_APP_MEM 5120

  setprop ro.CONTENT_PROVIDER_MEM 5632

  setprop ro.EMPTY_APP_MEM 6144

# Write value must be consistent with the above properties.

# Note that the driver only supports 6 slots, so we have HOME_APP at the

# same memory level as services.

  write /sys/module/lowmemorykiller/parameters/adj 0,1,2,7,14,15

  write /proc/sys/vm/overcommit_memory 1

  write /proc/sys/vm/min_free_order_shift 4

  write /sys/module/lowmemorykiller/parameters/minfree 1536,2048,4096,5120,5632,6144

  # Set init its forked children's oom_adj.

  write /proc/1/oom_adj -16

  正因為我們的應用程式能夠使用的記憶體有限，所以在編寫代碼的時候需要特別注意記憶體使用量問題。如下是一些常見的記憶體使用量不當的情況。

 (一) 查詢資料庫沒有關閉遊標

描述：

  程式中經常會進行查詢資料庫的操作，但是經常會有使用完畢Cursor後沒有關閉的情況。如果我們的查詢結果集比較小，對記憶體的消耗不容易被發現，只有在常時間大量操作的情況下才會複現記憶體問題，這樣就會給以後的測試和問題排查帶來困難和風險。

 範例程式碼：

Cursor cursor = getContentResolver().query(uri ...);

if (cursor.moveToNext()) {

  ... ... 

}

 修正範例程式碼：

Cursor cursor = null;

try {

  cursor = getContentResolver().query(uri ...);

  if (cursor != null && cursor.moveToNext()) {

  ... ... 

  }

} finally {

  if (cursor != null) {

  try { 

  cursor.close();

  } catch (Exception e) {

  //ignore this

  }

  }

} 

 (二) 構造Adapter時，沒有使用緩衝的 convertView

描述：

  以構造ListView的BaseAdapter為例，在BaseAdapter中提高了方法：

public View getView(int position, View convertView, ViewGroup parent)

來向ListView提供每一個item所需要的view對象。初始時ListView會從BaseAdapter中根據當前的螢幕布局執行個體化一定數量的 view對象，同時ListView會將這些view對象緩衝起來。當向上滾動ListView時，原先位於最上面的list item的view對象會被回收，然後被用來構造新出現的最下面的list item。這個構造過程就是由getView()方法完成的，getView()的第二個形參 View convertView就是被緩衝起來的list item的view對象(初始化時緩衝中沒有view對象則convertView是null)。

  由此可以看出，如果我們不去使用convertView，而是每次都在getView()中重新執行個體化一個View對象的話，即浪費資源也浪費時間，也會使得記憶體佔用越來越大。ListView回收list item的view對象的過程可以查看:

android.widget.AbsListView.java --> void addScrapView(View scrap) 方法。

 範例程式碼：

public View getView(int position, View convertView, ViewGroup parent) {

  View view = new Xxx(...);

  ... ...

  return view;

}

 修正範例程式碼：

public View getView(int position, View convertView, ViewGroup parent) {

  View view = null;

  if (convertView != null) {

  view = convertView;

  populate(view, getItem(position));

  ...

  } else {

  view = new Xxx(...);

  ...

  }

  return view;

} 

 (三) Bitmap對象不在使用時調用recycle()釋放記憶體

描述：

  有時我們會手工的操作