Android 效能最佳化之使用MAT分析記憶體泄露問題，androidmat

Android 效能最佳化之使用MAT分析記憶體泄露問題，androidmat

轉載請註明本文出自xiaanming的部落格（http://blog.csdn.net/xiaanming/article/details/42396507），請尊重他人的辛勤勞動成果，謝謝！

我們平常在開發Android應用程式的時候，稍有不慎就有可能產生OOM，雖然JAVA有記憶體回收機，但也不能杜絕記憶體泄露，記憶體溢出等問題，隨著科技的進步，行動裝置的記憶體也越來越大了，但由於Android裝置的參差不齊，可能運行在這台裝置好好的，運行在那台裝置就報OOM，這些適配問題也是比較蛋疼的，比如我們平常運行著一個應用程式，啟動並執行好好的，突然到某個Activity就給你爆出一個OOM的錯誤，你可能會以為是這個Activity導致的記憶體泄露，你會想到也有可能是記憶體有泄露嗎？記憶體泄露就像一個定時炸彈，隨時都有可能使我們的應用程式崩潰掉，所以作為一名Android開發人員，還是需要有分析記憶體泄露的能力，說道這裡我們還是要說下什麼是記憶體泄露，記憶體泄露是指有個引用指向一個不再被使用的對象，導致該對象不會被記憶體回收行程回收。因此，記憶體回收行程是無法回收記憶體泄露的對象。本文就使用DDMS(Dalvik Debug Monitor Server)和MAT(Memory Analyzer Tool)工具帶大家來分析記憶體泄露問題。

工具的準備

DDMS是ADT內建的調試工具,有關DDMS的使用請參考http://developer.android.com/tools/debugging/ddms.html，而MAT的就需要我們自行安裝Eclipse外掛程式，安裝方法我就不多說了，下面給出一個線上安裝的地址：http://download.eclipse.org/mat/1.3/update-site/，MAT可以檢測到記憶體泄露，降低記憶體消耗，它有著非常強大的解析堆記憶體空間dump能力。

如何檢測記憶體泄露

1.使用DDMS檢測記憶體泄露

開啟Devices視圖,選擇我們需要分析的應用程式進程，點擊Updata Heap按鈕

然後在開啟DDMS, 選擇Heap標籤，然後點擊Cause GC按鈕，點擊Cause GC是手動觸發JAVA記憶體回收行程，如

如果我們要測試某個Activity是否發生記憶體泄露，我們可以反覆進入和退出這個Activity, 再手動觸發幾次記憶體回收，觀察中 data object這一欄中的 Total Size的大小是保持穩定還是有明顯的變大趨勢，如果有明顯的變大趨勢就說明這個Activity存在記憶體泄露的問題，我們就需要在具體分析。

2.使用Logcat檢測記憶體泄露

當記憶體回收機在進行記憶體回收之後，會在Logcat中作相對於的輸出，所以我們也可以通過這些資訊來判斷是否存在記憶體泄露問題

一，上面訊息的第一個部分產生GC的原因，一共有四種類型
GC_CONCURRENT   當你的堆記憶體快被用完的時候，就會觸發這個GC回收
GC_FOR_MALLOC  堆記憶體已經滿了，同時又要試圖分配新的記憶體，所以系統要回收記憶體
GC_EXTERNAL_ALLOC   在Android3.0 (Honeycomb)以前，釋放通過外部記憶體（比如在2.3以前，產生的BitmapObject Storage Service在Native Memory中）時產生。Android3.0和更高版本中不再有這種類型的記憶體配置了。
GC_EXPLICIT  調用System.gc時產生，中就是點擊Cause GC按鈕手動觸發記憶體回收行程產生的log資訊

二，freed 1413K表示GC釋放了1434K的記憶體

三，20% free 9349K/11644K， 20%表示目前可分配記憶體占的比例，9349K表示當前使用中的物件所佔記憶體，11644K表示Heap的大小

四，paused 8ms + 3ms， total 71ms,則表示觸發GC應用暫停時間和GC總共消耗的時間

有了這些log資訊，我們就可以知道GC運行幾次以後有沒有成功釋放出一些記憶體，如果分配出去的記憶體在持續增加，那麼很明顯存在記憶體泄露，如下存在記憶體泄露的Log資訊

很明顯Heap中空閑記憶體佔總Heap的比例在縮小，Heap中使用中的物件所佔的記憶體在增加。

記憶體泄露分析實戰

