上篇文章中简单介绍了 systrace 的使用，以及如何简单地分析 systrace 生成的 trace.html 文件了，但是如何更深刻地理解 trace.html 文件呢？

catalog.png

一. 概述

在上篇文章中已经介绍过了，systrace 本质上是对其他工具的封装，包括 PC 端的 atrace 和设备端的 ftrace，ftrace 是 Linux 内核中的主要跟踪机制。systrace 使用 atrace 开启追踪，然后读取 ftrace 的缓存，并且把它重新转换成HTML格式。

有一个概念是使用 systrace 分析性能的基础概念，十分重要，需要大家理解：因为 systrace 是基于 ftrace 的，ftrace 是运行在 CPU 之上的，ftrace 缓冲区是用于记录硬件变化情况的，所以 CPU 上的变化情况也会写入 ftrace 缓冲区中。这也就意味着，如果你想知道显示栅栏发生变化的原因，则可以查看对应时间点上 CPU 上运行了哪些线程，发生了哪些活动，这些线程的活动就是显示栅栏发生变化的原因。

二. 示例：工作帧

这个示例介绍了一个正常 UI 管道（UI pipeline）的 systrace 工作流程，请先下载好 trace 文件，点这里下载。

对于一个持续的、周期性的工作负载 workload（比如：TouchLatency app），它的 UI 管道包括以下几步

1. SurfaceFlinger 中的 EventThread 唤醒 app 的 UI Thread，表明是时候渲染新帧了

2. App 进程通过使用 CPU、GPU 资源，在 UI Thread、RenderThread 和 hwuiTask 中完成了一帧的渲染，然后通过 binder 将渲染好的帧发送到 SurfaceFlinger 中，将该帧压入到帧缓冲队列 queueBuffer 中。App 中的线程在执行完自己的工作以后便返回到休眠状态。UI 渲染的大部分工作都在这一步中

3. SurfaceFlinger 中的第二个 EventThread 将唤醒 SurfaceFlinger 触发构图，并将最终帧提交到显示输出部分

   • SurfaceFlinger 通过 HWC/HWC2 或 GL 处理构图，HW/HW2 处理构图的速度更快且功率更低，但是存在一些取决于 SOC 的限制

   • 这一步通常需要约 4~6ms 的时间，但是这一步可以和第二步同时进行，因为在 Android 应用始终会进行三重缓冲（虽然 Android 应用中始终是三重缓冲的，但是在 SurfaceFlinger 中可能只存在一个待处理帧，所以看起来和双重缓冲很像）

   • 如果 SurfaceFlinger 确定没有任何任务需要执行，则会返回休眠状态

4. SurfaceFlinger 通过供应商驱动程序将最终输出部分调度到显示部分，然后返回休眠状态，等待下一次 EventThread 的唤醒

下面将结合 systrace_tutorial.html 文件具体分析一下上面几个步骤

2.1 EventThread 唤醒 App 的 UI Thread

如下图所示，在 15409.744 ms 处，可以看到在 Kernel CPU0 上运行了一个 EventThread 线程，从底部的描述信息可知 tid：6843，与此同时，在 com.prefabulated.touchlatency 应用中的 UI Thread 有一小段蓝色部分。

在 systrace 中线程是具有颜色的，不同的颜色代表此时线程处于不同的状态，各个颜色及状态说明如下：

• 灰色：Sleeping，处于休眠状态
• 蓝色：Runnable，线程可以运行，但是调度器 scheduler 尚未调度让它运行
• 绿色：Actively running，调度器 scheduler 认为它目前正处于运行状态
• 红色：Uninterruptible sleep，不可中断的休眠状态，通常处于内核中休眠锁定状态（generally sleeping on a lock in the kernel），一般是正在进行 I/O 操作，红色状态时通常对于性能调试非常有用
• 橙色：Uninterruptible sleep due to I/O load，由于 I/O load 而不可中断的休眠状态

systrace1.png

如下图所示，如果选中 com.prefabulated.touchlatency 应用中 UI Thread 最开始的一小段蓝色状态，可以看到此时 UI Thread State 是 Runnable 的（可运行状态，但是未被 调度器 scheduler 调度到 CPU 上执行），在下面的描述信息中可以看到 "wakeup from tid：6843"，正是由上图中所示的 EventThread 唤醒的

systrace2.png

从上面两幅图可以看出，在 EventThread 执行时 com.prefabulated.touchlatency 应用中的 UI Thread 变成了 Runnable 的状态了，正是第一步 SurfaceFlinger 中的 EventThread 唤醒 app 应用中的 UI Thread，使其处于 Runnable 的状态，表明是时候开始渲染新帧了。

