性能優化工具（二）-Systrace

1、簡介

Systrace是分析Android性能問題的神器，Google IO 2017上更是對其各類強推. 是分析卡頓掉幀問題核心工具，只要能提供卡頓現場，systrace就能很好定位問題，可是有必定上手難度，因此會稍微花比較多的篇幅來學習，固然systrace配合traceView使用效果更佳，以後也會介紹traceView。

2、原理

在介紹使用以前，先簡單說明一下Systrace的原理：它的思想很樸素，在系統的一些關鍵鏈路（好比System Service，虛擬機，Binder驅動）插入一些信息（我這裏稱之爲Label），經過Label的開始和結束來肯定某個核心過程的執行時間，而後把這些Label信息收集起來獲得系統關鍵路徑的運行時間信息，進而獲得整個系統的運行性能信息。Android Framework裏面一些重要的模塊都插入了Label信息（Java層的經過android.os.Trace類完成，native層經過ATrace宏完成），用戶App中能夠添加自定義的Label，這樣就組成了一個完成的性能分析系統。另外說明的是：Systrace對系統版本有一個要求，就是須要Android 4.1以上。系統版本越高，Android Framework中添加的系統可用Label就越多，可以支持和分析的系統模塊也就越多；所以，在可能的狀況下，儘量使用高版本的Android系統來進行分析。

3、日誌獲取

3.1 AndroidStudio 抓取：

1）打開Android Device Monitor，選擇要分析的進程(好比com.google.process.gapps)，點擊Capture system wide trace using Android systrace（下圖右上角箭頭所指的地方）

2）配置須要抓取Systrace的內容

Trace duration 默認5秒，
Trace Buffer Size 默認2M，理論上，時間越長，須要的buffer越大
Enable Application Traces from : 選擇要監控的app， 若是沒有就選none
根據須要勾選要展現數據的內容。
生成trace.html 文件後，直接在瀏覽器中打開就能夠。

3.2 命令行抓取（推薦）
命令行
python systrace.py [options] [category1] [category2] ... [categoryN]

配置好adb，python。

1）保持ADB device的鏈接；
2）cd 到systrace的目錄下：如cd Library/Android/sdk/platform-tools/systrace;
3）好比我執行以下操做：

python systrace.py --time=10 -o mytrace.html sched gfx view wm

時間默認是5秒，在這5秒過程當中作對應的操做，mytrace.html即我生成的檢測結果，在systrace中找到並用chrome打開。

抓取的過程就是：在執行以上命令以後，開始你對應的手機操做，最終生成trace的html文件供分析，固然咱們也發現了，命令後面帶了一串參數：sched gfx view wm ，它決定了你的trace輸出的數據包含哪些內容，若是trace數據太繁雜會讓你眼花繚亂，因此縮小須要分析的數據集合會有助於咱們定位問題，所以下面來了解下這些參數有哪些，都是幹嗎的，對應的分析場景應該使用哪些。

先來了解下這些參數有哪些：

參數分爲兩個部分options和category

options可取值：

options	解釋
-o <FILE>	指定trace數據文件的輸出路徑，若是不指定就是當前目錄的trace.html
-t N, –time=N	執行時間，默認5s。絕對不要把時間設的過短致使你操做沒完Trace就跑完了，這樣會出現Did not finish 的標籤，分析數據就基本無效了
-b N, –buf-size=N	buffer大小（單位kB),用於限制trace總大小，默認無上限
-k <KFUNCS>，–ktrace=<KFUNCS>	追蹤kernel函數，用逗號分隔
-a <APP_NAME>,–app=<APP_NAME>	這個選項能夠開啓指定包名App中自定義Trace Label的Trace功能。也就是說，若是你在代碼中使用了Trace.beginSection("tag"), Trace.endSection；默認狀況下，你的這些代碼是不會生效的，所以，這個選項必定要開啓
–from-file=<FROM_FILE>	從文件中建立互動的systrace
-e <DEVICE_SERIAL>,–serial=<DEVICE_SERIAL>	指定設備，在特定鏈接設備上進行跟蹤，由設備序列號標識 。
-l, –list-categories	這個用來列出你分析的那個手機系統支持的Trace模塊，通常來講，高版本的支持的模塊更多

category可取值：

