Android性能优化-工具使用-systrace

简介：
 Systrace允许监视和跟踪Android系统的行为(trace)。它会指明系统都在哪些工作上花费时间、CPU周期都用在哪里，甚至可以看到每个线程、进程在指定时间内都在干嘛。它同时还会突出观测到的问题，从垃圾回收到渲染内容都可能是问题对象，甚至提供建议的解决方案。但是不能确定具体有问题的代码在哪里，这里可用用traceview工具。

使用：
 我们来看看如何导出trace以及使用它来优化UI，打开Android Studio，启动Android Device Monitor。

说明1：trace输出的文件路径；
说明2：配置抓取Systrace的时间，通常设置5秒，并在5秒内重现问题，时间太短会导致问题重现时没有被抓到，时间太长会导致JavaHeap不够而无法保存，因此在能抓到问题点的情况下，时间越小越好；
说明3：Buffer Size是存储Systrace的size，同样的，太小会导致信息丢失，时间太长会导致Java Heap不够而无法保存，建议20480KB；
说明4：如果用户有自己在应用程序中加入自己的Systrace log，如下：
Trace.beginSection(“newInstance”)；
Trace.endSection( );
那么此处必须选择这个应用对应的进程名字，否则新加的Systrace log不会被抓到。
说明5：这部分TAG全部勾选。
说明6：针对UI相关的性能问题，以下TAG必须勾选：
——Bionic C Library
——CPU Frequency
——CPU Idle
——CPU Load
如果设备可以root，root后可以看到更多的TAG，root后请勾选：
——eMMC commands
——Synchonization
——Kernel Workqueues
设置完成后点击“OK"开始抓取systrace，请在此时重现性能问题，设置的时间到后，trace.html文件会被自动保存下来。用Chrome浏览器打开此文件。如果生成的trace文件无法直接打开，请在地址栏输入chrome://tracing/，然后选择load按钮，把生成的html文件load进来（不要直接open）。

Trace报告的X轴表示时间，Y轴以进程进行分组，进程组内是各个线程。每个应用进程包含每个线程所包含的所有跟踪标记，包括基于启用跟踪类别的高级跟踪事件的层次结构。
除了进程和线程运行信息，还有两个重要信息：
Frame:
在每个App进程，都有一个Frames行，正常情况以绿色的圆点表示。当圆点颜色为黄色或者红色时，意味着这一帧超过16.6ms（即发现丢帧），这时需要通过放大那一帧进一步分析问题。对于Android 5.0(API level 21)或者更高的设备，该问题主要聚焦在UI Thread和Render Thread这两个线程当中。对于更早的版本，则所有工作在UI Thread。
Alerts:
Systrace能自动分析trace中的事件，并能自动高亮性能问题作为一个Alerts，建议调试人员下一步该怎么做。
比如对于丢帧时，点击黄色或红色的Frames圆点便会有相关的提示信息；另外，在systrace的最右侧，有一个Alerts tab可以展开，这里记录着所有的的警告提示信息。
当我们点击了Alerts或者点击右边的Alerts列表中的任何一点我们可以看到在界面的最底部会相对应的优化提示以及可能会出现优化的视频教程链接。

比如上面的提示说View的draw绘制花的时间太长了，然后我们可以根据Description来很明白的看到提示的内容是什么。

操作：
Trace报告可以进行一些简单的交互，比如放大、缩小、平移和拖动等。下表列出了几个常用的快捷键：

导航操作	作用
w	放大 [+shift]速度更快
s	缩小 [+shift]速度更快
a	左移 [+shift]速度更快
d	右移 [+shift]速度更快

常用操作	作用
f	放大当前选定区域
m	标记当前选定区域
v	高亮VSync
g	切换是否显示60hz的网格线
0	恢复trace到初始态

一般操作	作用
h	切换是否显示详情
/	搜索关键字
enter	显示搜索结果，可通过← →定位搜索结果
`	显示/隐藏脚本控制台
?	显示帮助功能

通过在View Options框中输入以下name，辅助m按键，我们可以快速定位到各事件发生时间与时长等信息。

名称	含义
AppLaunch_dispatchPtr:Up	点击桌面icon离开
PostFork	Zoygate fork一个子进程
RuntimeInit	准备虚拟机资源
ActivityThreadMain	Activity主线程入口
bindApplication	建立AMS与应用的binder通信,可以看到执行了很多子方法,包括打开应用的odex,资源等
activityStart	handleLauncherActivity的时间,但这时界面还是不可见的

我们看到了“Wall duration”，代表着这一区块的开始到结束的耗时。之所以叫作“Wall duration”，是因为它就像是墙上的一个时钟，从线程的一开始就计时。
但是，CPU Duration一项中显示了实际CPU在处理这一区块所消耗的时间。