Systrace的工作原理以及如何分析

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文件,解压并在浏览器中打开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 正常的UI以及EventThread

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

灰色: 睡眠。
蓝色: 可以运行(它可以运行,但还未被调度运行)。
绿色: 正在运行(调度程序认为它正在运行)。

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

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

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

图2 TouchLatency的UI线程

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

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

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

图4(对应阶段3) Binder transaction

图4(对应阶段3) Binder transaction

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

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

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

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

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

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

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

图7(阶段4)SurfaceFlinger绘制最早的待绘制缓冲帧

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

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

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

图9(阶段6)'mdss_fb0'唤醒CPU0

推荐阅读更多精彩内容