Android 性能优化系列 - 02 理解 systrace

最新推荐文章于 2024-09-21 16:01:24 发布

一叶飘舟

最新推荐文章于 2024-09-21 16:01:24 发布

阅读量446

点赞数

文章标签： android 性能优化

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

一. 概述

在上篇文章中已经介绍过了，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 管道包括以下几步

SurfaceFlinger 中的 EventThread 唤醒 app 的 UI Thread，表明是时候渲染新帧了
App 进程通过使用 CPU、GPU 资源，在 UI Thread、RenderThread 和 hwuiTask 中完成了一帧的渲染，然后通过 binder 将渲染好的帧发送到 SurfaceFlinger 中，将该帧压入到帧缓冲队列 queueBuffer 中。App 中的线程在执行完自己的工作以后便返回到休眠状态。UI 渲染的大部分工作都在这一步中
SurfaceFlinger 中的第二个 EventThread 将唤醒 SurfaceFlinger 触发构图，并将最终帧提交到显示输出部分
- SurfaceFlinger 通过 HWC/HWC2 或 GL 处理构图，HW/HW2 处理构图的速度更快且功率更低，但是存在一些取决于 SOC 的限制
- 这一步通常需要约 4~6ms 的时间，但是这一步可以和第二步同时进行，因为在 Android 应用始终会进行三重缓冲（虽然 Android 应用中始终是三重缓冲的，但是在 SurfaceFlinger 中可能只存在一个待处理帧，所以看起来和双重缓冲很像）
- 如果 SurfaceFlinger 确定没有任何任务需要执行，则会返回休眠状态
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 而不可中断的休眠状态

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

从上面两幅图可以看出，在 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，这一步是帧渲染中执行时间很长的一步

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

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

我们选中 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

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

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

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