性能分析工具 Android TraceView

TraceView 簡介

Traceview是android平台配備一個很好的性能分析的工具。它可以通過圖形化的方式讓我們了解我們要跟蹤的程序的性能，並且能具體到每個方法的執行時間

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

Debug

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

DDMS

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

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

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

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

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

DDMS 工具中Traceview 的使用如下圖所示。

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

Traceview的作用

查看跟蹤代碼的執行時間，分析哪些是耗時操作 ；可以用於跟蹤方法的調用，尤其是Android Framework層的方法調用關系

如何使用TraceView

使用TraceView主要有兩種方式：

最簡單的方式就是直接打開DDMS，選擇一個進程，然後按上面的“Start Method Profiling”按鈕，等紅色小點變成黑色以後就表示TraceView已經開始工作了。然後我就可以滑動一下列表（現在手機上的操作肯定會很卡，因為Android系統在檢測Dalvik虛擬機中每個Java方法的調用，這是我猜測的）。操作最好不要超過5s，因為最好是進行小范圍的性能測試。然後再按一下剛才按的按鈕，等一會就會出現下面的圖片，然後就可以開始分析了。

第2種方式就是使用android.os.Debug.startMethodTracing()和android.os.Debug.stopMethodTracing()方法，當運行了這段代碼的時候，就會有一個trace文件在/sdcard目錄中生成，也可以調用startMethodTracing(String traceName) 設置trace文件的文件名，最後你可以使用adb pull /sdcard/test.trace /tmp 命令將trace文件復制到你的電腦中，然後用DDMS工具打開就會出現下面那副圖片了

Debug

1、選擇追蹤范圍加入記錄代碼

首先，必須在程序當中加入代碼，以便生成trace文件，有了這個trace文件才可以將其轉化為圖形。

要添加的代碼如下：

Debug.startMethodTracing("wirelessqa")；//開始
Debug.stopMethodTracing()；//結束

其中參數wirelessqa是要創建的trace文件的名稱，wirelessqa.trace。默認路徑是/sdcard/wirelessqa.trace，也可以自己制定/data/log/wirelessqa，表示文件在/data/log/wirelessqa.trace。

2、實例代碼參考

publicclass MainActivity extends Activity {
    @Override
    protectedvoid onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        setTitle(this.getClass().getName());
        View toLoginView = findViewById(R.id.to_login);
        // 開始記錄 sdcard/wirelessqa.trace文件
        Debug.startMethodTracing("wirelessqa");
        toLoginView.setOnClickListener(new View.OnClickListener() {
            publicvoid onClick(View view) {
                Intent intent = new Intent(getApplicationContext(), LoginActivity.class);
                startActivity(intent);
            }
        });
    }
    @Override
    protectedvoid onStop() {
        super.onStop();
        Debug.stopMethodTracing();// 結束記錄wirelessqa.trace
    }
}

說明：

開發文檔中說可以在activity的onCreate()中添加Debug.startMethodTracing(), 而在onDestroy()中添加Debug.stopMethodTracing()，但是在實際的測試時發現這種方式其實並不好用，因為通常情況下我們的activity的onDestroy()是由系統決定何時調用的，因此可能等了很長時間都不會得到這個trace文件。

因此決定在onStop()中來調用Debug.stopMethodTracing()。這樣當我們切換到其它activity或者點擊home鍵的時候onStop()就會被調用，我們也就可以得到完整的trace file

3、別忘了加入訪問SD卡的權限

4、利用tools下的工具trace view打開.trace文件

第一種方式相對來說是一種簡單，但是測試的范圍很寬泛，第二中方式相對來說精確一點，不過我個人喜歡使用第一種，因為簡單，而且它是檢測你的某一個操作。因為第二中更適合檢測某一個方法的性能，其實也沒有那種好，看使用的場景和個人的喜好

效果圖：

看懂TraceView中的指標

下面我們具體分析一下這張圖(與上圖數據上有點區別)：

縱軸

TraceView界面下方表格中縱軸就是每個方法，包括了JDK的，Android SDK的，也有native方法的，當然最重要的就是app中你自己寫的方法，有些Android系統的方法執行時間很長，那麼有很大的可能就是你app中調用這些方法過多導致的

每個方法前面都有一個數字，可能是全部方法按照Incl CPU Time 時間的排序序號（後面會講到）

點一個方法後可以看到有兩部分，一個是Parents，另一個是Children。
Parent表示調用這個方法的方法，可以叫做父方法，Children表示這個方法中調用的其他方法，可以叫做子方法

橫軸

Incl Cpu Time

