一、先磨刀再砍柴，記憶體洩露相關介紹

  我們先來簡單重溫一下Java GC 的概念：GC即為Garbage Collection，垃圾回收機制。Java GC實質上也就是一個執行在Java虛擬機器（JVM）上的一個程式，它自動地管理著記憶體的使用，在適當的時機釋放並回收無用的記憶體分配。使得我們不用像寫C++那樣手動釋放記憶體，從而幫助我們釋放雙手。那它是如何知道哪些記憶體分配是無用的，而哪些是有用的呢？借用一下2011年Google I/O的一張圖：

  垃圾回收機制設定了一個根節點GC Roots，然後從根節點開始往下進行遍歷，凡是能被直接或間接訪問到的子節點，都認為其是仍然有用的，不應該被回收的，也就是圖中的黃色節點。而無法被遍歷到的藍色節點，即被認為是無用的，應該被回收的記憶體區域。
  那什麼是記憶體洩露呢？簡單來說就是：不應該被GC Roots訪問到到的記憶體，仍能被訪問到，GC Roots誤以為這塊記憶體區域並不是垃圾，導致該回收的記憶體沒被回收。久而久之，記憶體洩露越來越嚴重，舊的垃圾記憶體得不到回收，新的垃圾記憶體不斷增加，可用的記憶體也就越來越少。JVM為了申請新的記憶體空間，頻繁觸發GC，程式執行效率將會受到影響，程式甚至直接丟擲Out Of Memory Exception異常退出。

  下面我們來熟悉一下Android開發中容易出現的記憶體洩漏場景：

1、靜態變數引用Activity

  靜態變數是駐紮在JVM的方法區，因此，靜態變數引用的物件是不會被GC回收的，因為它們所引用的物件本身就是GC ROOT。如果實在要用這樣彆扭的寫法，記得在onDestroy()裡把mActivity置為null。

public class TopicDetailActivity extends AppCompatActivity {
    private static Activity mActivity;

    public static void enterActivity
 
(Activity activity) {
        mActivity = activity;
        Intent intent = new Intent(activity, TopicDetailActivity.class)；
        activity.startActivity(intent);
    }
}

2、非靜態內部類

  非靜態內部類（包括匿名內部類）預設會持有外部類例項，如果內部類的生命週期長於外部類，則可能導致記憶體洩漏。可以考慮改成靜態內部類，或者新建立一個檔案，把內部類挪過去。

public class MainActivity
 
 extends AppCompatActivity {  
    @Override  
    protected void onCreate(Bundle savedInstanceState) {  
        super.onCreate(savedInstanceState);  
        setContentView(R.layout.activity_main);  
        MyThread myThread = new MyThread();  
        myThread.start();  
    }  

    class MyThread extends Thread {  
        @Override  
        public void run() {  
            while (true) {  
                try {  
                    Thread.sleep(65536);  
                } catch (InterruptedException e) {  
                    e.printStackTrace();  
                }  
            }  
        }  
    }  
}  

3、Activity內View不被釋放

  一旦View attach到我們的Window上，就會持有一個Context(即Activity)的引用。如果View無法被釋放，Activity也無法被釋放。

public class MainActivity extends AppCompatActivity {

    private static TextView tv;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        tv = (TextView) findViewById(R.id.tv);
        tv.setText("Hello world");
    }
}

4、Handler

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Handler handler = new Handler(){
            @Override
            public void handleMessage(Message msg) {

            }
        };
        handler.postDelayed(new Runnable() {
            @Override
            public void run() {

            }
        }, Integer.MAX_VALUE);
    }
}

  同第二點，程式碼中new了一個Handler的匿名內部類，預設持有Activity。我們知道，主執行緒的Looper物件不斷從訊息佇列中取出訊息，然後再交給Handler處理。而每個Message物件是持有Handler的引用的（Message物件的target屬性持有Handler引用），從而導致Message間接引用到了Activity。如果在Activty destroy之後，訊息佇列中還有Message物件，Activty是不會被回收的。同樣是，可以把匿名內部類改成靜態內部類，或挪到另一個檔案中去。還可以在onDestroy()時，removeCallbacks或removeCallBacks來清除MessageQueue殘留的Message，已保證Activity不會被Message hold住。

5、監聽器

  在Activity裡註冊BroadcastReceiver或EventBus等忘記反註冊。

二、步入正題，學用MAT

MAT是一種快速，功能豐富的Java堆分析工具，用於分析hprof檔案，幫助你查詢記憶體洩漏和減少記憶體消耗。

1、獲取hprof檔案

  首先，我們開啟Android Studio，除錯好ADB相關，並run起我們的工程，這裡確保一下我們的工程存在記憶體洩漏的Activity（- -因為如果沒有記憶體洩漏存在，那就沒得分析啦，巧婦難為無米之炊啊）。我們不停地在頁面間進行跳轉，最後回到起始的MainActivity。然後，在AS的左下角可以找到一個名為”Android Monitor”的欄目，點開之後再從我們常用的”logcat”切換到”Monitors”下，此時可以看見已連線手機的記憶體、CPU、GPU等使用情況。點選”Memory”項裡紅框選中的按鈕”Dump Java Heap”。

  稍等片刻，我們就會得到一個“不完整”的hprof檔案，AS會自動幫我們開啟這個檔案。（注意，這個hprof還不能用MAT開啟，強行用MAT開啟會報錯！）

  點選右邊的Analyzer Tasks，會有意外的驚喜喲~沒錯！AS居然自帶了方便我們排查Activity記憶體洩露的工具。

