正確使用Android性能分析工具——TraceView

前面嘮叨

最近公司app中有些列表在滑動的時候會有卡頓現象，我就開始着手解決這些問題，解決問題以前首先要分析列表滑動的性能瓶頸在什麼地方。由於以前不會正確使用TraceView這個工具，主要是看不懂TraceView界面下方數據指標的值表明什麼意思…之前我用StopWatch類來分析性能，如今以爲弱爆了…不過有些地方StopWatch工具類仍是很簡單好用的~

網上能夠找了不少博客來介紹這個工具的使用方法，不少都是講解了一些一些就會的方法，講一個大概，包括StackOverFlow上我也沒有找到很好的講解TraceView各個數據指標代碼什麼意思的回答

由於我要解決列表滑動的卡頓問題，就必需要找到致使卡頓現象的緣由，我就在StackOverFlow上找着別人零散的回答慢慢琢磨這個工具的使用方法。如今我學會了，至少能看懂每一個指標什麼意思，最後發現這個工具實在太強大了！！！

TraceView界面

現來看一下整個界面的圖，整個界面包括上下兩部分，上面是你測試的進程中每一個線程的執行狀況，每一個線程佔一行；下面是每一個方法執行的各個指標的值

上面一部分是你測試進程的中每一個線程運行的時間線，下圖中能夠能夠看到，主要只有一個main線程在執行，由於我滑動了一下列表，main線程（UI線程）正在進行繪製View呢~

而後我點擊了序號爲133的一個方法io.bxbxbai.android.examples.activity.ExpandableLayoutMainActivity$SimpleAdapter.getItemView，就會出現兩部分數據：

• Parents
• Children

Parents表示調用133這個方法的父方法，能夠看到序號爲130。Children表示方法133調用的其餘方法，能夠看到有好幾個方法。

如何使用TraceView

由於此次我主要是分析列表滑動卡頓問題，我就講講我是怎麼使用這個工具的，而且我是怎麼分析的。

使用TraceView主要有兩種方式：

1. 最簡單的方式就是直接打開DDMS，選擇一個進程，而後按上面的「Start Method Profiling」按鈕，等紅色小點變成黑色之後就表示TraceView已經開始工做了。而後我就能夠滑動一下列表（如今手機上的操做確定會很卡，由於Android系統在檢測Dalvik虛擬機中每一個Java方法的調用，這是我猜想的）。操做最好不要超過5s，由於最好是進行小範圍的性能測試。而後再按一下剛纔按的按鈕，等一會就會出現上面這幅圖，而後就能夠開始分析了。
2. 第2種方式就是使用android.os.Debug.startMethodTracing();和android.os.Debug.stopMethodTracing();方法，當運行了這段代碼的時候，就會有一個trace文件在/sdcard目錄中生成，也能夠調用startMethodTracing(String traceName) 設置trace文件的文件名，最後你可使用adb pull /sdcard/test.trace /tmp 命令將trace文件複製到你的電腦中，而後用DDMS工具打開就會出現第一幅圖了

第一種方式相對來講是一種簡單，可是測試的範圍很寬泛，第二中方式相對來講精確一點，不過我我的喜歡使用第一種，由於簡單，並且它是檢測你的某一個操做。由於第二中更適合檢測某一個方法的性能，其實也沒有那種好，看使用的場景和喜愛了。。。

看懂TraceView中的指標

其實我今年7月份就已經開始使用TraceView工具了，可是當時不懂其中每一個指標的含義，就沒注意到它強大的地方。看不懂界面下方表格中的指標，這些數據其實一點意義都沒有。

網上包括Android官網也沒有對TraceView工具的使用有詳細的說明文檔，這點確實比較蛋疼。

縱軸

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

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

點一個方法後能夠看到有兩部分，一個是Parents，另外一個是Children。

• Parent表示調用這個方法的方法，能夠叫作父方法
• Children表示這個方法中調用的其餘方法，能夠叫作子方法

橫軸

橫軸上是不少指標，這些指標表示什麼意思真的困擾了我很長一段時間。。。

可以很衡量一個方法性能的指標應該只有時間了吧？ 一個方法確定就是執行時間越短約好咯~~

1. Incl Cpu Time

define inclusive ： 全包括的

上圖中能夠看到0（toplevel） 的Incl Cpu Time 佔了100%的時間，這個不是說100%的時間都是它在執行，請看下面代碼：

1

2

3

4

5

6

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方法）一共執行的時間

2. 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 了

3. Incl Real Time

這個感受和Incl Cpu Time 差很少，第7條會講到。

4. Excl Real Time

同上

5. Calls + Recur Calls / Total

這個指標很是重要！

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

我選中了一個方法，能夠看到這個方法的Calls + Recur Calls 值是14 + 0，表示這個方法調用了14次，可是沒有遞歸調用

從Children這一塊來看，不少方法調用都是13的倍數，說明父方法中有一個判斷，可是這不是重點，有些Child方法調用Calls爲26，這說明了這些方法被調用了兩遍，是否是可能存在重複調用的狀況？這些都是可能能夠優化性能的地方。

6. Cpu Time / Call

重點來了！！！！！！！！！！

這個指標應該說是最重要的，從上圖能夠看到，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的顯示仍是隱藏
• 仍是由於其餘緣由…

7. 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
• 其餘

下圖這一條工具欄中有不少性能分析工具~~~

29