下面是一個存在記憶體泄露的例子代碼，這也是比較常見的一種記憶體泄露的方式，就是在Activity中寫一些內部類，並且這些內部類具有生命週期過長的現象

package com.example.memoryleak;import java.util.ArrayList;import java.util.List;import android.app.Activity;import android.os.Bundle;public class LeakActivity extends Activity {private List<String> list = new ArrayList<String>();@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);//類比Activity一些其他的對象for(int i=0; i<10000;i++){list.add("Memory Leak!");}//開啟線程new MyThread().start();}public class MyThread extends Thread{@Overridepublic void run() {super.run();//類比耗時操作try {Thread.sleep(10 * 60 * 1000);} catch (InterruptedException e) {e.printStackTrace();}}}}

運行例子代碼，選擇Devices視圖，點擊上面Updata Heap標籤，然後再旋轉螢幕，多重複幾次，然後點擊Dump HPROF file, 之後Eclipse的MAT外掛程式會自動幫我們開啟，如

我們看到下面有Histogram（長條圖）他列舉了每個對象的統計，Dominator Tree(支配樹）提供了程式中最占記憶體的對象的排列，這兩個是我在排查記憶體泄露的時候用的最多的

Histogram（長條圖)

我們先來看Histogram, MAT最有用的工具之一，它可以列出任意一個類的執行個體數。它支援使用Regex來尋找某個特定的類，還可以計算出該類所有對象的保留堆最小值或者精確值, 我們可以通過Regex輸入LeakActivity, 看到Histogram列出了與LeakActivity相關的類

我們可以看到LeakActivity,和MyThread內部類都存在16個對象，雖然LeakActivity和MyThread存在那麼多個物件，但是到這裡並不能讓我們準確的判斷這兩個對象是否存在記憶體泄露問題， 選中com.example.memoryleak.LeakActivity，點擊右鍵，如

Merge Shortest Paths to GC Roots 可以查看一個對象到RC  Roots是否存在引用鏈相串連, 在JAVA中是通過可達性（Reachability Analysis)來判斷對象是否存活，這個演算法的基本思想是通過一系列的稱謂"GC Roots"的對象作為起始點，從這些節點開始向下搜尋，搜尋所走得路徑稱為引用鏈，當一個對象到GC Roots沒有任何引用鏈相連則該對象被判定為可以被回收的對象，反之不能被回收，我們可以選擇 exclude all phantom/weak/soft etc.references(排查虛引用/弱引用/軟引用等）因為被虛引用/弱引用/軟引用的對象可以直接被GC給回收.

可以看到LeakActivity存在GC Roots鏈，即存在記憶體泄露問題，可以看到LeakActivity被MyThread的this$0持有。

除了使用Merge Shortest Paths to GC Roots 我們還可以使用

List object - With outgoing References   顯示選中對象持有那些對象

List object - With incoming References  顯示選中對象被那些外部對象所持有

Show object by class - With outgoing References  顯示選中對象持有哪些對象, 這些對象按類合并在一起排序

Show object by class - With incoming References  顯示選中對象被哪些外部對象持有, 這些對象按類合并在一起排序

Dominator Tree(支配樹）

它可以將所有對象按照Heap大小排序顯示, 使用方法跟Histogram（長條圖)差不多，在這裡我就不做過多的介紹了

我們知道上面的例子代碼中我們知道內部類會持有外部類的引用，如果內部類的生命週期過長，會導致外部類記憶體泄露，那麼你會問，我們應該怎麼寫那不會出現記憶體泄露的問題呢？既然內部類不行，我們就外部類或者static的內部類，如果我們需要用到外部類裡面的一些東西，我們可以將外部類Weak Reference傳遞進去

package com.example.memoryleak;import java.lang.ref.WeakReference;import java.util.ArrayList;import java.util.List;import android.app.Activity;import android.os.Bundle;public class LeakActivity extends Activity {private List<String> list = new ArrayList<String>();@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);//類比Activity一些其他的對象for(int i=0; i<10000;i++){list.add("Memory Leak!");}//開啟線程new MyThread(this).start();}public static class MyThread extends Thread{private WeakReference<LeakActivity> mLeakActivityRef;public MyThread(LeakActivity activity){mLeakActivityRef = new WeakReference<LeakActivity>(activity);}@Overridepublic void run() {super.run();//類比耗時操作try {Thread.sleep(10 * 60 * 1000);} catch (InterruptedException e) {e.printStackTrace();}//如果需要使用LeakActivity，我們需要添加一個判斷LeakActivity activity = mLeakActivityRef.get();if(activity != null){//do something}}}}

同理，Handler也存在同樣的問題，比如下面的代碼

package com.example.memoryleak;import android.app.Activity;import android.os.Bundle;import android.os.Handler;import android.os.Message;public class LeakActivity extends Activity {@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);MyHandler handler = new MyHandler();handler.sendMessageDelayed(Message.obtain(), 10 * 60 * 1000);}public class MyHandler extends Handler{@Overridepublic void handleMessage(Message msg) {super.handleMessage(msg);}}}

