綜述

內(nèi)存泄漏(memory leak)是指由于疏忽或錯誤造成程序未能釋放已經(jīng)不再使用的內(nèi)存。那么在Android中，當一個對象持有Activity的引用，如果該對象不能被系統(tǒng)回收，那么當這個Activity不再使用時，這個Activity也不會被系統(tǒng)回收，那這么以來便出現(xiàn)了內(nèi)存泄漏的情況。在應(yīng)用中內(nèi)出現(xiàn)一次兩次的內(nèi)存泄漏獲取不會出現(xiàn)什么影響，但是在應(yīng)用長時間使用以后，若是存在大量的Activity無法被GC回收的話，最終會導致OOM的出現(xiàn)。那么我們在這就來分析一下導致內(nèi)存泄漏的常見因素并且如何去檢測內(nèi)存泄漏。

導致內(nèi)存泄漏的常見因素

情景一：靜態(tài)Activity和View

靜態(tài)變量Activity和View會導致內(nèi)存泄漏，在下面這段代碼中對Activity的Context和TextView設(shè)置為靜態(tài)對象，從而產(chǎn)生內(nèi)存泄漏。

import android.content.Context; 
import android.support.v7.app.AppCompatActivity; 
import android.os.Bundle; 
import android.widget.TextView; 
  
public class MainActivity extends AppCompatActivity { 
  
    private static Context context; 
    private static TextView textView; 
  
    @Override 
    protected void onCreate(Bundle savedInstanceState) { 
        super.onCreate(savedInstanceState); 
        setContentView(R.layout.activity_main); 
        context = this; 
        textView = new TextView(this); 
    } 
} 

情景二：Thread，匿名類，內(nèi)部類

在下面這段代碼中存在一個非靜態(tài)的匿名類對象Thread，會隱式持有一個外部類的引用LeakActivity，從而導致內(nèi)存泄漏。同理，若是這個Thread作為LeakActivity的內(nèi)部類而不是匿名內(nèi)部類，他同樣會持有外部類的引用而導致內(nèi)存泄漏。在這里只需要將為Thread匿名類定義成靜態(tài)的內(nèi)部類即可(靜態(tài)的內(nèi)部類不會持有外部類的一個隱式引用)。

public class LeakActivity extends AppCompatActivity { 
  
    @Override 
    protected void onCreate(Bundle savedInstanceState) { 
        super.onCreate(savedInstanceState); 
        setContentView(R.layout.activity_leak); 
        leakFun(); 
    } 
  
    private void leakFun(){ 
        new Thread(new Runnable() { 
            @Override 
            public void run() { 
                try { 
                    Thread.sleep(Integer.MAX_VALUE); 
                } catch (InterruptedException e) { 
                    e.printStackTrace(); 
                } 
            } 
        }); 
    } 
}  

情景三：動畫

在屬性動畫中有一類無限循環(huán)動畫，如果在Activity中播放這類動畫并且在onDestroy中去停止動畫，那么這個動畫將會一直播放下去，這時候Activity會被View所持有，從而導致Activity無法被釋放。解決此類問題則是需要早Activity中onDestroy去去調(diào)用objectAnimator.cancel()來停止動畫。

public class LeakActivity extends AppCompatActivity { 
  
    private TextView textView; 
    @Override 
    protected void onCreate(Bundle savedInstanceState) { 
        super.onCreate(savedInstanceState); 
        setContentView(R.layout.activity_leak); 
        textView = (TextView)findViewById(R.id.text_view); 
        ObjectAnimator objectAnimator = ObjectAnimator.ofFloat(textView,"rotation",0,360); 
        objectAnimator.setRepeatCount(ValueAnimator.INFINITE); 
        objectAnimator.start(); 
    } 
}  

情景四：Handler