define inclusive ： 全包括的
上圖中可以看到（toplevel） 的Incl Cpu Time 占了100%的時間，這個不是說100%的時間都是它在執行，請看下面代碼：

public void top() { 
    a(); 
    b(); 
    c(); 
    d(); 
} 

Incl Cpu Time表示方法top執行的總時間，假如說方法top的執行時間為10ms，方法a執行了1ms，方法b執行了2ms，方法c執行了3ms，方法d執行了4ms（這裡是為了舉個例子，實際情況中方法a、b、c、d的執行總時間肯定比方法top的執行總時間要小一點）

而且調用方法top的方法的執行時間是100ms，那麼：

//Incl Cpu Time
top 10% 
a 10% 
b 20% 
c 30% 
d 40% 

從上面圖中可以看到：
toplevel的 Incl Cpu Time 是1110.943，而io.bxbxbai.android.examples.activity.ExpandableLayoutMainActivity$SimpleAdapter.getItemView方法的Incl Cpu Time為12.859，說明後者的Incl Cpu Time % 約為1.2%，這個指標表示 這個方法以及這個方法的子方法（比如top方法中的a、b、c、d方法）一共執行的時間

Excl Cpu Time

理解了Incl Cpu Time以後就可以很好理解Excl Cpu Time了，還是上面top方法的例子：

方法top 的 Incl Cpu Time 減去 方法a、b、c、d的Incl Cpu Time 的時間就是方法top的Excl Cpu Time 了

Incl Real Time

這個感覺和Incl Cpu Time 差不多，第7條會講到。

Excl Real Time

同上

Calls + Recur Calls / Total

這個指標非常重要！它表示這個方法執行的次數，這個指標中有兩個值，一個Call表示這個方法調用的次數，Recur Call表示遞歸調用次數，看下圖：

我選中了一個方法，可以看到這個方法的Calls + Recur Calls 值是14 + 0，表示這個方法調用了14次，但是沒有遞歸調用
從Children這一塊來看，很多方法調用都是13的倍數，說明父方法中有一個判斷，但是這不是重點，有些Child方法調用Calls為26，這說明了這些方法被調用了兩遍，是不是可能存在重復調用的情況？這些都是可能可以優化性能的地方。

Cpu Time / Call

cpu time，這個指標應該說是最重要的，從上圖可以看到，133這個方法的調用次數為20次，而它的Incl Cpu Time為12.859ms，那麼133方法每一次執行的時間是0.643ms（133這個方法是SimpleAdapter的getItemView方法）

對於一個adapter的getView方法來說0.643ms是非常快的（因為這個adapter中只有一個TextView，我為了測試用的）

如果getView方法執行時間很長，那麼必然導致列表滑動的時候產生卡頓現象，可以在getView方法的Children方法列表中找到耗時最長的方法，分析出現問題的原因：

是因為有過多的計算？ 還是因為有讀取SD卡的操作？ 還是因為adapter中View太復雜了？ 還是因為需要有很多判斷，設置View的顯示還是隱藏 還是因為其他原因…

Real Time / Call

Real Time 和 Cpu Time 我現在還不太明白它們的區別，我的理解應該是:

Cpu Time 應該是某個方法占用CPU的時間 Real Time 應該是這個方法的實際運行時間

為什麼它們會有區別呢？可能是因為CPU的上下文切換、阻塞、GC等原因方法的實際執行時間要比Cpu Time 要稍微長一點

總結

TraceView是一個非常強大的性能分析工具，因為Android 官網對這個工具的使用介紹文檔很少，而且一些中文博客中寫的也都是抄來抄去，沒有講到底怎麼使用

最近我在做這方面的性能分析，就慢慢琢磨了這麼工具的使用，發現非常強大，寫下來總結一下

Android的性能分析工具還有很多，比如：
Eclipse Memory Analyzer Tool 來分析Android app的內存使用
Dump UI Hierarchy for UI Atomator，分析UI層級
systrace

其他

下圖這一條工具欄中有很多性能分析工具

Traceview 的使用

下面，我們通過一個示例程序介紹Traceview 的使用。

實例程序如下圖所示：界面有4 個按鈕，對應四個方法。

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

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 方法查看分析我們的代碼了

生成.trace文件

android.os.Debug類，其中重要的兩個方法

Debug.startMethodTracing();
Debug.stopMethodTracing();

這兩個方法用來創建.trace文件，將從Debug.startMethodTracing()開始，到Debug.stopMethodTracing()結束，期間所有的調用過程保存在.trace文件中，包括調用的函數名稱和執行的時間等信息。

dmtracedump

dmtracedump -g result.png target.trace  //結果png文件  目標trace文件