Android應用開發完成後，一般都會需要關注性能優化的問題，可是哥比較悲慘還沒走到這一步就出現動畫滑動不流暢的問題，花了不少時間去優化插值函數效果也不佳。最後無意中把APK安裝到其他廠家的盒子上發現動畫就流程了，開始懷疑跟平臺相關。可直接這樣拋給平臺也不太負責了，也不符合哥的風格，還是得往深里扣啊。用兩篇博文來記錄一下這次查找問題原因的過程，本文介紹TraceView。
一： TraceView 簡介
TraceView 是Android平臺數據採集和分析工具，它可以分析應用程序的性能，而採集數據可以通過DDMS工具來實現。如圖1所示：
圖1： 啓動TraceView採集數據
按照圖1方法，打開device後選中需要採集的應用，點擊對應圖標啓動採集數據，再次點擊結束採集。
二：TraceView結果分析
TraceView 界面比較負責，其中UI分兩部分，包括Timeline Panel（時間線面板）和Profile Panel（分析面板）。如圖2所示
圖2： TraceView UI面板
從圖2可以看出，時間面板對應了時間軸上的方法調用，同時能看到該方法的測試時間。Profile Panel是Traceview的核心界面，其內涵非常豐富。它主要展示了某個線程（先在Timeline Panel中選擇線程）中各個函數調用的情況，包括CPU使用時間、調用次數等信息。而這些信息正是查找hotspot的關鍵依據。所以，對開發者而言，一定要了解Profile
Panel中各列的含義。筆者總結了其中幾個重要列的作用，如表1所示：
|
列名 |
描述 |
|
Name |
該線程運行過程中所調用的函數名 |
|
Incl Cpu Time |
某函數佔用的CPU時間，包含內部調用其它函數的CPU時間 |
|
Excl Cpu Time |
某函數佔用的CPU時間，但不含內部調用其它函數所佔用的CPU時間 |
|
Incl Real Time |
某函數運行的真實時間（以毫秒爲單位），內含調用其它函數所佔用的真實時間 |
|
Excl Real Time |
某函數運行的真實時間（以毫秒爲單位），不含調用其它函數所佔用的真實時間 |
|
Call+Recur Calls/Total |
某函數被調用次數以及遞歸調用佔總調用次數的百分比 |
|
Cpu Time/Call |
某函數調用CPU時間與調用次數的比。相當於該函數平均執行時間 |
|
Real Time/Call |
同CPU Time/Call類似，只不過統計單位換成了真實時間 |
對應性能有影響的我們一般需要關注兩類API：
1，每次執行佔用CPU資源多
2，調用頻繁的API
對於第1類方法，可以通過按Cpu Time/call 來排序，找到平均執行CPU時間長的方法，看是否存在問題。
對於第2類方法，可以通過按Call+Recur Calls/Total來排序，看調用頻繁且佔CPU資源多的方法，檢查是否存在問題。
我這裏遇到的問題是，同一APK在兩個平臺上表現不一樣，一個平臺A動畫平滑，另一個平臺B動畫會出現卡頓。很自然的會通過對比兩個平臺的Traceview來找原因，結果並不像想象中那樣，對比發現兩個平臺traceview基本相當，如下圖
圖3 平臺A的分析面板數據
圖2 平臺B中的TraceView
兩個平臺的traceView基本相當，也找不出哪裏的問題。但在這個對比中有兩個重要的收穫：
1， 從traceView分析面板中，可以跟蹤沒個函數的調用關係，對閱讀framework代碼有很大幫助，另外在跟蹤函數過程中發現只能追蹤JAVA層代碼而Native的及不是本進程的代碼也無法跟蹤。正是這個原因導致用traceView沒有分析出爲什麼在平臺B中會有動畫卡頓的問題。
2，跟蹤函數過程中發現了Choreographer類及Vsync（後面還會介紹到），這個類是Android 4.1以後引如爲解決UI平滑度的，感興趣的可以點擊打開鏈接。相信對UI平滑會有更深的理解。