2、意外的收穫，AS自帶的分析工具

  勾選”Detect Leaked Activities”，然後點選綠色的”>”按鈕，分析結果就出來了。展開分析結果裡的”Leaked Activities”就可以看到哪些Activity存在記憶體洩漏問題。這裡可以看出TopicDetailActivity明顯就洩漏了，因為我dump hprof檔案時，已經回到起始的MainActivity了且Activity棧不存在TopicDetailActivity的例項了，所以記憶體中不應該有那麼多TopicDetailActivity的例項：@601142272，@603487232等。這些例項都應該被GC回收，而沒有被回收！查詢記憶體洩漏是不是So easy啊~。嗯(⊙_⊙)，雖然每天用AS都卡得飛起，但是這個分析工具還是值得肯定的，方便，準確！

  好了，我們現在知道，哪些Activity被洩漏了，但是我們仍然不知道它們為什麼會被洩漏。剛開篇的時候，我們說到，能被GC Roots直接或間接訪問到的例項是不會被回收的。Activity洩漏和其他記憶體洩漏一樣，都是因為被某個長時間不會被銷燬的傢伙給引用了，而這個傢伙能被GC Roots訪問到。接著，我們就來看看是誰hold住了Activity又不肯放手。

  選中某個已知洩漏的Activity，可以檢視其Reference Tree。這裡列出了所有引用TopicDetailActivity的物件，一眼望過去，圖中引用TopicDetailActivity例項的物件有View類的，比如TextView，也有非View類，比如ContextImpl。這裡注意一下，AS會把重點懷疑物件用藍色字型標示出來，這裡標出來的是CursorWatcherEditTextView（這裡宣告一下，它是EditText的子類），洩漏的原因八九不離十就是這個自定義View。那又是什麼導致CursorWatcherEditTextView Hold住了Activity呢。這裡再繼續展開Reference Tree也不容易看出個所以然來。要想進一步深入還得使用MAT。
  我們來匯出一個”完整版”的hprof。點選AS左上角的歪脖”Captures”，然後按圖示”Export to standard.hprof”，選好匯出位置再匯出就好了

3、主角登場，MAT使用簡介

  接下來我們用MAT開啟hprof檔案：

  注意紅框裡圈出的兩個Action，分別是用兩種不同角度檢視記憶體的使用情況。
  Histogram根據以class為基本單位，來列舉每個類各有多少個例項（Objects），Shallow Heap代表這個類的所有例項佔有的記憶體大小。然後也沒啥好看的了，我們再去看看Dominator Tree。

  Dominator Tree會從大到小列舉出一些當前記憶體中佔用最大記憶體的物件。Shallow Heap的概念與Histogram裡的一樣。Retained Heap代表如果這個物件被回收，有多少記憶體能被真正釋放，其中包括了Shallow Heap（自身佔有的記憶體） + 只被這個物件Hold住的其他物件。Percentage則表示佔比，這很簡單。

  剛才我們已經通過AS分析工具，得知TopicDetailActivity這個頁面存在記憶體洩漏，故在搜尋框裡輸入TopicDetailActivity。在以上兩種Tab下，選中某一欄右鍵都能看到一系列的操作。

  這裡我們只介紹一下”List Object”和”Merge Shortest Paths to GC Roots”，其他的大家自己去摸索哈。
  List Object也有兩個可選的“with outgoing reference”：檢視這個物件它引用了誰，”with incoming reference”：檢視是誰引用了這個物件，又是兩種不同的角度。排查記憶體洩漏，我們肯定是看incoming，因為只有被引用才可能被hold住，才可能記憶體洩漏。放上incoming的圖，大家自行感受一下。

  由上圖可見，總共有306個例項引用了TopicDetailActivity，一個個排查過去不得爆炸..所以我們化繁為簡，用”Merge Shortest Paths to GC Roots”->”exclude weak/soft references”（排除掉弱引用和軟引用，因為他們不會造成記憶體洩漏）：從GC Roots開始找一條能到達Activity的最短的路徑，這往往就是記憶體洩漏的真正原因。

  然後逐級展開到底，我們能看到TopicDetailActivity例項。然後，簡單介紹一下如何看這個圖。我們從下往上看，Activity被CursorWatcherEditText hold住了，而Activity的引用被賦值在CursorWatcherEditText的mContext變數域裡，同理，CursorWatcherEditText被Editor hold住了，CursorWatcherEditText的引用被賦值在Editor的mTextView變數域裡，以此類推。那這個記憶體洩漏到底是為什麼呢？這個問題可能比較複雜，我們慢慢理清邏輯。

  CursorWatcherEditText持有TopicDetailActivity這很正常，因為我們之前說過，一旦View attach到我們的Window上，就會持有其Activity的引用。我們再往上找原因。因為CursorWatcherEditText繼承自EditText，EditText繼承自TextView，通過看TextView.java的原始碼可知，在new 成員變數mEditor的時候，會把TextView例項自身傳給mEditor，然後被儲存在Editor例項的mTextView成員變數域內，這依舊沒啥問題。

  然後我們再往上看，噫，Editor被他自己的內部類Blink hold住了，找到Blink類，這貨居然不是靜態的內部類，還是個Handler，還實現了Runnable，極有可能就是這個導致的記憶體洩露。

  我們最後往上看一次- -，一眼看完，Path上端還真的有Message，MessageQueue，就是我們之前說的因為仍有殘留的Message hold住了Handler導致的記憶體洩漏。好了，這條Path總算是摸清了，但是新的問題又出現了，為什麼會有殘留的Message，是不是我們用EditText的姿勢不對或者說是Extends的時候出了什麼問題。雖然不太明白，但是我們進一步閱讀原始碼後發現，Blink與Cursor以及Focus息息相關，並且TextView#setEnabled(boolean enabled)裡有這麼一行，會嘗試呼叫blink.removeCallbacks：
，在onDestroy()裡呼叫editReply.setEnabled(false);，記憶體洩漏得到解決