安卓筆記俠

前言

要想做好內存優化工作，就要掌握兩大部分的知識，一部分是知道并理解內存優化相關的原理，另一部分就是善于運用內存分析的工具。本篇就來介紹內存分析工具：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文件顯示以下信息：

接著我們來分析標紅框的內容，負責分配的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));
            }
        });
    }
}

View Code

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();
    }

View Code

其中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 總覽視圖

其中總覽視圖可以查看整體的內存情況，表中的顯示信息如下所示。

結合上表和上圖，我們在總覽視圖獲得的信息就是：堆棧分配給當前的應用程序的內存大小為2.346MB，已分配的內存為1.346MB，空閑的內存為1MB，當前Heap的使用率為57.37%，對象的數量為24058個。

3.3 詳情視圖

詳細視圖展示了所有的數據類型的內存情況，表中列的信息如下所示。

除了列的信息，還有行信息：

行信息中比較重要的是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應用開發》