效能優化工具（二）-Systrace
一、簡介
Systrace是分析Android效能問題的神器，Google IO 2017上更是對其各種強推. 是分析卡頓掉幀問題核心工具，只要能提供卡頓現場，systrace就能很好定位問題，但是有一定上手難度，所以會稍微花比較多的篇幅來學習，當然systrace配合traceView使用效果更佳，之後也會介紹traceView。
二、原理
在介紹使用之前，先簡單說明一下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.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
四、工具簡單使用介紹
使用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/systra