使用 Android Studio 檢測內存洩漏與解決內存洩漏問題

　　自從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

 　　修復了內存洩漏問題，占用內存為36M在修復了內存洩漏問題後，內存使用下降了16.3%！！！掌握了Android Monitor的使用方法後，相信能在android開發的路上助各位一臂之力。