Android效能分析工具Systrace和TraceView的使用
1.Systrace的介紹
Systrace是Android4.1中新增的效能資料取樣和分析工具。它可幫助開發者收集Android關鍵子系統（如Surfaceflinger、WindowManagerService等Framework部分關鍵模組、服務）的執行資訊，從而幫助開發者更直觀的分析系統瓶頸，改進效能。 Systrace的功能包括跟蹤系統的I/O操作、核心工作佇列、CPU負載以及Android各個子系統的執行狀況等。
在Android平臺中， 它主要由3部分組成： 1.核心部分：Systrace利用了Linux Kernel中的ftrace功能。所以，如果要使用Systrace的話，必須開啟kernel中和ftrace相關的模組。 2.資料採集部分：
2.Systrace跟蹤程式碼
(1).應用層程式碼新增systrace跟蹤方式: Trace.beginSection(“TEST”); Trace.endSection();(2).framework的java層程式碼新增systrace跟蹤方式: Trace.traceBegin(Trace.TRACE_TAG_VIEW, “performTraversals”); Trace.traceEnd(Trace.TRACE_TAG_VIEW); 也可以使用： ATRACE_BEGIN(“TEST”); ATRACE_END();(3).framework的native程式碼新增systrace跟蹤方式:
3.Systrace的執行方式
>sdk包下手動執行： $> cd android-sdk/tools/systrace $> python systrace.py --set-tags gfx,view,wm $> adb shell stop $> adb shell start $> python systrace.py --disk --time=10 -o mynewtrace.html
4.Systrace資料分析
>當Systrace執行之後，將記錄系統預定的跟蹤資料，生成一個html檔案，如圖：
5.Systrace使用示例
Android流暢程度效能分析： (1).將幾臺連結Eclipse之後，按照上頁所述，開啟Android System Trace設定面板。 (2).如果要測試介面流暢度，我們一般只關注圖形效能。因此必須選擇Graphics和View（還有其他很多選項，如果是在做音訊處理或者視訊播放的分析測試話，可以選擇其他選項）。 (3).確認執行之後，滾滑要測試的介面，記錄跟蹤時間，之後我們會得到一個html頁面。 (4).開啟html頁面後，頁面中顯示了系統執行情況的概述圖；欲檢視具體資料可以通過WASD快捷鍵來完成，W/S 放大/縮小 A/D 左移/右移。 (5).在頁面中有一個surfaceFlinger模組， 此模組是負責繪製Android應用程式UI的服務，此區域如果出現空檔，一種情況是沒有操作或者滑動到頭，沒東西需要繪製，這種屬於正常；另一種情況就是有問題存在，有其他操作引起時間過長。 (6).在分析局域，放大後就能看到具體的函式執行情況，點選後能看到每個部分所使用的時間。比如deliverInputEvent是系統提供的觸控事件；performTraversals是開始佈局並且繪畫顯示畫面的過程；draw是繪畫的過程；對於一個 listview，如果deliverInputEvent過長，很有可能是在adapter中的getView方法中處理時間過長導致。 所以通過Systrace的資料，可以大體上的發現是否存在效能問題。但如果要知道具體情況，就需要用到另外一個工具。
6.TraceView的介紹
通過Systrace分析資料，可以大體上發現是否存在效能問題。
但如果要知道具體情況，就需要用到另外一個工具TraceView是android的一個視覺化的除錯工具。
藉助它，你可以具體瞭解你的程式碼在執行時的效能表現。
它能幫你更好了解到程式碼執行過程的效率，進而改善程式碼，提高你應用的體驗。
同時TraceView是Android平臺特有的資料採集和分析工具，它主要用於分析Android中應用程式的hotspot。
讓我們瞭解我們要跟蹤的程式的效能，並且能具體到methodTraceview的作用： (1). 檢視跟蹤程式碼的執行時間，分析哪些是耗時操作。 (2). 可以用於跟蹤方法的呼叫，尤其是Android Framework層的方法呼叫關係。 (3). 可以方便的檢視執行緒的執行情況，某個方法執行時間、呼叫次數、在總體中的佔比等，從而定位效能點。
7.TraceView的執行方式
手動執行： 在開始除錯的地方，如Activity的onCreate函式， 新增Debug.startMethodTracing("tracefilename"); 結束除錯的地方，如Activity的onStop函式， 新增Debug.stopMethodTracing(); 之後執行你的app一段時間並退出，會在sd卡根目錄生成tracefilename.trace這個log檔案，記錄這段時間內的執行資訊。 將日誌檔案pull到PC端，cmd到android sdk tools資料夾內(或繫結sdk tools目錄到系統path內)，執行traceview tracefilename.trace即可開啟TraceView分析介面。
使用DDMS: 開啟devices視窗，選擇某個程序，點選右上角的start method profilingddms trace，執行app一段時間後，再點選已變成stop method profiling的該按鈕。eclipse會自動彈出debug的標籤（可通過選單File->save as儲存資料）。
介面如下：
8.TraceView的資料分析
Timeline Panel(時間線面板) ：
Profile Panel(分析面板)：
分析面板主要展示了某個執行緒（先在Timeline Panel中選擇執行緒）中各個函式呼叫的情況，包括CPU使用時間、呼叫次數等資訊。而這些資訊正是查詢hotspot的關鍵依據。點選某個方法可以檢視在對應執行緒上的執行時間區域，並會顯示其父方法及子方法。 Profile Panel各列資訊作用說明 如下：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類似，只不過統計單位換成了真實時間
9.TraceView使用示例
通常，查詢hotspot包括兩種型別的函式：
第一類是呼叫次數不多，但每次呼叫卻需要花費很長時間的函式。
方法：在Profile Panel中，選擇按Cpu Time/Call進行降序排序（從上之下排列，每項的耗費時間由高到低），如上圖所示。
展開函式，我們發現getStringsToShow在 Incl Cpu Time %一列中佔據了63.3%，它是onCreate子函式耗費時間最長的，而且Calls+Recur Calls/Total列顯示其呼叫次數為1，即它僅僅被呼叫一次了。這個函式是應用程式實現的，所以極有可能是一個潛在的Hotspot。
第二類是那些自身佔用時間不長，但呼叫卻非常頻繁的函式。
方法：點選Call/Recur Calls/Total列頭，使之按降序排列。關注點放在那些呼叫頻繁並且佔用資源較多的函式。
如上圖所示。紅框處有兩個過載的MyMD5.getHashString函式呼叫，它們各運行了368次，而且佔用的CPU時間百分比達到了31.8%和53.2%。很顯然，這2處呼叫就是hotspot，有優化的餘地 。
10.結論
>如今Android系統日趨穩定，儲存容量也越來越大，對原始碼質量的要求也不斷降低。
但是很多開發工程師在開發的過程中不注重程式碼質量，不考慮系統性能和使用者體驗，
因此開發出的產品往往效能低下，使用者體驗機差。 >為了很好的驗證產品的效能，目前有很多工具可以用來分析測試Android的效能，比如：dumpsys、Systrace、TraceView、Update Threads（更新執行緒）、Update Heap（更新堆）、Allocation Tracker（分配跟蹤器）等工具，這裡我們僅僅介紹了其中兩個。