Systrace的工作原理

快来打我* 2022-03-06 13:44 215阅读 0赞

Systrace的工作原理

转：[https://www.jianshu.com/p/6f528e862d31][https_www.jianshu.com_p_6f528e862d31]

## Systrace的工作原理 ##

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

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文件][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开始查看帧：

![Image 1][]

图1 正常的UI以及EventThread

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

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

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

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

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

![Image 1][]

图2 TouchLatency的UI线程

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

![Image 1][]

图3 （对应阶段2）UI线程被唤醒，开始渲染帧，然后插入SurfaceFlinger的绘制帧队列

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

![Image 1][]

图4（对应阶段3） Binder transaction

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

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

![Image 1][]

图5（对应阶段3） 待处理帧从1到2。

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

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

![Image 1][]

图6（阶段4） SurfaceFlinger的主线程由第二个EventThread唤醒。

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

![Image 1][]

图7（阶段4）SurfaceFlinger绘制最早的待绘制缓冲帧

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

![Image 1][]

图8（阶段5）. SurfaceFlinger进行组装并提交最终的框架。

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

![Image 1][]

图9（阶段6）'mdss\_fb0'唤醒CPU0

作者：一叶一声秋  
链接：https://www.jianshu.com/p/6f528e862d31  
来源：简书  
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

## Systrace的工作原理 ##

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

## 运行systrace ##

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

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

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

## 例子：working frame ##

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

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

![Image 1][]

图1 正常的UI以及EventThread

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

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

![Image 1][]

图2 TouchLatency的UI线程

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

![Image 1][]

图3 （对应阶段2）UI线程被唤醒，开始渲染帧，然后插入SurfaceFlinger的绘制帧队列

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

![Image 1][]

图4（对应阶段3） Binder transaction

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

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

![Image 1][]

图5（对应阶段3） 待处理帧从1到2。

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

![Image 1][]

图6（阶段4） SurfaceFlinger的主线程由第二个EventThread唤醒。

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

![Image 1][]

图7（阶段4）SurfaceFlinger绘制最早的待绘制缓冲帧

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

![Image 1][]

图8（阶段5）. SurfaceFlinger进行组装并提交最终的框架。

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

![Image 1][]

图9（阶段6）'mdss\_fb0'唤醒CPU0

作者：一叶一声秋  
链接：https://www.jianshu.com/p/6f528e862d31  
来源：简书  
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

[https_www.jianshu.com_p_6f528e862d31]: https://www.jianshu.com/p/6f528e862d31
[https_source.android.com_devices_tech_debug_systrace]: https://link.jianshu.com?t=https://source.android.com/devices/tech/debug/systrace
[zip]: https://link.jianshu.com?t=https://source.android.com/devices/tech/debug/perf_traces.zip
[Image 1]: