自從Google在2013年釋出了Android Studio後，Android Studio憑藉著自己良好的記憶體優化，酷炫的UI主題，強大的自動補全提示以及Gradle的編譯支援正逐步取代Eclipse，成為主流的Android開發IDE。Android Studio在為我們提供了良好的編碼體驗的同時，也提供了許多對App效能分析的工具，讓開發者可以更方便分析App效能。Google在IO大會上一直告誡開發者不要無節制的使用手機記憶體，要注意一些不良的開發習慣會導致App的記憶體洩漏。雖然如今網上檢測App記憶體洩漏的文章汗牛充棟，但是要使用DDMS和MAT，不僅使用步驟複雜繁瑣，而且要手動排查記憶體洩漏的位置，操作起來多有不便。其實Android Studio已經開始支援自動進行記憶體洩漏檢查了，本文就帶著大家一探其中的奧妙吧。

什麼是記憶體洩漏
Android虛擬機器的垃圾回收採用的是根搜尋演算法。GC會從根節點（GC Roots）開始對heap進行遍歷。到最後，部分沒有直接或者間接引用到GC Roots的就是需要回收的垃圾，會被GC回收掉。而記憶體洩漏出現的原因就是存在了無效的引用，導致本來需要被GC的物件沒有被回收掉。

舉個栗子

    private static Leak mLeak;

    @Override
    protectedvoidonCreate(Bundle savedInstanceState){
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_second);
        mLeak = new
 
 Leak();
    }

    classLeak{
    }

mLeak是儲存在靜態區的靜態變數，而Leak是內部類，其持有外部類Activity的引用。這樣就導致Activity需要被銷燬時，由於被mLeak所持有，所以系統不會對其進行GC，這樣就造成了記憶體洩漏。

再舉一個最常犯的栗子

public classSingleton{
    private static Singleton instance;
    private Context mContext;
    privateSingleton(Context context){
        this.mContext = context;
    }

    public
 
static Singleton getInstance(Context context){
        if (instance == null){
            synchronized (Singleton.class){
                if (instance == null){
                    instance = new Singleton(context);
                }
            }
        }
        return instance;
    }
}

如果我們在在呼叫Singleton的getInstance()方法時傳入了Activity。那麼當instance沒有釋放時，這個Activity會一直存在。因此造成記憶體洩露。
解決方法可以將new Singleton(context)改為new Singleton(context.getApplicationContext())即可，這樣便和傳入的Activity沒關係了。

記憶體洩漏的檢測
開啟Android Studio，編譯程式碼，在模擬器或者真機上執行App，然後點選，在Android Monitor下點選Monitor對應的Tab，進入如下介面

在Memory一欄中，可以觀察不同時間App記憶體的動態使用情況，點選可以手動觸發GC，點選可以進入HPROF Viewer介面，檢視Java的Heap，如下圖

Reference Tree代表指向該例項的引用，可以從這裡面檢視記憶體洩漏的原因，Shallow Size指的是該物件本身佔用記憶體的大小，Retained Size代表該物件被釋放後，垃圾回收器能回收的記憶體總和。
下面我們以掌上道聚城客戶端為例，來一探記憶體洩漏檢測的方法。
開啟Android Studio，編譯程式碼，執行掌上道聚城，然後開始盡情的耍我們的App啦，然後就從Memory Monitor裡面觀察App的記憶體使用曲線，突然發現，納尼！！！怎麼記憶體使用越來越大了，這就很有可能是發生記憶體洩漏了，然後點選手動進行GC，再點選觀看JavaHeap，點選Analyzer Task，Android Monitor就可以為我們自動分析洩漏的Activity啦，分析出來如下圖所示

publicstatic VideoTagHelper getInstance(Context context) {
        if (tagHelper == null) {
            tagHelper = new VideoTagHelper();
        }
        tagHelper.context = context;
        return tagHelper;
    }

和剛剛舉得栗子裡出現的錯誤一模一樣啊，這段程式碼是誰寫的，拖出去······
我們修復了檢查出的記憶體洩漏的問題，並將修復前和修復後的程式碼在相同的模擬器上執行並進行相同的操作，檢視他們使用記憶體的情況，如下圖所示