Traceview 是 Android 平臺特有的資料採集和分析工具

它主要用於分析 Android 中應用程 序的 hotspot（瓶頸）。Traceview 本身只是一個數據分析工具，而資料的採集則需要使用 Android SDK 中的 Debug 類或者利用 DDMS 工具。

heap 工具可以幫助我們檢查程式碼中是否存在會造成記憶體洩漏的地方。

用 heap 監測應用程序使用記憶體情況的步驟如下：

1. 啟動 eclipse 後，切換到 DDMS 透檢視，並確認 Devices 檢視、Heap 檢視都是開啟的；
2. 點選選中想要監測的程序，比如 system_process 程序；
3. 點選選中 Devices 檢視介面中最上方一排圖示中的“Update Heap”圖示；
4. 點選 Heap 檢視中的“Cause GC”按鈕；
5. 此時在 Heap 檢視中就會看到當前選中的程序的記憶體使用量的詳細情況。

說明：

• 點選“Cause GC”按鈕相當於向虛擬機器請求了一次 gc 操作；
• 當記憶體使用資訊第一次顯示以後，無須再不斷的點選“Cause GC”，Heap 檢視介面會定時重新整理，在對應用的不斷的操作過程中就可以看到記憶體使用的變化；
• 記憶體使用資訊的各項引數根據名稱即可知道其意思。

如何才能知道我們的程式是否有記憶體洩漏的可能性呢？

• 這裡需要注意一個值：Heap 檢視中部有一個 Type 叫做 data object，即資料物件，也就是我們的程式中大量存在的類型別的物件。在 data object 一行中有一列是“Total Size”，其值就是當前程序中所有 Java 資料物件的記憶體總量，一般情況下，這個值的大小決定了是否會有記憶體洩漏。可以這樣判斷：
• 不斷的操作當前應用，同時注意觀察 data object 的 Total Size 值；正常情況下 Total Size 值都會穩定在一個有限的範圍內，也就是說由於程式中的的程式碼良好，沒有造成物件不被垃圾回收的情況，所以說雖然我們不斷的操作會不斷的生成很多物件，而在虛擬機器不斷的進行 GC 的過程中，這些物件都被回收了，記憶體佔用量會會落到一個穩定的水平；
•  反之如果程式碼中存在沒有釋放物件引用的情況，則 data object 的 Total Size 值在每次 GC 後不會有明顯的回落，隨著操作次數的增多 Total Size 的值會越來越大，直到到達一個上限後導致程序被 kill 掉。
• 此處以 system_process 程序為例，在我的測試環境中 system_process 程序所佔用的記憶體的data object 的 Total Size 正常情況下會穩定在 2.2~2.8 之間，而當其值超過 3.55 後進程就會被kill。

allocation tracker 是記憶體分配跟蹤工具

步驟：

• 執行 DDMS，只需簡單的選擇應用程序並單擊 Allocation tracker 標籤，就會開啟一個新的視窗，單擊“Start Tracing”按鈕；
• 然後，讓應用執行你想分析的程式碼。執行完畢後，單擊“Get Allocations”按鈕，一個已分配物件的列表就會出現第一個表格中。
• 單擊第一個表格中的任何一項，在表格二中就會出現導致該記憶體分配的棧跟蹤資訊。通過 allocationtracker，不僅知道分配了哪類物件，還可以知道在哪個執行緒、哪個類、哪個檔案的哪一行

參考