Android內存洩漏的簡單檢查與分析方法

方法2：通過代碼檢測Activity洩漏

基本思路：

1）debug版本可以起一個長期工作的線程LeakThread在後台專門做洩漏檢測

2）向Application注冊一個 頁面生命周期 的監聽：application.registerActivityLifecycleCallbacks

3）在監聽類中對 onActivityDestoryed(Activity activity) 的事件回調做處理：

如果一個Activity走到onDestroy，那麼這個Activity對象就是需要被回收的目標。

我們聲明一個檢測對象的弱引用ref = new WeakReference(activity)。

PS：與強引用和軟引用相比，弱引用不會被回收器當做一個“有效”的引用，不會影響其引用對象的釋放。實際上，垃圾回收器會毫不猶豫地回收只有弱引用的對象~

4）在 LeakThread中我們每隔一段時間檢測一下ref.get() 是否為空，為空說明activity已被釋放。不為空可以手動觸一次發gc；如果超過一段時間，比如50s，頁面對象還未被清理，我們可以推斷內存洩漏的發生.

5）當內存洩漏發生時，提示給開發者，並自動dump出.prof文件。

因為代碼檢測不是這裡的重點，代碼就不貼了，只記思路。

三、分析內存洩漏（DDMS dump + MAT分析）

發現可能出現內存洩漏時，我們需要對.prof文件進行分析，方能快速定位到是哪個倒霉家伙導致了內存洩漏

3.1、如何dump出.prof文件？（可參照前文圖片）

打開DDMS ，Eclipse 可以切到DDMS視圖，Android studio可以從Tools-Android-Android device monitor進入DDMS

找到app的進程，在進程上方點擊“update heap”按鈕，可以先主動出發一次GC，待內存占用數據稍微穩定下來後 點擊“Dump HProf File”，便可以導出.prof文件

3.2：導出.prof文件後如何分析？

Android studio可以直接打開prof文件。點開Analyzer Tasks的面板，點擊右上角的開始按鈕。

分析完成後，發生內存洩漏的頁面對象會出現在Analysis Results面板-Leak Activityes的目錄下。

如圖，原來洩漏發生是LoadingRoomActivity的鍋！

3.3 進一步分析洩漏的原因，你會需要一個好用的內存分析工具：MAT

在官網可以下載到它：

http://www.eclipse.org/mat/downloads.php

雖然MAT不會准確告訴你你的代碼哪洩漏了，但是它會給你發現哪洩露的數據和線索。

3.3.1 打開.hprof前可能遇到的問題：

在MAT中打開.prof頁面，你可能會遇到一點小挫折：

如上圖，可能會彈出 ‘Parsing heap dump from xxx has encountered a proplem’ 的錯誤彈窗

這是因為文件版本和編輯器能支持的版本有沖突的原因。

解決方案如下：

Sdk安裝目錄下platform-tools裡有一個hprof-conv工具可以解決該問題。在cmd控制台執行：

hprof-conv input.hprof output.hprof

重新再MAT打開output.hprof 就可以打開了~

值得一提的是，如果你dump出的文件太大的話，也有可能發現打不開的現象，這時候，打開安裝MAT目錄下的MemoryAnalyzer.ini 把-XmX改大些重啟即可。但是也不要改得比你機器的可用內存還大，不能太貪心哈哈~

3.3.2 打開.phrof文件後的分析

通過MAT打開.phrof文件後，會彈出Overview 和 Leak Suspects 2個標簽頁。

Leak Suspects標簽頁可見如下圖：

Leak Suspects視圖展示了app內存占用的比例，淺色是空閒的內存，其他是內存占用的空間。每塊內存對應的問題也都列在下面。點開每個Problem Suspect下的details，可以看到有哪些類的實例占用了內存和占用大小等信息~

此時我們已經有了懷疑的目標，為了更清晰地查看，我們可以回到Overview頁面，打開Histogram頁面：

在打開的Histogram標簽頁中，我們填入檢測對象，在列出的匹配項中過濾掉對象的非強引用。

到這裡我們就可以看到，是哪個壞蛋hold住了你的對象了。MAT能夠給到的支持也就到這裡，接下來，還是需要你根據這些線索到代碼中尋找判別和修正了~“