Android UI性能的探雷針——Systrace

關於App UI性能的測試，Android提供了一個原生的工具Systrace，正常渲染FPS通常是在60左右，可是若是有一些代碼寫的很差，可能會影響到UI的性能，致使界面卡頓，這種問題是最難查的，爲何會卡頓，在哪卡頓，固然你也能夠打log看時間，可是畢竟不方便。Systrace是能夠解決這個問題的，我在網上查了一下關於Systrace的資料，仍是比較少的，也許用的人也少吧。因此本文大部份內容翻譯自谷歌官方文檔

---

準備工做

首先若是你要運行Systrace，須要安裝Python和Android SDK Tools 20 以上的版本。
同時，如今Systrace只支持Android4.1以上的版本。

開始記錄

關於記錄有兩種方式開啓，一種就是使用Python，另一種就是使用AndroidStudio中的自帶插件。
這裏有一個問題，我不確認，是否使用AndroidStudio中的自帶插件也須要安裝Python，由於個人電腦一直安裝着這些東西，因此，能夠直接運行。

Python 啓動

首先命令行切換到Android SDK的platform-tools下，在這個文件夾下有一個systrace文件夾，而後切到這個文件夾下：

在這個文件夾下有一個python腳本，運行便可。

python systrace.py --time=10 -o mynewtrace.html sched gfx view wm複製代碼

運行規則以下：

參數名	意義
-h,--help	幫助信息
-o	保存的文件名
-t N,--time=N	多少秒內的數據，默認爲5秒，以當前時間點日後倒N個時間
-b N,--buf-size=N	單位爲千字節,限制數據大小
-k --ktrace=	追蹤特殊的方法
-l,--list-categories	設置追蹤的標籤
-a ,--app=	包名
--from-file=	建立報告的來源trace文件
-e ,--serial=	設備號

標籤簡寫：

簡寫	全稱
gfx	- Graphics
input	- Input
view	- View
webview	- WebView
wm	- Window Manager
am	- Activity Manager
sync	- Synchronization Manager
audio	- Audio
video	- Video
camera	- Camera

根據官方文檔的意思，這些標籤在SDK 17如下須要使用

--set-tags = <TAGS>複製代碼

進行添加，SDK18以及更高直接用簡寫便可，這個標籤表示生成性能分析結果中的標籤，這個後面再看。

Android Studio啓動

打開Android Studio：

點擊如圖所示的標籤，打開Android Device Monitor這個界面，在左上角選擇以下按鈕：

而後進入可視化設置界面：

進行設置，點擊ok，即可開始記錄。

數據分析

我這裏將會使用命令行模式進行數據記錄。
在記錄以前，我先寫了一個簡單的demo，demo有三個Activity，一個主界面，一個放有listview的Activity，一個放有RecyclerView的Activity（代碼很基礎我就不貼出來了）
在listview中我加入了1000個Item，每一個item中都有文字和圖片，RecyclerView也是。特別注意，listview沒有作任何優化，由於咱們要看的就是很差的效果。我先運行一下程序，而後在命令行中輸入以下：

python systrace.py --time=20 -o deep.html -a deep.testsystrace sched gfx view wm複製代碼

我記錄了20秒內的狀況，指定包名deep.testsystrace，生成文件deep.html，運行，而後不斷滑動listview：
直到記錄結束，命令行會有以下提示：

而後咱們打開這個文件夾，找到剛纔生成的deep.html。

打開這個網頁：

在分析這些數據以前，咱們須要先知道一些操做：

Key	Description
w	Zoom into the trace timeline.
s	Zoom out of the trace timeline.
a	Pan left on the trace timeline.
d	Pan right on the trace timeline.
e	Center the trace timeline on the current mouse location.
g	Show grid at the start of the currently selected task.
Shift+g	Show grid at the end of the currently selected task.
Right Arrow	Select the next event on the currently selected timeline.
Left Arrow	Select the previous event on the currently selected timeline.

咱們在網頁中找到咱們的工程，deep.testsystrace,可是不知道是否是bug，網頁只顯示了ep.testsystrace，不過根據pid也能夠確認就是咱們的應用。
以後咱們逐個分析，首先是Frames，即幀數。咱們將上圖放大（快捷鍵w）：

能夠看到幀數對應的一行有許多F，各類顏色：
當顯示爲綠色的時候爲正常，紅色或者黃色分別對應的等級是e和w，也就是不正常，即達不到60fps的水準。這是咱們就能夠根據下面的時間分析究竟是什麼佔用的時間了。
首先點擊紅色即不正常的F：

與該幀無關的操做會被置成灰色：

而後將其逐漸放大：

對比正常的幀，咱們能夠發現，咱們obtainView和inflate調用過多。咱們以前說了，listview咱們沒有作任何優化，每次都會重現創建view，也沒有使用viewholder，因此會出現如上結果。若是咱們對listview進行了優化呢？咱們能夠試一下，修改一下adapter的getview，當view爲空時再進行建立。而後再次記錄數據：

咱們發現已經沒有紅色的F了，可是仍有少數黃色的F，咱們能夠根據分析再次進行優化，加上ViewHolder。這裏再也不作測試了。
一樣咱們也能夠根據Alert中的提示進行修改，可是感受提示不能直指緣由，仍是分析幀數，更容易找到緣由。

自定義記錄

咱們還能夠經過Trace.beginSection來記錄一些信息，以下代碼：

Trace.beginSection() 與 Trace.endSection() 之間代碼工做會一直被追蹤。結果以下，爲了查看方便我把結果放大了：

能夠以這種方式查看某個程序塊的耗時。

總結

用這種方式能夠分析出app 卡頓的一些問題的緣由，從而進行解決。對於app開發人員，仍是掌握較好。
更多的開發知識，或有什麼問題，能夠關注個人公衆號，給我留言：