第三届OpenHarmony大会回顾第8期 | 面向下一代智能终端操作系统的渲染服务研究与挑战

演讲嘉宾 | 杜冬冬

回顾整理 | 廖 涛

排版校对 | 宋夕明

嘉宾介绍

研究分论坛

杜冬冬，上海交通大学助理研究员、上海交通大学OpenHarmony技术俱乐部指导老师。研究方向为操作系统。目前围绕智能终端操作系统，在渲染服务、内核关键技术、软硬件协同、模型原生等方面开展了多项工作，成果发表在 SOSP、OSDI、ASPLOS、ISCA 等操作系统和体系结构领域顶级会议上，多项工作被开源社区和工业界大规模部署应用。

正文内容

渲染服务（Rendering Service）是终端操作系统的重要组件，能显著提升界面绘制的效率和质量，直接决定着终端用户的体验。随着AI技术的快速发展以及用户日益增长的体验需求，下一代智能终端操作系统的渲染服务将面临哪些挑战，又将如何发展？上海交通大学助理研究员杜冬冬在第三届OpenHarmony技术大会上进行了精彩分享。

什么是渲染服务？和其他终端操作系统服务一样，渲染服务通过将硬件能力（CPU、GPU 等）进行封装抽象，向应用程序提供渲染等能力的服务（2D图形渲染等）。在终端操作系统中，渲染服务是一个重要的组成部分，其直接关乎着终端设备使用者的用户体验。当前渲染服务通常包括两个架构，统一渲染和分离渲染。其中，统一渲染将主要的渲染任务都集中在一个渲染服务（如 Render Service）中，其能够带来较好的全局渲染任务管理，使能一些复杂的动效；而分离渲染是指每个应用中会有专门的渲染线程，来进行渲染任务，其能够较好地平衡不同应用的渲染负载。

分离渲染架构 统一渲染架构

现代移动端图形系统通常采用VSync架构的渲染策略，其主要特点有：显示器HAL层每帧率分之一秒向软件图形系统发送一个VSync事件；VSync事件触发软件图形系统执行该帧逻辑（输入处理、动画、渲染、合成）；该帧（或者该帧的一些阶段）通常需要在下一个VSync事件之前完成，否则会影响后一帧的执行并产生掉帧。

随着终端设备能力的快速迭代，日益增长的硬件显示需求（更清晰、更流畅、更沉浸式的硬件显示需求）和高级动效需求（持续增长的图形特性数量加重了渲染负载，使每帧的运行时间难以预测）对渲染与视窗技术提出了更大挑战。然而，极致流畅与高端精致的目标难以兼得，且掉帧与渲染时延长的问题客观存在，功耗仍需努力。

日益增长的硬件显示需求

日益增长的高级动效需求

目前，基于VSync架构执行渲染存在的主要问题是：掉帧（frame drop）和时延（latency）。

掉帧形成的主要原因是：渲染系统无法在显示器硬件VSync信号（即屏幕刷新）前准备好一帧图像上屏，导致显示器在下一个新的VSync周期内仍使用上一帧旧的图像，产生顿挫、卡顿感。

VSync逻辑示意图

当前，由于渲染负载存在波动，当出现重负载长帧时，当前VSync架构下，长帧往往无法在一个VSync周期内完成，产生偶发的掉帧。掉帧的根因是负载存在波动，而非每帧均衡。虽然大部分帧可以在一个VSync周期内完成，但仍存在少部分的重负载长帧导致掉帧，很难避免。此外，由于渲染的场景众多/动画众多/操作众多无法考虑全，用户的极限操作也无法预判，且图形框架非常复杂，对于app开发者/框架开发者无法完全掌握框架的正确用法/最好用法，导致了帧率优化困难。

Pixel 5 (Android) 帧渲染时长的箱形图

时延即从某一帧开始执行（处理输入事件）到该帧真正显示到屏幕上的时间。VSync架构规定，每一帧的UI线程和系统服务（SF/RS）必须被VSync信号触发，这种强制的对齐导致了额外的时延。此外，由于三缓冲机制（triple buffering，一种用于优化图形渲染性能的技术）允许在掉帧时渲染完的帧堆积在帧缓冲队列中，从而产生被动堆积。若有堆积，延时会额外增加一个周期。

时延会影响跟手性，在滑动过程中，小球无法完全贴合指尖（被指尖覆盖）；在快速滑动中，小球落后指尖的最大值为约为2.4cm (400 px)，平均值约为200 px。

时延与跟手性

针对上述渲染过程的掉帧和时延问题，作者本人及其所在团队基于OpenHarmony进行渲染研究分析，并提出了提出了“D-Vsync”技术。

通过观察渲染的幂律分布可知：大部分帧（95%）是短帧，能够在Vsync周期能顺利完成；小部分关键帧（5%）是长帧，负载大难以在周期内完成，并且导致丢帧等一系列影响用户体验的问题。因此，可以考虑利用短帧“省”下来的时间，去“帮”长帧（削峰填谷）。

