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开发人员，仍是掌握较好。
更多的开发知识，或有什么问题，能够关注个人公众号，给我留言：