2. 將手機通過USB連結至電腦，連結時需要確認手機是處於“USB除錯”模式，而不是作為“Mass Storage”；

3. 連結成功後，在DDMS的Devices檢視中將會顯示手機裝置的序列號，以及裝置中正在執行的部分程序資訊；

4. 點選選中想要監測的程序，比如system_process程序；

5. 點選選中Devices檢視介面中最上方一排圖示中的“Update Heap”圖示；

6. 點選Heap檢視中的“Cause GC”按鈕（清理記憶體）；

7. 此時在Heap檢視中就會看到當前選中的程序的記憶體使用量的詳細情況。
說明：
a) 點選“Cause GC”按鈕相當於向虛擬機器請求了一次gc操作；
b) 當記憶體使用資訊第一次顯示以後，無須再不斷的點選“Cause GC”，Heap檢視介面會定時重新整理，在對應用的不斷的操作過程中就可以看到記憶體使用的變化；
c) 記憶體使用資訊的各項引數根據名稱即可知道其意思，在此不再贅述。
    如何才能知道我們的程式是否有記憶體洩漏的可能性呢？

    這裡需要注意一個值：Heap檢視中部有一個Type叫做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掉。
d) 此處已system_process程序為例，在我的測試環境中system_process程序，所佔用的記憶體的data object的Total Size，正常情況下會穩定在920.289之間之間，而當其值超過一定值後進程就會被kill。