Android系统-性能评估-2-了解systrace

systrace是一个分析Android性能问题的基础工具，但其本质上是其他某些工具的封装，包括：在host侧的封装atrace，在device端的可执行文件（用于控制用户空间的tracing和配置ftrace,即Linux内核中的主要跟踪机制）。Systrace使用atrace来enable tracing，然后读取ftrace的buffer，并且把它重新转换成HTML格式。（虽然较新的内核支持 Linux Enhanced Berkeley Packet Fliter (eBPF)，但以下文档内容仅适用于 3.18 内核（无 eFPF），因为 Pixel/Pixel XL 上使用的是 3.18 内核）。

systrace 归 Google Android 和 Google Chrome 团队所有，且是作为 Catapult 项目的一部分在开源环境中开发的。除 systrace 之外，Catapult 还包括其他有用的实用程序。例如，除了可由 systrace 或 atrace 直接启用的功能之外，ftrace 还提供了其他功能，并且包含一些对调试性能问题至关重要的高级功能（这些功能需要 root 访问权限，通常也需要新的内核版本）。

运行systrace

要在 Pixel/Pixel XL 上调试抖动问题，请从以下命令开始：

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

当该命令在加入了额外的 GPU 活动和显示管道活动所需的跟踪点时，这将使你能够从用户input一直追踪到屏幕上显示的帧。将缓冲区大小设为较大的值，以避免丢失事件（通常表现为一些 CPU 在跟踪记录中的某个点之后不包含任何事件）。

在使用 systrace 的过程中，请记住，每个事件都是由 CPU 上的活动触发的。
注意：硬件中断不受CPU控制也不会在ftrace中触发事件，实际提交到跟踪日志是由中断处理程序完成的，但一些损坏的驱动会造成中断的延迟，因此最关键点因素还是CPU本身。
因为 systrace 构建于 ftrace 之上，而 ftrace 在 CPU 上运行，所以 CPU 上的活动必须写入用于记录硬件变化情况的 ftrace 缓冲区。这意味着，如果您想知道display fence更改状态的原因，则可以查看在状态转换的确切点 CPU 上运行了哪些活动（在 CPU 上运行的某些活动在日志中触发了这种更改）。此概念是使用 systrace 分析性能的基础。

示例：工作帧

该示例介绍了正常UI管道的 systrace。要按照示例操作，请下载跟踪记录的 ZIP 文件（包括本节中提及的其他跟踪记录），将文件解压缩，然后在浏览器中打开 systrace_tutorial.html 文件。注意，该 systrace 是一个大型文件；除非您在日常工作中使用 systrace，否则这个跟踪记录应该是相对更完整的，其中包含的信息比你以前在单个跟踪记录中看到的要多很多。

对于持续的周期性工作负载（例如 TouchLatency），UI管道包含以下内容：

1. SurfaceFlinger 中的 EventThread 会唤醒应用的UI thread，表明该渲染新帧了。
2. 应用使用 CPU 和 GPU 资源在UI thread、RenderThread 和 hwuiTask 中渲染帧。这是界面占用的大部分容量。
3. 应用通过 Binder 将渲染的帧发送到 SurfaceFlinger 并进入休眠状态。
4. SurfaceFlinger 中的第二个 EventThread 唤醒 SurfaceFlinger，以触发composition和display输出。如果SurfaceFlinger 确定没有任何任务需要执行，将返回休眠状态。
5. SurfaceFlinger 通过 HWC/HWC2 或 GL 处理composition。HWC/HWC2 composition的速度更快且能耗更低，但存在限制，具体取决于 SOC。这个步骤通常需要约 4-6 毫秒，但是可以与第 2 步同步进行，因为 Android 应用始终会进行三重缓冲（虽然应用始终会进行三重缓冲，但 SurfaceFlinger 中可能只有一个待处理帧在等待，这样它就看起来与双重缓冲一样）。
6. SurfaceFlinger 将通过display驱动程序将最终内容发派到显示部分，然后返回休眠状态，等待 EventThread 唤醒。

下面我们详细介绍一下从 15409 毫秒开始的帧：

**图 1. ** 正常UI管道（EventThread 正在运行）。 对应阶段1

