android DDMS中的內存監測工具Heap

DDMS中自帶的Heap工具能夠顯示出當前堆內存的狀況，分配內存、剩餘的內存等信息。

首先是進入DDMS，運行應用，在DDMS的左邊區域選中應用的包名，而後點擊上方的update heap圖標。

點擊後控制檯就會被觸發了，但如今控制檯可能沒有下面的信息，由於只有在GC後控制檯纔會真正觸發。因此能夠點擊Cause GC按鈕，而後就能夠看到下面的信息了。

說明：當內存使用信息第一次顯示之後，無須再不斷的點擊「Cause GC」，Heap視圖界面會定時刷新，在對應用的不斷的操做過程當中就能夠看到內存使用的變化

這些數據包括當前的數據對象個數，類對象個數，咱們主要關注的是最上面的那個彙總欄（有ID的那個表格），還有下面的data object（數據對象，也就是咱們的程序中大量存在的類類型的對象）。

在data object一行中有一列是「Total Size」，其值就是當前進程中全部Java數據對象的內存總量，通常狀況下這個值的大小決定了是否會有內存泄漏。能夠這樣判斷：

a) 不斷的操做當前應用，同時注意觀察data object的Total Size值；

b) 正常狀況下Total Size值都會穩定在一個有限的範圍內，也就是說因爲程序中的的代碼良好，沒有形成對象不被垃圾回收的狀況，因此說雖然咱們不斷的操做會不斷的生成不少對象，

而在虛擬機不斷的進行GC的過程當中，這些對象都被回收了，內存佔用量會會落到一個穩定的水平；

c) 反之，若是代碼中存在沒有釋放對象引用的狀況，則data object的Total Size值在每次GC後不會有明顯的回落，隨着操做次數的增多Total Size的值會愈來愈大， 

直到到達一個上限後致使進程被Kill掉，這就是咱們不但願的！

下面是一個例子，經過不斷滑動照片牆來加載新的圖片，從下面的動態圖能夠看見，當舊的圖片被移出屏幕的時候引用了GC，佔用的內存有明顯的回落，接着開始上升（由於又加載了新的圖片），但上升到必定程度便不會繼續升高，這就說明這個程序不會不斷的產生大量的對象，不太會出現OOM。

另外還可使用heap dump來追蹤內存信息。點擊DDMS工具條上面的Dump HPROF文件按鈕，選擇文件存儲位置（默認選擇：D:\tools\android-sdk\tools） 

這個由DDMS生成的文件不能直接用MAT工具打開，會提示文件格式不支持。須要轉化：

（1）運行cmd，cd 到 D:\tools\android-sdk\tools目錄下

（2）輸入命令hprof-conv  xxxxold.hprof  yyyynew.hprof           xxxx.hprof 爲原文件，yyyy.hprof 爲轉化事後的文件(一樣生成在D:\tools\android-sdk\tools目錄下)

備註：

若是使用ADT（它包含DDMS的插件）同時也在eclipse裏面安裝了MAT，點擊「dump HPROF」按鈕將會自動地作轉換（用hprof-conv），同時會在eclipse裏面打開轉換後的hprof文件（它其實用MAT打開）。