工作中遇到挺多需要分析記憶體洩露問題的情況，現在大致簡要寫下思路，等之後時間相對比較充裕再進行補充。

1.明白記憶體洩露的判斷依據？

個人總結為：持續增加，只增不減！

理解一下這8個字，配合幾個命令和工具來確定一下你的應用是否存在記憶體洩露問題，這是很關鍵的，如果一開始就判斷錯誤了，那麼沒有繼續往下進行的理由。

命令如下： 

adb shell

dumpsys meminfo 應用包名 [當然，比較粗略地話，可以用adb shell procrank]

這時候你可以看到一個記憶體使用情況表

而我們首先關注的是TOTAL這個值，譬如你會執行某個指令碼，或者Monkey在不斷操作你的應用，你可以隔半個小時觀察一次TOTAL的情況，如果持續增加，那麼十有八九是有記憶體洩露的問題了，但是也並不是絕對，這時候你就要配合上DDMS工具來做分析了。（DDMS裡面有一項Heap，裡面可以Cause GC，如果你發現你執行了GC之後，依舊記憶體沒有什麼太大的減少，那麼恭喜你，這部分記憶體洩露了。）

2.根據第一步所闡述的一個情況，大概可以判斷出是否有記憶體洩露，那麼接著需要做什麼呢？

如果記憶體洩露，那麼我們該做些什麼呢？

思路：必定我們想要找到洩露點，那麼如何找到？

（1）. 你需要抓取hprof檔案，這個檔案可以呈現出一些記憶體的使用情況，不過切記，你別清除了程序再來抓這個檔案，然後配合著MAT把這個hprof檔案分析了

（MAT分析hprof檔案的這方面知識網上太齊全了，讀者們可以自己去學習一下哈，這裡就不累贅）

（2）.如果MAT分析出來的東東，你實在看不出什麼貓膩，那麼再次恭喜你，你中大招了。

這時候你要繼續觀察dumpsys meminfo 包名， 輸出的結果資訊，關注點放在 UnKnown那一行 和 Native Heap 那一行，關注Heap Alloc 或者 Pss Total, 

如果你的總TOTAL一直再增加，但是是由於這兩行的增加，那麼這個問題你不需要再繼續在MAT上花時間了，因為這種記憶體洩露問題，出在Native層（C）

那麼你需要去找你程式中使用到JNI的地方，so庫或者其他一些特殊呼叫上，分析它們是否可能造成記憶體洩露問題。

（3）當然興許你依舊沒有頭緒，那麼沒關係，另一個命令就是為了你而存在的，（首先某個應用的PID號, 用dumpsys meminfo 包名，那邊已經可以查到）

譬如我上面那個mms, PID號為2786， 接著adb shell showmap -a PID號 (adb shell 

然後根據結果[....]這的資訊，在去google上面找關鍵字， 譬如：[ anon ] bash的堆

（4）當你最終還是不知道是由哪邊的.so庫引起的話，你可以檢視下Native Heap的記憶體分配情況，這時候你依舊需要藉助DDMS，

需要先執行以下命令：

adb shell setprop libc.debug.malloc 1

adb shell stop

adb shell start

然後你還需要改一下eclipse中的配置引數值【因為如果你不配置的話，你的DDMS開啟預設是看不到Native Heap那個Tab項的】

在ddms.cfg檔案（實在找不到的話，就用Everything搜尋下吧）最後增加一行native=true並save。ddms.cfg位於c:\Users\xxx\.android目錄下。

在Device中選擇好你要的應用的包名項，然後按下Snapshot按鈕， 就可以觀察到Native Heap的使用情況了，然後反覆執行指令碼，再觀察觀察，你會找到你需要的東西的。

（5）記憶體洩露的問題可能很複雜，但是有的時候有了這些技巧，相對更重要。所以第（5）小點，額外再提供一些其他的命令技巧，幫助查詢另外的情況出現記憶體洩露的問題。

1.  adb shell dumpsys activity    查詢activity棧的情況（曾遇到過，就是activity一直堆積，導致的記憶體溢位OOM）

        2.  adb shell dumpsys cpuinfo

        3.  adb shell dumpsys battery

如果你在這方面有自己其他的一些方法，那麼也不妨留言跟大家分享下！

檔案：/proc/meminfo

          /proc/buddyinfo

簡單粗暴就直接通過: showmap 命令 多次，然後對比一下，看哪個增長得最明顯。

轉載請註明：http://blog.csdn.net/ljphhj/article/details/44966023

轉載於 胖虎 CSDN