Android教程網 >> Android技術 >> Android資訊 >> 正確使用Android性能分析工具——TraceView

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

編輯：Android資訊

前面唠叨

最近公司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調用的其他方法，可以看到有好幾個方法。

main

如何使用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工具打開就會出現第一幅圖了

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

看懂TraceView中的指標

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

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

縱軸

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

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

點一個方法後可以看到有兩部分，一個是Parents，另一個是Children。

Parent表示調用這個方法的方法，可以叫做父方法
Children表示這個方法中調用的其他方法，可以叫做子方法

橫軸

incl time

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

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

1. Incl Cpu Time

define inclusive ：全包括的

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