渲染的幂律分布

与Android分离渲染架构不同，OpenHarmony采取的统一渲染架构能够实现各个App统一绘制。因此，D-Vsync（Decoupeld) OpenHarmony总体架构如下所示：

(D-)VSync OpenHarmony总体架构图

关键的设计有：

(D-)VSync应用于渲染服务进程Render Service (RS) ，管理RS每一帧的执行时机；

APP侧可以通过rs_RequestNextVSync (后文简称RNV) 请求渲染服务进程RS去执行下一帧渲染逻辑。APP侧处理输入事件响应，在有事件响应/UI动画等场景下，会调用RNV；

RS侧自己可以通过RNV请求自己执行下一帧渲染逻辑。通常为属性动画等动画场景。

其中，当APP侧请求RNV时，在VSync模式下，RS必须要在RNV请求后的第一个VSync事件到来后执行这一帧，拥有额外的等待。此外，由于用户输入、APP侧RNV不可预知，RS不能盲目提前执行。当RS属性动画自我请求RNV时，此时APP主线程不执行，RS存在长帧与短帧的负载波动，导致掉帧，属性动画场景不涉及输入，为确定性负载可以提前执行。

(D-)VSync逻辑示意图

D-VSync的帧预执行模块：D-VSync为RNV增加了新的参数，判断是外部调用（App侧事件响应、UI动画），还是自我调用（RS属性动画）。并且，D-VSync还会根据上一个VSync周期和当前VSync周期内收到的RNV类型，判断是属性动画场景、非动画场景（响应事件）、混合场景（包含动画和事件），根据场景进行相应的执行动作：

动画场景：在收到一个APP RNV时，若前一个周期内没有收到任何RNV（渲染最开始），或者前一个周期仅收到APP的RNV，则可以执行该帧；

非动画场景：在收到一个RS RNV时，前一个周期内没有收到APP的RNV，则可以执行该帧（D-VSync）；

混合场景：在收到一个RS RNV时，前一个周期内有APP的RNV，则等待该帧的APP RNV，收到后一并执行该帧；在收到一个APP RNV时，前一个周期内有RS的RNV，则等待该帧的RS RNV，收到后一并执行该帧。若等待超时，则表示输入事件流/属性动画结束，再响应该RNV执行该帧。

D-VSync 帧预执行模块

此外，帧堆积存在预设的预执行上限 X（由D-VSync控制器配置）。若响应该RNV立刻发送事件给RS会导致超出预执行上限 X，则等待到下一个VSync周期再发送该事件。发送事件前会检查该帧的虚拟时间戳和此刻系统的真实时间戳比较，两者的差值最大为X个周期（即预执行最早提前X个周期）。

D-VSync的虚拟时间戳模块：真实的VSync信号会在每个周期记录真实的时间戳和周期（realVSyncTS，realPeriod）。属性动画RNV在请求时会附带请求时这一帧的时间戳 lastVSyncTS。虚拟时间戳的计算方式如下：

属性动画场景/混合场景：lastVSyncTS + realPeriod将动画向前推进；将结果比较now确定是否已发生掉帧，若掉帧则使用realVSyncTS + realPeriod。

非动画场景：realVSyncTS + realPeriod使用下一个真实的VSync时间戳；将结果比较historyTS确保时间戳不发生回退。若小于或相等，则使用historyTS + realPeriod。

D-VSync 虚拟时间戳模块

此外，每帧在计算完虚拟时间戳后会用realVSyncTS 和 realPeriod来进行时间戳校准逻辑。虚拟的VSync时间戳expectedVSyncTS会被校准为realVSyncTS + k * realPeriod，其中k是整数。该校准逻辑避免了动画期间、非动画但是依赖于historyTS由堆积的情况下造成的时间戳误差累积。

D-VSync的控制器。控制器管理D-VSync预执行上限和D-VSync的开启与关闭（即 D-VSync 与 VSync 的实时动态切换，与静态系统配置）。当VSync -> D-VSync动态切换时，会记录pendingRNVInVSync，在D-VSync模式下，第一个真实的VSync信号触发时发送事件，之后的RNV会直接触发事件（即D-VSync的堆积）。当D-VSync -> VSync 动态切换时：D-VSync有堆积的帧，在切换回VSync模式后会跳过已经有堆积的帧的时间戳，保证不会产生时间戳回退/帧的重复（当前仅在有连续5帧空帧时会发生切换，减少能耗）。

此外，控制器还能够确保RNV不会互相覆盖、会被distributor主线程及时处理的同步逻辑，并且能够统计空帧数量，标记是否在属性动画期间等。

D-VSync控制器

未来，在AI技术和智能终端设备快速发展的背景下，下一代智能终端操作系统的渲染服务的性能表现将至关重要。面对高端精致、设备升级等挑战，如何构建并行的、动态可扩展的、负载均衡的、端到端运行时可预测的渲染与视窗服务？如何通过多设备协同渲染能力、空间计算与3D视窗能力等进一步提升用户体验？期待与大家共同探讨。