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

上篇文章中简单介绍了 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 9579Calling 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 的工作原理以及如何分析

推荐阅读更多精彩内容