Systrace的工作原理及例子解读

Systrace的工作原理及例子解读

译文地址：https://source.android.com/devices/tech/debug/systrace

如果图片显示有问题，请访问简书，地址http://www.jianshu.com/p/6f528e862d31

systrace是一个分析android性能问题的基础工具，但本质上是其他某些工具的封装，包括：PC端的atrace，设备端的可执行文件（用于控制用户控件的追踪以及配置ftrace,即Linux内核中的主要跟踪机制）。Systrace使用atrace开启追踪，然后读取ftrace的缓存，并且把它重新转换成HTML格式。

systrace由Google Android和Google Chrome共同开发，为Catapul开源t项目的一部分。 除了systrace，Catapult还包括其他有用的工具。 例如，ftrace相比与systrace和atrace具有更多的功能，并且包含一些对调试性能问题至关重要的高级功能。 （这些功能需要root权限）

运行systrace

在Pixel/Pixel XL上调试震动时，可以通过以下命令：

./systrace.py sched freq idle am wm gfx view sync binder_driver irq workq input -b 96000

当systrace与GPU和显示管道活动所需的附加跟踪点结合使用时，您可以跟踪所有从用户输入到屏幕显示的帧。设置大的缓冲区可以避免事件的丢失（通常表现为某些CPU在跟踪中的某个点之后没有任何事件）。

当使用systrace时，注意每个事件都是在CPU上触发的。

注意：硬件中断不受CPU控制也不会在ftrace中触发事件，实际提交到跟踪日志是由中断处理程序完成的，但一些损坏的驱动会造成中断的延迟，因此最关键点因素还是CPU本身。

因为systrace构建在ftrace之上，ftrace在CPU上运行，所以硬件改变log必然会写入到的ftrace缓冲区。这就意味着如果你好奇为什么显示栏改变了，那么你可以看CPU在该转换点上的运行内容（CPU上运行的事件均被保存到log中）。这个概念是使用systrace分析性能的基础。

例子：working frame

这是一个描述正常UI管道过程的systrace，请事先下载好zip文件，点击下载zip文件，解压并在浏览器中打开systrace_tutorial.html，注意：这个文件要比一般的html文件大得多。

对于一个持续的定期的工作负载，例如TouchLatency，UI管道，通常包含以下几个阶段：

1. SurfaceFlinger中的EventThread唤醒了应用程序UI线程，表明现在是渲染新帧的时候了。
2. 应用程序使用CPU和GPU资源在UI线程，RenderThread和hwuiTasks中渲染帧。这部分暂UI的大部分。
3. 应用程序通过binder将绘制好的帧发送到SurfaceFlinger并进入睡眠状态。
4. SurfaceFlinger中的第二个EventThread唤醒SurfaceFlinger来触发组合和显示输出。如果SurfaceFlinger确定没有任何工作要完成，它将返回睡眠状态。
5. SurfaceFlinger通过HWC / HWC2或GL处理组合。 HWC / HWC2组合更快，更低的功率，但会收到SOC的限制。这一步通常需要4-6ms，但是可以与步骤2重叠，因为Android应用程序总是三重缓冲。 （虽然应用程序总是三重缓冲，但在SurfaceFlinger中只能有一个待处理帧，因此和双重缓存差不多。）
6. SurfaceFlinger通过供应商驱动程序调度最终输出，并返回睡眠状态，等待EventThread唤醒。

让我们从15409ms开始查看帧：

图1是正常的帧（对应阶段1），要了解UI管道如何工作这是一个很好的示范。 TouchLatency的UI线程行在不同时间包含不同的颜色。 不同的线代表线程的不同状态：

灰色： 睡眠。
蓝色： 可以运行（它可以运行，但还未被调度运行）。
绿色： 正在运行（调度程序认为它正在运行）。

注意：中断处理程序没有CPU时间轴中显示，因此在线程运行的过程中虽然没有显示中断，但实际上你可能已经执行了终端或者softirqs，最终需要通过检查trace(进程0)来判断终端是否发生。

红色： 不间断的睡眠（通常发生在内核锁上）， 指出I / O负载，对于性能问题的调试非常有用。
橙色： 由于I / O负载导致的不间断睡眠。
要查看不间断睡眠的原因（可从sched_blocked_reason跟踪点获取），请选择红色不间断睡眠切片。

当EventThread正在运行时，TouchLatency的UI Thread就变成了可以运行的蓝色。 要查看是什么，请点击蓝色部分：

图2（对应阶段1） 显示的是EventThread运行后，TouchLatency的tid6843唤醒UIThread为其工作，这一个信息可以从下方的“wakeup from tid:6843”看出

如果’binder_drivier’tag被开启后，你可以选择binder transaction来查看整个过程。

图4（对应阶段3） Binder transaction

如图4所示，在15423ms处，SurfaceFlinger的Binder:6832_1由于pid9579的调用变为了可运行状态。在binder tracsaction的两侧你也可以看到缓冲队列。

在SurfaceFlinger的queueBuffer中，TouchLtency的待绘制帧数量从1变为了2.

图5显示了三重缓冲，其中有两个完整的帧，应用程序将很快开始渲染第三个帧。 这是因为我们已经删除了一些帧，所以应用程序会保留两个挂起的帧而不是一个帧，以避免跳帧。

随后，SurfaceFlinger的主线程被第二个EventThread唤醒，因此它可以将的待处理帧输出到显示器：

SurfaceFlinger首先锁定较早的待绘制缓冲区，这将导致挂起的缓冲区数从2减为1：

锁定缓冲区后，SurfaceFlinger进行组装并显示新帧。

接下来，’mdss_fb0’在CPU 0上唤醒。’mdss_fb0’是显示管道的内核线程，用于将渲染的帧输出到显示器。 我们可以看到’mdss_fb0‘的信息（向下滚动查看）。