Android TraceView 最權威的性能分析工具

TraceView是什麼

Traceview是android平臺配備一個很好的性能分析的工具。它可以通過圖形化的方式讓我們瞭解我們要跟蹤的程序的性能，並且能具體到method。

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工具打開就會出現下面那副圖片了.
第2種方式舉例：

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卡的權限

<uses-permissionandroid:name="android.permission.MOUNT_UNMOUNT_FILESYSTEMS"/>   
<uses-permissionandroid:name="android.permission.WRITE_EXTERNAL_STORAGE"/>  

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
其他

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

文章參考：https://bxbxbai.github.io/2014/10/25/use-trace-view/
和http://blog.csdn.net/wirelessqa/article/details/8764622