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

標籤：code   logs   mat   使用   檢測   上下   main   而且   崩潰   

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%的時間都是它在執行，請看下面代碼：

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

ncl Cpu Time表示方法top執行的總時間，假如說方法top的執行時間為10ms，方法a執行了1ms，方法b執行了2ms，方法c執行了3ms，方法d執行了4ms（這裡是為了舉個栗子，實際情況中方法a、b、c、d的執行總時間肯定比方法top的執行總時間要小一點）。
而且調用方法top的方法的執行時間是100ms，那麼：

從上面圖中可以看到：
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方法）一共執行的時間

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

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

3. Excl Real Time
   同上

4. Calls + Recur Calls / Total
   這個指標非常重要！

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

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

1. 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的顯示還是隱藏
• 還是因為其他原因…
  

1. Real Time / CallReal Time 和 Cpu Time 我現在還不太明白它們的區別，我的理解應該是:
2. Cpu Time 應該是某個方法佔用CPU的時間
3. Real Time 應該是這個方法的實際已耗用時間
   

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

總結

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

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

Android的效能分析工具還有很多，比如：

• Eclipse Memory Analyzer Tool 來分析Android app的記憶體使用量
• Dump UI Hierarchy for UI Atomator，分析UI層級
• systrace
• 其他
  

這一條工具列中有很多效能分析工具~~~

MQC測試平台是為廣大企業客戶和移動開發人員提供真機測試服務的雲平台，擁有大量熱門機型，提供7x24全天候服務。

我們致力於提供專業、穩定、全面、高價值的自動化測試能力，以及簡單易用的使用流程、貼心的技術服務，並且協助客戶以最低的成本、最高的效率發現APP中的各類隱患（APP崩潰、各類相容性問題、功能性問題、效能問題等），減少使用者流失，提高APP品質和市場競爭力。

 

著作權聲明：此文章轉載自http://bxbxbai.github.io/2014/10/25/use-trace-view/

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