前言
要想做好內存優化工作，就要掌握兩大部分的知識，一部分是知道並理解內存優化相關的原理，另一部分就是善於運用內存分析的工具。本篇就來介紹內存分析工具：Memory Monitor、Allocation Tracker和Heap Dump的使用方法。
1.Memory Monitor
在Android Studio(以下簡稱AS)中Android Monitor是一個主窗口，它包含了Logcat,、Memory Monitor、CPU Monitor、 GPU Monitor和Network Monitor。其中Memory Monitor可以輕松地監視應用程序的性能和內存使用情況，以便於找到被分配的對象，定位內存泄漏，並跟蹤連接設備中正在使用的內存數量。Memory Monitor可以報告出你的應用程序的內存分配情況， 更形象的呈現出應用程序使用的內存。它的作用如下：
- 實時顯示可用的和分配的Java內存的圖表。
- 實時顯示垃圾收集(GC)事件。
- 啟動垃圾收集事件。
- 快速測試應用程序的緩慢是否與過度的垃圾收集事件有關。
- 快速測試應用程序崩潰是否與內存耗盡有關。
1.1 使用Memory Monitor
在使用Memory Monitor之前要確保手機開啟了開發者模式和USB調試。
使用的步驟為：
1.運行需要監控的應用程序。
2.點擊AS面板下面的Android圖標，並選擇Monitors選項。
如果Memory Monitor已經運行，效果如下圖所示（AS版本2.3.2）。
QQ截圖20170705223544.png
圖中的標注的功能如下：
- Initiate GC(標識1)：用來手動觸發GC。
- Dump Java heap(標識2)：保存內存快照。
- Start/Stop Allocation Tracking(標識3)：打開Allocation Tracker工具（后面會介紹）。
- Free(標識4)：當前應用未分配的內存大小。
- Allocated(標識5)：當前應用分配的內存大小。
圖中y軸顯示當前應用的分配的內存和未分配的內存大小；x軸表示經過的時間。
1.2 大內存申請與GC
am-gc2.png
從上圖可以看出，分配的內存急劇上升，這就是大內存分配的場景，我們要判斷這是否是合理的分配的內存，是Bitmap還是其他的大數據，並且對這種大數據進行優化，減少內存開銷。
接下來分配的內存出現急劇下降，這表示垃圾收集事件，用來釋放內存。
1.3 內存抖動
20150924173526554 (1)_副本.jpg
內存抖動一般指在很短的時間內發生了多次內存分配和釋放，嚴重的內存抖動還會導致應用程序卡頓。內存抖動出現原因主要是短時間頻繁的創建對象（可能在循環中創建對象），內存為了應對這種情況，也會頻繁的進行GC。非並行GC在進行時，其他線程都會被掛起，等待GC操作完成后恢復工作。如果是頻繁的GC就會產生大量的暫停時間，這會導致界面繪制時間減少，從而使得多次繪制一幀的時長超過了16ms，產生的現象就是界面卡頓。綜合起來就產生了內存抖動，產生了如上圖般的鋸齒狀。
2.Allocation Tracker
Allocation Tracker用來跟蹤內存分配，它允許你在執行某些操作的同時監視在何處分配對象，了解這些分配使你能夠調整與這些操作相關的方法調用，以優化應用程序性能和內存使用。
Allocation Tracker能夠做到如下的事情：
- 顯示代碼分配對象類型、大小、分配線程和堆棧跟蹤的時間和位置。
- 通過重復的分配/釋放模式幫助識別內存變化。
- 當與 HPROF Viewer結合使用時，可以幫助你跟蹤內存泄漏。例如，如果你在堆上看到一個bitmap對象，你可以使用Allocation Tracker來找到其分配的位置。
2.1 使用Allocation Tracker
AS和DDMS中都有Allocation Tracker，這里會·介紹AS中的Allocation Tracke如何使用。首先要確保要確保手機開啟了開發者模式，並且開啟了USB調試。
使用的步驟為：
1.運行需要監控的應用程序。
2.點擊AS面板下面的Android圖標，並選擇Monitors選項。
3.點擊Start Allocation Tracking按鈕，這時Start Allocation Tracking按鈕變為了Stop Allocation Tracking按鈕。
4.操作應用程序。
5.點擊Stop Allocation Tracking按鈕，結束快照。這時Memory Monitor會顯示出捕獲快照的期間，如下圖所示。
QQ截圖20170708172907.png
6.過幾秒后就會自動打開一個窗口，顯示當前生成的alloc文件的內存數據。
2.2 alloc文件分析
自動打開的alloc文件窗口如下圖所示。
QQ截圖20170708174544.png
該alloc文件顯示以下信息：
| 列 | 說明 |
|---|---|
| Method | 負責分配的Java方法 |
| Count | 分配的實例總數 |
| Total Size | 分配內存的總字節數 |
接着我們來分析標紅框的內容，負責分配的Java方法為performLaunchActivity，內存分配序列為2369，分配的對象為ActivityThread，分配的實例總數為300個，分配內存的總字節數為10512。不了解performLaunchActivity方法和ActivityThread可以看Android深入四大組件這一系列的文章。
目前的菜單選項是Group by Method我們也可以選擇 Group By Allocator，如下圖所示。
QQ截圖20170708192205.png
為了更好的解釋圖中的信息，這里給出測試的代碼，MainActivity和SecondActivity 的代碼如下所示。
MainActivity.java
public class MainActivity extends AppCompatActivity { private Button button; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); button =(Button)findViewById(R.id.bt_next); button.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { startActivity(new Intent(MainActivity.this,SecondActivity.class)); } }); } }
SecondActivity.java
public class SecondActivity extends AppCompatActivity { private static Object inner; private Button button; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); button = (Button) findViewById(R.id.bt_next); button.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { createInnerClass(); finish(); } }); } void createInnerClass() { class InnerClass { } inner = new InnerClass(); }
其中SecondActivity是存在內存泄漏的，生成快照期間，我的操作就是在MainActivity和SecondActivity跳轉了3次（點擊button 共6次）。這時我們回過頭來看上圖的紅框的信息，MainActivity總共分配了3個Intent實例，占用內存為192字節。SecondActivity總共分配了6個實例，占用內存為96字節，其中分配了3個匿名內部類OnClickListener的實例，3個InnerClass的實例。
我們可以選擇列表中的一項，單擊鼠標右鍵，在彈出的菜單中選擇jump to the source就可以跳轉到對應的源文件中。
除此之外，還可以點擊Show/Hide Chart按鈕來顯示數據的圖形化，如下圖所示。
3.Heap Dump
Heap Dump的主要功能就是查看不同的數據類型在內存中的使用情況。它可以幫助你找到大對象，也可以通過數據的變化發現內存泄漏。
3.1 使用Heap Dump
打開Android Device Monitor工具，在左邊Devices列表中選擇要查看的應用程序進程，點擊Update Heap按鈕(裝有一半綠色液體的圓柱體），在右邊選擇Heap選項，並點擊Cause GC按鈕，就會開始顯示數據。我們每次點擊Cause GC按鈕都會強制應用程序進行垃圾回收，並將清理后的數據顯示在Heap工具中。如下圖所示。
從上圖可以看出，Heap工具共有三個區域，分別是總覽視圖(標識1)、詳情視圖(標識2)和內存分配柱狀圖(標識2)。
3.2 總覽視圖
其中總覽視圖可以查看整體的內存情況，表中的顯示信息如下所示。
| 列 | 說明 |
|---|---|
| Heap Size | 堆棧分配給該應用程序的內存大小 |
| Allocated | 已分配使用的內存大小 |
| Free | 空閑的內存大小 |
| %Used | 當前Heap的使用率（Allocated/Heap Size） |
| #Objects | 對象的數量 |
結合上表和上圖，我們在總覽視圖獲得的信息就是：堆棧分配給當前的應用程序的內存大小為2.346MB，已分配的內存為1.346MB，空閑的內存為1MB，當前Heap的使用率為57.37%，對象的數量為24058個。
3.3 詳情視圖
詳細視圖展示了所有的數據類型的內存情況，表中列的信息如下所示。
| 列 | 說明 |
|---|---|
| Type | 數據類型 |
| Total Size | 總共占用的內存大小 |
| Smallest | 將該數據類型的對象從小到大排列，排在第一個的對象所占用的內存 |
| Largest | 將該數據類型的對象從小到大排列，排在最后一個的對象所占用的內存 |
| Median | 將該數據類型的對象從小到大排列，排在中間的對象所占用的內存 |
| Average | 該數據類型的對象所占用內存的平均值 |
除了列的信息，還有行信息：
| 行 | 說明 |
|---|---|
| free | 內存碎片 |
| data object | 對象 |
| class object | 類 |
| 1-byte array (byte[],boolean[]) | 1字節的數組對象 |
| 2-byte array (short[],char[]) | 2字節的數組對象 |
| 4-byte array (object[],int[],float[]) | 4字節的數組對象 |
| 6-byte array (long[],double[]) | 8字節的數組對象 |
| non-Java object | 非Java對象 |
行信息中比較重要的是free，它與總覽視圖中的free的含義不同，它代表內存碎片。當新創建一個對象時，如果碎片內存能容下該對象，則復用碎片內存，否則就會從free空間（總覽視圖中的free）重新划分內存給這個新對象。free是判斷內存碎片化程度的一個重要的指標。
此外，1-byte array這一行的信息也很重要，因為圖片是以byte[]的形式存儲在內存中的，如果1-byte array一行的數據過大，則需要檢查圖片的內存管理了。
3.4 檢測內存泄漏
Heap Dump也可以檢測內存泄漏。在左邊Devices列表中選擇要查看的應用程序進程，點擊Update Heap按鈕(裝有一半綠色液體的圓柱體），在右邊選擇Heap選項，並點擊Cause GC按鈕，就會開始顯示數據，如下圖所示。
這時data object的Total Size為270.266KB。接下來操作應用，這個應用仍舊是在2.2小節所舉的內存泄漏的例子，我反復的在MainActivity和SecondActivity跳轉了10次（點擊Button共20次），數據顯示為：
data object的Total Size變為了768.172KB。這時我點擊Cause GC按鈕，數據顯示為：
可以看到data object的Total Size變為了444.516KB，再點擊一次Cause GC按鈕：
Total Size變為了323.312KB，經過兩次Cause GC的操作，Total Size的值從768.172KB變為了323.312KB，這是一個比較大的變化，說明在Cause GC操作之前有462.86KB(768.172KB-323.312KB)的內存沒有被回收，可能發生了內存泄漏。
參考資料
Memory Monitor
Allocation Tracker
Android Monitor Basics
Android性能專項測試之Memory Monitor工具
《Android應用性能優化最佳實踐》
《Android群英傳 神兵利器》
《高性能Android應用開發》