1、DDMS與traceView的區別
DDMS是一個集調試、瀏覽、控制等操作爲一體的工具箱,而traceView只是一個性能調優工具,可通過它查看程序中方法的執行效率等指標。
2、traceView的使用
traceView的開啓有兩種方式
①最簡單的方式就是直接打開DDMS,選擇一個進程,然後按上面的“Start Method Profiling”按鈕,等紅色小點變成黑色以後就表示TraceView已經開始工作了。然後進行手機操作,操作最好不要超過5s,因爲最好是進行小範圍的性能測試。然後再按一下剛纔按的按鈕,等一會就會出現上面這幅圖,然後就可以開始分析了。
②第2種方式就是使用android.os.Debug.startMethodTracing();
和android.os.Debug.stopMethodTracing();
方法,將android.os.Debug.stopMethodTracing();放在結束調試的地方。當運行了這段代碼的時候,就會有一個trace文件在/sdcard
目錄中生成,也可以調用startMethodTracing(String
traceName)
設置trace文件的文件名,最後你可以使用adb
pull /sdcard/test.trace /tmp
命令將trace文件複製到你的電腦中,然後用DDMS工具打開就會出現第一幅圖了。
上述兩種方式都可以進行測試的開始,第一種方式適用於更大範圍的調試,第二種更加的精確,可以在局部方法測試。
3、traceView中的指標
縱軸
TraceView界面下方表格中縱軸就是每個方法,包括了JDK的,Android SDK的,也有native方法的,當然最重要的就是app中你自己寫的方法,有些Android系統的方法執行時間很長,那麼有很大的可能就是你app中調用這些方法過多導致的。
每個方法前面都有一個數字,可能是全部方法按照Incl CPU Time 時間的排序序號(後面會講到)
點一個方法後可以看到有兩部分,一個是Parents,另一個是Children。
-
Parent表示調用這個方法的方法,可以叫做父方法
-
Children表示這個方法中調用的其他方法,可以叫做子方法
橫軸
1. Incl Cpu Time
Incl Cpu Time表示方法top執行的總時間,假如說方法top的執行時間爲10ms,方法a執行了1ms,方法b執行了2ms,方法c執行了3ms,方法d執行了4ms(這裏是爲了舉個栗子,實際情況中方法a、b、c、d的執行總時間肯定比方法top的執行總時間要小一點)。public void top() {
a();
b();
c();
d();
}
而且調用方法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%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
-
其他