Android 內存監測工具 DDMS --> Heap

用 Heap監測應用進程使用內存狀況的步驟以下：
1. 啓動eclipse後，切換到DDMS透視圖，並確認Devices視圖、Heap視圖都是打開的；
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正常狀況下會穩定在2.2~2.8之間，而當其值超過3.55後進程就會被kill。

來自： http://apps.hi.baidu.com/share/detail/32190286

在DDMS裏檢查heap的使用狀況

Dalvik Debug Monitor Server（DDMS）是主要的Android調試工具之一，也是ADT Eclipse plug-in 的一部分，獨立的程序版本也能夠在Android SDK的根目錄下的tools/下面找到。關於DDMS更多的信息，請參考使用DDMS 。

咱們來使用DDMS檢查這個應用的heap使用狀況。你可使用下面的兩種方法啓動DDMS：

• from Eclipse: click Window > Open Perspective > Other... > DDMS
• or from the command line: run ddms (or ./ddms on Mac/Linux) in the tools/ directory

在左邊的面板選擇進程com.example.android.hcgallery，而後在 工具條上邊點擊Show heap updates按鈕。這個時候切換到DDMS的VM Heap分頁。它會顯示每次gc後heap內存的一些基本數據。要看第一次gc後的數據內容，點擊Cause GC按鈕：

咱們能夠看到如今的值（Allocated列）是有一些超過8MB。如今滑動相片，這時看到 數據在增大。由於只有僅僅13個相片在程序裏邊，因此泄露的內存只有這麼大。在某種程度上來講，這時最壞的一種內存泄露，由於咱們無法獲得 OutOfMemoryError來提醒咱們說如今內存溢出了。

生成heap dump

咱們如今使用heap dump來追蹤這個問題。點擊DDMS工具條上面的Dump HPROF文件按鈕，選擇文件存儲位置，而後在運行hprof-conv。在這個例子裏咱們使用獨立的MAT版本（版本1.0.1），從MAT站點下載 。

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

用MAT分析heap dumps

啓動MAT而後加載剛纔咱們生成的HPROF文件。MAT是一個強大的工具，講述它全部的特性超出了本文的範圍，因此我只想演示一種你能夠用來檢測 泄露的方法：直方圖（Histogram）視圖。它顯示了一個能夠排序的類實例的列表，內容包括：shallow heap（全部實例的內存使用總和），或者retained heap（全部類實例被分配的內存總和，裏面也包括他們全部引用的對象）。

若是咱們按照shallow heap排序，咱們能夠看到byte[]實例在頂端。自從Android3.0（Honeycomb），Bitmap的像素數據被存儲在byte數組裏 （以前是被存儲在Dalvik的heap裏），因此基於這個對象的大小來判斷，不用說它必定是咱們泄露掉的bitmap。

右擊byte[]類而後選擇List Objects > with incoming references。它會生成一個heap上的全部byte數組的列表，在列表裏，咱們能夠按照Shallow Heap的使用狀況來排序。

選擇並展開一個比較大的對象，它將展現從根到這個對象的路徑--就是一條保證對象有效的鏈條。注意看，這個就是咱們的bitmap緩存！

MAT不會明確告訴咱們這就是泄露，由於它也不知道這個東西是否是程序還須要的，只有程序員知道。在這個案例裏面，緩存使用的大量的內存會影響到後面的應用程序，因此咱們能夠考慮限制緩存的大小。

使用MAT比較heap dumps

調試內存泄露時，有時候適時比較2個地方的heap狀態是頗有用的。這時你就須要生成2個單獨的HPROF文件（不要忘了轉換格式）。下面是一些關於如何在MAT裏比較2個heap dumps的內容（有一點複雜）：

1. 第一個HPROF 文件(using File > Open Heap Dump ).
2. 打開 Histogram view.
3. 在Navigation History view裏 (若是看不到就從Window > Navigation History找 ), 右擊histogram 而後選擇Add to Compare Basket .
4. 打開第二個HPROF 文件而後重作步驟2和3.
5. 切換到Compare Basket view, 而後點擊Compare the Results (視圖右上角的紅色"!"圖標)。

總結

這本篇文章裏面，我展現了Allocation Tracker和heap dumps是如何給你一種對程序內存使用的感性認識。我也展現了Eclipse Memory Analyzer（MAT)能夠幫助追逐咱們程序裏面的內存泄露問題。MAT是一個強大的工具，我也僅僅觸碰了一些皮毛，若是你想學習更多內容，我建議讀 一些下面的文章：

• Memory Analyzer News : Eclipse MAT project的官方博客。
• Markus Kohler的Java Performance blog有不少有用的文章, 包括 Analysing the Memory Usage of Android Applications with the Eclipse Memory Analyzer and 10 Useful Tips for the Eclipse Memory Analyzer .

來自： http://dev.10086.cn/blog/?uid-13136-action-viewspace-itemid-9580