Android性能分析工具

DDMS

DDMS 的全稱是Dalvik Debug Monitor Service，是Android 開發環境中的Dalvik 虛擬機調試監控服務

HierarchyViewer

UI性能分析工具，分析布局文件的性能，層級嵌套

UI布局復雜程度及冗余分析，View嵌套的冗余層級

View的性能指標：測量、布局、繪制的渲染時間

invalidate Layout按鈕

invalidate()，強制刷新

requestLayout按鈕

requestLayout()，重新測量，布局

使用GPU過度繪制分析UI性能

開發者選項中的GPU過度繪制工具（Show GPU Overdraw）

使用GPU呈現模式圖及FPS考核UI性能

開發者選項中的GPU呈現模式分析，Profile GPU Rendering

Android Monitor

TraceView

TraceView 簡介

Traceview 是Android 平台特有的數據采集和分析工具，它主要用於分析Android 中應用程序的hotspot（瓶頸）。Traceview 本身只是一個數據分析工具，而數據的采集則需要使用Android SDK 中的Debug 類或者利用DDMS 工具。二者的用法如下：

開發者在一些關鍵代碼段開始前調用Android SDK 中Debug 類的startMethodTracing 函數，並在關鍵代碼段結束前調用stopMethodTracing 函數。這兩個函數運行過程中將采集運行時間內該應用所有線程（注意，只能是Java線程）的函數執行情況，並將采集數據保存到/mnt/sdcard/下的一個文件中。開發者然後需要利用SDK 中的Traceview工具來分析這些數據。

借助Android SDK 中的DDMS 工具。DDMS 可采集系統中某個正在運行的進程的函數調用信息。對開發者而言，此方法適用於沒有目標應用源代碼的情況。DDMS 工具中Traceview 的使用如下圖所示。

觀察CPU的執行情況，測試的進程中每個線程運行的時間線，線程中各個方法的調用信息（CPU使用時間、調用次數等）

可以方便的查看線程的執行情況，某個方法執行時間、調用次數、在總體中的占比等，從而定位性能點

一般Traceview可以定位兩類性能問題

方法調運一次需要耗費很長時間導致卡頓 方法調運一次耗時不長，但被頻繁調運導致累計時長卡頓

點擊上圖中所示按鈕即可以采集目標進程的數據。當停止采集時，DDMS 會自動觸發Traceview 工具來浏覽采集數據<喎?/kf/ware/vc/" target="_blank" class="keylink">vcD4NCjxwPs/Cw+ajrM7Sw8fNqLn90ru49sq+wP2zzNDyvenJ3FRyYWNldmlldyC1xMq508OhozxiciAvPg0KyrXA/bPM0PLI58/CzbzL+cq+o7q958Pm09A0ILj2sLTFpaOsttTTpsvEuPa3vbeooaM8YnIgLz4NCjxpbWcgYWx0PQ=="這裡寫圖片描述" src="/uploadfile/Collfiles/20161006/201610061033051073.png" title="\" />

點擊不同的方法會進行不同的耗時操作。

public class MainActivity extends ActionBarActivity {
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
        }

        public void method1(View view) {
            int result = jisuan();
            System.out.println(result);
        }

        private int jisuan() {
            for (int i = 0; i < 10000; i++) {
                System.out.println(i);
            }
            return 1;
        }

        public void method2(View view) {
            SystemClock.sleep(2000);
        }

        public void method3(View view) {
            int sum = 0;
            for (int i = 0; i < 1000; i++) {
                sum += i;
            }
            System.out.println("sum=" + sum);
        }

        public void method4(View view) {
            Toast.makeText(this, "" + new Date(), 0).show();
        }
    }

我們分別點擊按鈕一次，要求找出最耗時的方法。點擊前通過DDMS 啟動Start Method Profiling 按鈕。

然後依次點擊4 個按鈕，都執行後再次點擊上圖中紅框中按鈕，停止收集數據。

接下來我們開始對數據進行分析。

當我們停止收集數據的時候會出現如下分析圖表。該圖表分為2 大部分，上面分不同的行，每一行代表一個線程
的執行耗時情況。main 線程對應行的的內容非常豐富，而其他線程在這段時間內干得工作則要少得多。圖表的下半部
分是具體的每個方法執行的時間情況。顯示方法執行情況的前提是先選中某個線程。

我們主要是分析main 線程。
上面方法指標參數所代表的意思如下：

列名 描述 Name 該線程運行過程中所調用的函數名 Incl Cpu Time 某函數占用的CPU 時間，包含內部調用其它函數的CPU 時間 Excl Cpu Time 某函數占用的CPU 時間，但不含內部調用其它函數所占用的CPU 時間 Incl Real Time 某函數運行的真實時間（以毫秒為單位），內含調用其它函數所占用的真實時間 Excl Real Time 某函數運行的真實時間（以毫秒為單位），不含調用其它函數所占用的真實時間 Call+Recur Calls/Total 某函數被調用次數以及遞歸調用占總調用次數的百分比 Cpu Time/Call 某函數調用CPU 時間與調用次數的比。相當於該函數平均執行時間 Real Time/Call 同CPU Time/Call 類似，只不過統計單位換成了真實時間

　
我們為了找到最耗時的操作，那麼可以通過點擊Incl Cpu Time，讓其按照時間的倒序排列。我點擊後效果如下圖：

