（两百五十一）学习systrace（二）

继续学习https://source.android.google.cn/devices/tech/debug/systrace

 

了解 Systrace

注意：如果您以前从未使用过 systrace，我们强烈建议您先阅读 systrace 概览，然后再继续。

systrace 是分析 Android 设备性能的主要工具。不过，它实际上是其他工具的封装容器：它是 atrace 的主机端封装容器，是用于控制用户空间跟踪和设置 ftrace 的设备端可执行文件，也是 Linux 内核中的主要跟踪机制。systrace 使用 atrace 来启用跟踪，然后读取 ftrace 缓冲区并将其全部封装到一个独立的 HTML 查看器中（虽然较新的内核支持 Linux 增强型柏克莱封包过滤器 (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 活动和显示管道活动所需的附加跟踪点时，您将能够跟踪从用户输入直到屏幕上显示的帧。将缓冲区大小设为较大的值，以避免丢失事件（通常表现为一些 CPU 在跟踪记录中的某个点之后不包含任何事件）。

在使用 systrace 的过程中，请记住，每个事件都是由 CPU 上的活动触发的。

注意：硬件中断不受 CPU 控制，且会在 ftrace 中触发事件，不过，向跟踪日志的实际提交操作是由中断处理程序完成的，如果您的中断已到达，而（例如）某个其他不良驱动程序已停用中断，则提交可能会延迟。因此，CPU 是关键要素。

因为 systrace 构建于 ftrace 之上，而 ftrace 在 CPU 上运行，所以 CPU 上的活动必须写入用于记录硬件变化情况的 ftrace 缓冲区。这意味着，如果您想知道显示栅栏更改状态的原因，则可以查看在状态转换的确切点 CPU 上运行了哪些活动（在 CPU 上运行的某些活动在日志中触发了这种更改）。此概念是使用 systrace 分析性能的基础。

 

示例：工作帧

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

对于一致的周期性工作负载（例如 TouchLatency），界面管道包含以下内容：

 

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

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

图 1. 正常界面管道（EventThread 正在运行）

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

• 灰色：正在休眠。
• 蓝色：可运行（它可以运行，但是调度程序尚未选择让它运行）。
• 绿色：正在运行（调度程序认为它正在运行）。

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

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

要查看不可中断休眠的原因（可从 sched_blocked_reason 跟踪点获取），请选择红色的不可中断休眠图块。

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

图 2. TouchLatency 的界面线程。

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

图 3. 界面线程被唤醒、渲染一个帧，并将其加入队列以供 SurfaceFlinger 使用。

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

图 4. Binder 事务。

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

补充下图四，显示SurfaceFlinger 详细，点击binder:6832_1 runnable的一段

 

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

图 5. 待处理帧从 1 个变为 2 个。

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

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

图 6. SurfaceFlinger 的主线程被第二个 EventThread 唤醒。

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

图 7. SurfaceFlinger 首先锁定较早的待处理缓冲区。

 

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

图 8. SurfaceFlinger 设置构图并提交最终帧。

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

图 9. mdss_fb0 在 CPU 0 上被唤醒。

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

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

 

感觉好复杂啊，待续

遗留问题

1.高亮的判定是怎么样的，按M有时候是帧，有时候是空白区域

2.再结合Google的trace理一遍流程

3.待处理缓冲区 这个数目在哪里看到呀