最近在做一個照片牆的應用，涉及到很多知識，其中難點在於如何應對數量龐大的圖片，這就涉及到內存管理的知識了。今天介紹的工具是DDMS中自帶的Heap，它可以顯示出當前引用占用的內存，剩余的內存等信息。下面我們就來使用它吧~
首先是進入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。
參考自：
http://blog.csdn.net/qeqeqe236/article/details/7338608