2.2 App 进程开始渲染新的一帧并通过 Binder 发送数据到 SurfaceFlinger 中

第二步主要是在应用进程中，通过 CPU 和 GPU 资源，在 UI Thread、RenderThread 和 hwuiTask1 中渲染帧，最后通过 binder 将渲染帧数据发送到 SurfaceFlinger 中。

如下图所示，com.prefabulated.touchlatency 进程中 UI Thread、RenderThread 和 hwuiTask1 中渲染帧，最后调用了 binder，这一步是帧渲染中执行时间很长的一步

systrace3.png

我们选中上图小红框中的 binder_transaction，可以在下面的描述信息中看到如下所示的信息，Destination Process 6832 Calling PID 9579、Calling tgid 9564，表明此时 RenderThread 正在和 ProcessId 是 6832 进程进行 binder 通信，如下图所示

systrace4.png

我们看一下 SurfaceFlinger 进程中，此时正在运行的 Binder:6832_1，如下图所示

systrace5.png

我们选中 Binder:6832_1 中的 binder replay，可以在底部看到 Destination Process: 9564，Destination Thread：9579，Calling PID：6836，Calling tgid：6832，顾名思义，binder replay 正在响应刚才 RenderThread 的发出的 binder_transaction，Destination Process 是 9564，也正是 com.prefabulated.touchlatency 的 processId

systrace6.png

在 SurfaceFlinger 进程中，通过 binder 接收到的 frame 帧数据被压入到 queueBuffer 中，从下图中可以看到，在 binder_reply 执行前后 com.prefabulated.touchlatency 中缓冲的帧由 1 个变成了 2 个。

下图表示了三重缓冲，在缓冲队列中存在两个已缓冲的帧，应用程序将很快开始渲染第三帧

systrace6.png

在 com.prefabulated.touchlatency 进程通过 CPU 和 GPU 资源在 UI Thread、RenderThread 和 hwuiTask1 中计算好渲染帧以后，通过 binder 将渲染帧发送到 SurfaceFlinger 进程中，然后就返回了休眠状态，如下图所示的三个红色的框，表示的是灰色的，就是指此时线程正在休眠状态，直到下一时刻被唤醒，重新渲染下一帧

systrace7.png

2.3 SurfaceFlinger 锁定缓冲区中的帧触发构图并提交最终帧到显示输出

接下来将开始第三步的工作，SurfaceFlinger 被第二个 EventThread 唤醒，并从缓冲区中锁定较早的一帧，触发构图，并将最终帧提交到显示输出部分。

如下图所示，在 15430.345 ms 处执行第二个 EventThread，唤醒 SurfaceFlinger，使其处于可运行的状态（Runnable，蓝色的），从底部的描述信息中可以看到其 tid：6845

systrace8.png

我们再选中 SurfaceFlinger 中可运行的部分（Runnable，蓝色的），如下图所示，可以看到描述信息 "wakeup from tid: 6845"，说明 SurfaceFlinger 此时确实是被上图中所示的 EventThread 唤醒的

systrace9.png

之后 SurfaceFlinger 便锁定缓冲区中较早的一帧并触发构图，然后将最终帧提交给显示输出部分。

如下图所示，在 15413.169 ms 处，通过 acquireBuffer 方法锁定缓冲区中较早的一帧，queueBuffer 中缓冲帧的数量也由两个，变成了一个

systrace10.png

如下图所示，在锁定缓冲区中较早的一帧以后，便通过 doComposition 方法触发了构图，并且在 15433.787 ms 处通过 ATOMIC_COMMIT 操作将最终帧提交到显示输出

systrace11.png

2.4 驱动程序将最终输出部分调度到显示部分

紧接着 mdss_fb0 线程被唤醒，如下图所示，mdss_fb0 线程是显示管道的内核线程，用于将渲染过的帧输出到显示部分

systrace12.png

如下图所示，可以看到 mdss_fb0 的执行情况，mdss_fb0 的具体执行信息需要查看相关的驱动程序文档了。

systrace13.png

三. 总结

上述内容是自己对 Understanding Systrace 部分内容的翻译（其实已经有官方的翻译 了解 Systrace，但是我觉得翻译的并不好，层次感也不够强 ），经过自己消化理解输出的，也算是自己的学习。

通过本文有两点收获

• 分析 systrace 生成的 trace.html 更加得心应手，比如对一些快捷键的使用更熟练、更深刻的理解了底部的文字描述信息
• 对 Android 中每一帧 Frame 的渲染流程更加熟悉，对帧 Frame 的渲染流程有了直观 & 完整的理解

希望本文也可以帮助到更多的朋友。

四. 参考

了解 systrace
Understanding Systrace
Systrace 的工作原理以及如何分析