卡頓檢測工具TraceView之分析每個方法的執行時間
TraceView介面
現來看一下整個介面的圖,整個介面包括上下兩部分,上面是你測試的程序中每個執行緒的執行情況,每個執行緒佔一行;下面是每個方法執行的各個指標的值
上面一部分是你測試程序的中每個執行緒執行的時間線,下圖中可以可以看到,主要只有一個main執行緒在執行,因為我滑動了一下列表,main執行緒(UI執行緒)正在進行繪製View呢~
然後我點選了序號為133的一個方法io.bxbxbai.android.examples.activity.ExpandableLayoutMainActivity$SimpleAdapter.getItemView
,就會出現兩部分資料:
- Parents
- Children
Parents表示呼叫133這個方法的父方法,可以看到序號為130。Children表示方法133呼叫的其他方法,可以看到有好幾個方法。
如何使用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表示這個方法中呼叫的其他方法,可以叫做子方法
橫軸
橫軸上是很多指標,這些指標表示什麼意思真的困擾了我很長一段時間。。。
能夠很衡量一個方法效能的指標應該只有時間了吧? 一個方法肯定就是執行時間越短約好咯~~
1. Incl Cpu Time
define inclusive : 全包括的
上圖中可以看到0(toplevel)
的Incl Cpu Time 佔了100%的時間,這個不是說100%的時間都是它在執行,請看下面程式碼:
1 2 3 4 5 6 | publicvoidtop(){ 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
- 其他