图 1 显示了一个由多个正常帧围绕的正常帧，因此对于理解界面管道的工作原理来说，它是一个很好的切入点。TouchLatency 的界面线程所在行在不同的时间显示为不同的颜色。柱形表示线程的不同状态：

• 灰色：正在休眠。 Sleeping

• 蓝色：可运行（它可以运行，但是调度程序尚未选择让它运行）。Runnable

• 绿色：正在运行（调度程序认为它正在运行）。 Running

  注意：中断处理程序并未在正常的单个 CPU 时间轴中显示，因此您有可能实际上是在线程运行时的某个阶段运行中断处理程序或 softirq。请检查跟踪记录的中断请求 (irq) 部分（在进程 0 下），以确认中断（而非标准线程）正在运行。

• 红色：不可中断休眠（通常在内核中处于休眠锁定状态）。可以指示 I/O 负载，在调试性能问题时非常有用。Uninterruptiable sleep

• 橙色：由于 I/O 负载而处于不可中断的睡眠状态。Uninterruptiable sleep

要查看是什么唤醒的它，请点击蓝色部分：要查看不可中断休眠的原因（可从 sched_blocked_reason 跟踪点获取），请选择红色的不可中断休眠图块。

当 EventThread 运行时，TouchLatency 的界面线程会变为可运行。要查看是什么唤醒的它，请点击蓝色部分：

**图 2. ** TouchLatency 的UI thread。对应阶段1

图 2 显示了 TouchLatency 的界面线程被与 EventThread 对应的 tid 6843 唤醒。UI thread 被唤醒：

**图 3. ** UI thread被唤醒、渲染一个帧，并将其加入队列以供 SurfaceFlinger 使用。对应阶段2

如果跟踪记录中的 binder_driver 标记已启用，则您可以选择一个 Binder 事务，并查看该事务涉及的所有进程的相关信息：

**图 4. ** Binder 事务。对应阶段3
图 4 显示在 15423.65 毫秒，SurfaceFlinger 中的 Binder:6832_1 由于 tid 9579（即 TouchLatency 的 RenderThread）变为可运行。此外，您还可以在 Binder 事务的两侧看到 queueBuffer。

在 SurfaceFlinger 端的 queueBuffer 期间，TouchLatency 中待处理帧的数量从 1 变为 2：

**图 5. **待处理帧从 1 个变为 2 个。对应阶段3
图 5 表示三重缓冲，其中两个帧已完成渲染，应用将很快开始渲染第三个帧。这是因为一些帧已经丢弃，所以应用保留两个待处理的帧而不是一个，以避免以后再丢弃帧。

稍后，SurfaceFlinger 的主线程被第二个 EventThread 唤醒，以便它可以将先前的待处理帧输出到显示部分：

**图 6. ** SurfaceFlinger 的主线程被第二个 EventThread 唤醒。对应阶段4

SurfaceFlinger 首先锁定较早的待处理缓冲区，而这将导致待处理缓冲区的数量从 2 减为 1：

**图 7. ** SurfaceFlinger 首先锁定较早的待处理缓冲区。对应阶段4

锁定缓冲区后，SurfaceFlinger 会设置构图并将最终帧提交给显示部分（其中某些区段作为 mdss 跟踪点的一部分启用，因此它们可能不在你 SOC 的相应位置上）。

**图 8. ** SurfaceFlinger 设置composition 并提交最终帧。对应阶段5

接下来，mdss_fb0 在 CPU 0 上被唤醒。mdss_fb0 是显示管道的内核线程，用于将渲染过的帧输出到显示部分。我们可以看到 mdss_fb0 位于跟踪记录中其自己所在行中的情形（向下滚动即可查看）。

图 9. mdss_fb0 在 CPU 0 上被唤醒。对应阶段6

mdss_fb0 被唤醒，短暂运行，进入不可中断休眠状态，然后再次被唤醒。

注意：从现在开始，跟踪记录将变得更为复杂，因为最后的工作会在 mdss_fb0、中断和工作队列函数之间划分。如果您需要该级别的详细信息，请参阅您 SOC 的驱动程序堆栈的确切特性（因为了解 Pixel XL 上发生的活动可能对您并无帮助）。