對于Handler的內(nèi)存泄漏在(Android的消息機制——Handler的工作過程)[http://blog.csdn.net/ljd2038/article/details/50889754]這篇文章中已經(jīng)詳細介紹，就不在贅述。

情景五：第三方庫使用不當

對于EventBus，RxJava等一些第三開源框架的使用，若是在Activity銷毀之前沒有進行解除訂閱將會導致內(nèi)存泄漏。

使用MAT檢測內(nèi)存泄漏

對于常見的內(nèi)存泄露進行介紹完以后，在這里再看一下使用MAT(Memory Analysis Tool)來檢測內(nèi)存泄露。MAT的下載地址為：http://www.eclipse.org/mat/downloads.php。

下面來看一段會導致內(nèi)存泄露的錯誤代碼。

public class LeakActivity extends AppCompatActivity { 
  
    @Override 
    protected void onCreate(Bundle savedInstanceState) { 
        super.onCreate(savedInstanceState); 
        setContentView(R.layout.activity_leak); 
        EventBus.getDefault().register(this); 
    } 
  
    @Subscribe 
    public void subscriber(String s){ 
  
    } 
}  

在上面這段代碼中有會導致內(nèi)存泄漏，原因是EventBus沒有解除注冊。下面就以這段代碼為例來看一下如何分析內(nèi)存泄漏。

打開AndroidStudio中的Monitors可以看到如下界面。   

在這里可以看到在應(yīng)用剛啟動的時候，所占用的內(nèi)存為15M，然后我們現(xiàn)在開始操作APP，反復(fù)進入退出LeakActicity。點擊上如中的GC按鈕。這時候我們在看一下內(nèi)存使用情況。 

在這里我們可以看到，內(nèi)存一直在持續(xù)增加，已經(jīng)達到33M，并且無法被GC所回收。所以我們可以判斷，這時候必然出現(xiàn)內(nèi)存泄漏的情形。那么現(xiàn)在再點擊Dump Java Heap按鈕，在captures窗口看到生成得hprof文件。但這時候所生成的hprof文件不是標準格式的，我們需要通過SDK所提供的工具hprof-conv進行轉(zhuǎn)化，該工具在SDK的platform-tools目錄下。執(zhí)行命令如下：

hprof-conv XXX.hprof converted-dump.hprof 

當然在AndroidStudio中可以省去這一步，可以直接導出標準格式的hprof文件。 

這時候可以通過MAT工具來打開導出的hprof文件。打開界面如下圖所示： 

在MAT中我們最常用的就是Histogram和Dominator Tree，他們分別對應(yīng)上圖中的A和B按鈕。Histogram可以看出內(nèi)存中不同類型的buffer的數(shù)量和占用內(nèi)存的大小，而Dominator Tree則是把內(nèi)存中的對象按照從大到小的順序進行排序，并且可以分析對象之間的引用關(guān)系。在這里再來介紹一下MAT中兩個符號的含義。

• ShallowHeap:對象自身占用的內(nèi)存大小，不包括他引用的對象
• RetainedHeap:對象自身占用的內(nèi)存大小并且加上它直接或者間接引用對象的大小

Histogram

由于在Android中一般內(nèi)存泄漏大多出現(xiàn)在Acivity中，這時候可以點擊Histogram按鈕，并搜索Activity。   

在這里可以看出LeakActivity存在69個對象，基本上可以斷定存在內(nèi)存泄漏的情形，這時候便可以通過查看GC對象的引用鏈來進行分析。點擊鼠標右鍵選擇Merge Shortest paths to GC Roots并選擇exclude weak/soft references來排除弱引用和軟引用。 

在排除軟引用和弱引用以后如下圖所示： 

在這里可以看出由于EventBus導致的LeakActivity內(nèi)存泄漏。

在Histogram中還可以查看一個對象包含了那些對象的引用。例如，現(xiàn)在要查看LeakActivity所包含的引用，可以點擊鼠標右鍵，選擇list objects中的with incoming reference。而with outcoming reference表示選中對象持有那些對象的引用。 

Dominator Tree

現(xiàn)在我們點擊這時候可以點擊Dominator Tree按鈕，并搜索Activity?？梢钥吹饺缦聢D所示： 

在這里可以看到存在大量的LeakActivity。然后點擊鼠標右鍵選擇Path To GC Roots->exclude weak/soft references來排除弱引用和軟引用。 

之后可以看到如下結(jié)果，依然是EventBus導致的內(nèi)存泄漏： 

總結(jié)

內(nèi)存泄漏往往被我們所忽略，但是當大量的內(nèi)存泄漏以后導致OOM。它所造成的影響也是不容小覷的。當然除了上述內(nèi)存泄漏的分析以為我們還可以通過LeakCanary來分析內(nèi)存泄漏。對于LeakCanary的使用在這里就不在進行詳細介紹。