本文在騰訊技術推文上 修改 發佈。
http://wetest.qq.com/lab/view/63.html?from=ads_test2_qqtips&sessionUserType=BFT.PARAMS.195040.TASKID&ADUIN=913337456&ADSESSION=1468996652&ADTAG=CLIENT.QQ.5431_.0&ADPUBNO=26510
自從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的對象沒有被回收掉。
舉個例子
mLeak是存儲在靜態區的靜態變量，而Leak是內部類，其持有外部類Activity的引用。這樣就導致Activity需要被銷燬時，由於被mLeak所持有，所以系統不會對其進行GC，這樣就造成了內存泄漏。
再舉一個最常犯的例子
如果我們在在調用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啦，分析出來如下圖所示
在Reference Tree裏面，我們直接就可以看到持有該Activity的單例對象，直接定位到該單例中的代碼，發現代碼中出現了
和剛剛舉得例子裏出現的錯誤一模一樣，我們修復了檢查出的內存泄漏的問題，並將修復前和修復後的代碼在相同的模擬器上運行並進行相同的操作，查看他們使用內存的情況，如下圖所示
有內存泄漏的情況，佔用內存約爲43M