category	解釋
gfx	Graphic系統的相關信息，包括SerfaceFlinger，VSYNC消息，Texture，RenderThread等；分析卡頓很是依賴這個。
input	Input
view	View繪製系統的相關信息，好比onMeasure，onLayout等。。
webview	WebView
wm	Window Manager
am	ActivityManager調用的相關信息；用來分析Activity的啓動過程比較有效。
sm	Sync Manager
audio	Audio
video	Video
camera	Camera
hal	Hardware Modules
app	Application
res	Resource Loading
dalvik	虛擬機相關信息，好比GC停頓等。
rs	RenderScript
bionic	Bionic C Library
power	Power Management
sched	CPU調度的信息，很是重要；你能看到CPU在每一個時間段在運行什麼線程；線程調度狀況，好比鎖信息。
binder_driver	Binder驅動的相關信息，若是你懷疑是Binder IPC的問題，不妨打開這個。
core_services	SystemServer中系統核心Service的相關信息，分析特定問題用。
irq	IRQ Events
freq	CPU Frequency
idle	CPU Idle
disk	Disk I/O
mmc	eMMC commands
load	CPU Load
sync	Synchronization
workq	Kernel Workqueues
memreclaim	Kernel Memory Reclaim
regulators	Voltage and Current Regulators

[options] 是一些命令參數，[category] 是你感興趣的系統模塊，好比view表明view系統（包含繪製流程），am表明ActivityManager（包含Activity建立過程等）；分析不一樣問題的時候，能夠選擇不一樣你感興趣的模塊。須要重複的是，儘量縮小須要Trace的模塊，其一是數據量小易與分析；其二，雖然systrace自己開銷很小，可是縮小須要Trace的模塊也能減小運行時開銷。好比你分析卡頓的時候，power, webview 就幾乎是無用的。

經常使用的比較通用的命令：
./systrace.py -t 10 -a <package_name> -o xxtrace.html app sched gfx view am wm dalvik binder_driver freq idle load sync

4、工具簡單使用介紹

使用Web瀏覽器打開HTML報告

該報告列出了呈現UI幀並指示沿時間線的每一個渲染幀的每一個進程。用綠色框架圓圈表示在16.6毫秒內渲染以保持每秒60幀穩定所需的幀。渲染時間超過16.6毫秒的幀用黃色或紅色框架圓圈表示。

注意：
在運行Android 5.0（API級別21）或更高版本的設備上， UI 渲染的工做是在UI Thread和RenderThread兩個線程完成。 在以前的版本中，建立框架的全部工做都是在UI Thread上完成的。

單擊框架圓圈會突出顯示它，並提供有關係統完成該框架所作工做的其餘信息，包括警報。它還會向您顯示系統在渲染該幀時執行的方法，所以您能夠調查這些方法以獲取UI jank的緣由。

點擊黃色或紅色幀按鈕，會分析提示此幀卡頓的信息

選擇慢幀後，您可能會在報告的底部窗格中看到警報。 上圖中顯示的Alert提出，框架的主要問題是在ListView回收和從新綁定中花費了太多的時間。 跟蹤中有相關事件的連接能夠解釋更多關於系統在這段時間內正在作什麼的事情。

要查看工具在trace中發現的每一個Alert以及設備觸發Alert的次數，請單擊窗口最右側的Alerts選項卡，以下圖所示。

Alerts面板可幫助您查看發生了哪些問題，以及發生的頻率。 將Alert面板看做是要修復的錯誤列表， 一般狀況下，一個區域的微小變化或改進能夠消除應用程序中的所有警報。

若是你在UI Thread上作太多的工做，你須要找出哪些方法消耗了太多的CPU時間。

一種方法是添加跟蹤標記到您認爲會致使這些瓶頸的方法，以查看這些函數調用是否顯示在systrace中。 若是您不肯定哪些方法可能會在UI線程上形成瓶頸，請使用Android Studio的內置CPU分析器，或者生成跟蹤日誌並使用Traceview查看它們。

固然除了看frame 紅 黃 綠狀態以及系統給出的描述以外，還有其餘值得關注的點：

從app角度出發：

1）發現黃色 尤爲是紅色的幀，這種顏色表示超過了16ms的繪製要求了，那就看看兩幀之間都作了些什麼，缺乏信息的就打點trace進去。或者結合Traceview去排查方法耗時的問題。
2）systrace上task的運行狀態:
灰色：Sleeping
藍色：Runnable （它能夠運行，可是須要等待調度程序喚醒)
綠色：Running
橙色：Uninterruptible sleep 因爲 I/O 負載而不可中斷休眠

尤爲關注Runnable， 頗有可能wake by pid xxx , cpu此時被xxx進程搶佔着，去看看這個進程是否有什麼異常。

從framework層面出發：

這個流程是Surfaceflinger每隔16ms接收vsync信號進行layer合成的操做，看看這個操做自己是否就超過了16ms
SurfaceFlinger不瞭解的能夠先看看這個系列的問題：Android圖形系統篇總結

 

五 、Android 官方案例分析

最後給一個官方案例的分析來給點分析啓發吧
https://source.android.com/devices/tech/debug/systrace