通過分析發現：method1 最耗時，耗時2338 毫秒。

那麼有了上面的信息我們可以進入我們的method1 方法查看分析我們的代碼了

Allocation Tracker

追蹤內存的分配，追蹤內存對象的來源，通過這個工具我們可以很方便的知道代碼分配了哪類對象、在哪個線程、哪個類、哪個文件的哪一行

運行DDMS，只需簡單的選擇應用進程並單擊Allocation tracker 標簽，就會打開一個新的窗口，單擊“Start Tracing”按鈕；

然後，讓應用運行你想分析的代碼。運行完畢後，單擊“Get Allocations”按鈕，一個已分配對象的列表就會出現第一個表格中。

單擊第一個表格中的任何一項，在表格二中就會出現導致該內存分配的棧跟蹤信息。通過allocation tracker，不僅知道分配了哪類對象，還可以知道在哪個線程、哪個類、哪個文件的哪一行。

Systrace

Systrace其實有些類似Traceview，它是對整個系統進行分析

DDMS->Capture system wide trace using Android systrace

Heap

內存監測工具，分析內存使用情況，查看當前內存快照，便於對比分析哪些對象有可能是洩漏了的

heap 工具可以幫助我們檢查代碼中是否存在會造成內存洩漏的地方。用heap 監測應用進程使用內存情況的步驟如下：

啟動eclipse 後，切換到DDMS 透視圖，並確認Devices 視圖、Heap 視圖都是打開的

點擊選中想要監測的進程，比如system_process 進程；

點擊選中Devices 視圖界面中最上方一排圖標中的“Update Heap”圖標；

點擊Heap 視圖中的“Cause GC”按鈕；

此時在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

總之，使用DDMS 的Heap 視圖工具可以很方便的確認我們的程序是否存在內存洩漏的可能性

Leakcanary

Square出品，內存洩露監測神器

Eclipse Memory Analyzer（MAT）

內存分析工具，這個工具分為Eclipse插件版和獨立版兩種，如果你是使用Eclipse開發的，那麼可以使用插件版MAT，非常方便。如果你是使用Android Studio開發的，那麼就只能使用獨立版的MAT了

HPROF文件

HPROF文件是MAT能識別的文件，HPROF文件存儲的是特定時間點，java進程的內存快照

點擊Dump HPROF file按鈕，生成HPROF文件，這個文件記錄著我們應用程序內部的所有數據。但是目前MAT還是無法打開這個文件的，我們還需要將這個HPROF文件從Dalvik格式轉換成J2SE格式，使用hprof-conv命令就可以完成轉換工作

hprof-conv dump.hprof converted-dump.hprof 

Histogram

Histogram：列出內存中每個對象的名字、數量以及大小
Shallow Heap：當前對象自己所占內存的大小，不包含引用關系的

析大內存的對象，分析對象的數量

Dominator Tree

Dominator Tree：列出最大的對象以及其依賴存活的Object，並且我們可以分析對象之間的引用結構
Retained Heap表示這個對象以及它所持有的其它引用（包括直接和間接）所占的總內存

在每一行的最左邊都有一個文件型的圖標，這些圖標有的左下角帶有一個紅色的點，有的則沒有。帶有紅點的對象就表示是可以被GC Roots訪問到的，可以被GC Root訪問到的對象都是無法被回收的。帶紅點的對象最右邊都有寫一個System Class，說明這是一個由系統管理的對象，並不是由我們自己創建並導致內存洩漏的對象

搜索大內存對象通向GC Roots的路徑，因為內存占用越高的對象越值得懷疑

GC Roots reference chain(引用鏈)的起點,是一個在current thread(當前線程)的call stack(調用棧)上的對象（例如方法參數和局部變量），或者是線程自身或者是system class loader(系統類加載器)加載的類以及native code(本地代碼)保留的活動對象。所以GC Roots是分析對象為何還存活於內存中的利器。

dumpsys meminfo命令

adb shell dumpsys meminfo  [-d]

adb shell dumpsys batterystats 電量狀態

Lint工具

使用Lint進行資源及冗余UI布局等優化，Lint 有自動修復、提示建議和直接跳轉到問題處的功能

集成到androidstudio，點擊工具欄的Analysis -> Inspect Code
內存抖動：短時間內有大量頻繁的對象創建與釋放操作

Lint是Android提供的一個靜態掃描應用源碼並找出其中的潛在問題的一個強大的工具

運行Lint：點擊工具欄的Analysis -> Inspect Code

ProGuard

混淆代碼，壓縮和優化代碼，apk瘦身

GC打印