我們知道使用MyHandler發送訊息的時候，Message會被加入到主線程的MessageQueue裡面，而每條Message的target會持有MyHandler對象，而MyHandler的this$0又會持有LeakActivity對象， 所以我們在旋轉螢幕的時候，由於每條Message被延遲了 10分鐘，所以必然會導致LeakActivity泄露,所以我們需要將代碼進行修改下

package com.example.memoryleak;import java.lang.ref.WeakReference;import android.app.Activity;import android.os.Bundle;import android.os.Handler;import android.os.Message;public class LeakActivity extends Activity {MyHandler handler;@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);handler = new MyHandler(this);handler.sendMessageDelayed(Message.obtain(), 10 * 60 * 1000);}public static class MyHandler extends Handler{public WeakReference<LeakActivity> mLeakActivityRef;public MyHandler(LeakActivity leakActivity) {mLeakActivityRef = new WeakReference<LeakActivity>(leakActivity);}@Overridepublic void handleMessage(Message msg) {super.handleMessage(msg);if(mLeakActivityRef.get() != null){//do something}}}@Overrideprotected void onDestroy() {handler.removeCallbacksAndMessages(null);super.onDestroy();}}

上面的代碼就能保證LeakActivity不會被泄露，注意我們在Activity的onDestory方法中使用了handler.removeCallbacksAndMessages(null)，這樣子能保證LeakActivity退出的時候，每條Message的target  MyHandler也會被釋放， 所以我們在使用非static的內部類的時候，要注意該內部類的生命週期是否比外部類要長，如果是的話我們可以使用上面的解決方案。

常見的記憶體泄露問題

1.上面兩種情形

2.資來源物件沒有關閉，比如資料庫操作中得Cursor,IO操作的對象

3.調用了registerReceiver註冊廣播後未調用unregisterReceiver()來取消

4.調用了View.getViewTreeObserver().addOnXXXListener ,而沒有調用View.getViewTreeObserver().removeXXXListener

5.Android 3.0以前，沒有對不在使用的Bitmap調用recycle(),當然在Android 3.0以後就不需要了，更詳細的請查看http://blog.csdn.net/xiaanming/article/details/41084843

6.Contenx的泄露，比如我們在單例類中使用Context對象，如下

import android.content.Context;public class Singleton {private Context context;private static Singleton mSingleton;private Singleton(Context context){this.context = context;}public static Singleton getInstance(Context context){if(mSingleton == null){synchronized (Singleton.class) {if(mSingleton == null){mSingleton = new Singleton(context);}}}return mSingleton;}}

假如我們在某個Activity中使用Singleton.getInstance(this)或者該執行個體，那麼會造成該Activity一直被Singleton對象引用著，所以這時候我們應該使用getApplicationContext()來代替Activity的Context，getApplicationContext()擷取的Context是一個全域的對象，所以這樣就避免了記憶體泄露。相同的還有將Context成員設定為static也會導致記憶體泄露問題。

7.不要重寫finalize()方法，我們有時候可能會在某個對象被回收前去釋放一些資源，可能會在finalize()方法中去做，但是實現了finalize的對象，建立和回收的過程都更耗時。建立時，會建立一個額外的Finalizer 對象指向新建立的對象。 而回收時，至少需要經過兩次GC，第一次GC檢測到對象只有被Finalizer引用，將這個對象放入 Finalizer.ReferenceQueue 此時，因為Finalizer的引用，對象還無法被GC，
Finalizer$FinalizerThread 會不停的清理Queue的對象，remove掉當前元素，並執行對象的finalize方法，清理後對象沒有任何引用，在下一次GC被回收，所以說該對象存活時間更久，導致記憶體泄露。

如果大家還有一些記憶體泄露的情形歡迎提出來，我好更新下！

博主參加了CSDN 2014年度的部落格之星評選，希望大家有空幫忙投上一票，謝謝大家！

http://vote.blog.csdn.net/blogstar2014/details?username=xiaanming#content