【最佳实践】帧率和丢帧分析实践（一）

丢帧问题概述

应用丢帧通常指的是在应用程序的界面绘制过程中，由于某些原因导致界面绘制的帧率下降，从而造成界面卡顿、动画不流畅等问题。以60Hz刷新率为例子，想要达到每秒60帧（即60fps）的流畅体验，每一帧需要在16.7ms内完成，如果超过16.7ms未完成渲染，就可能会出现丢帧。

本文主要是以Trace数据为切入点进行分析，相应的工具可以使用DevEco Studio内置的Frame Profiler，若开发者需要补充Trace相关知识，可以参考Trace打点信息说明等应用开发文档。

本文将主要介绍以下内容，来帮助开发者解决应用丢帧问题：

• 丢帧问题原理
• 发现丢帧问题
• 丢帧问题分析
• 常见丢帧问题
• 丢帧问题优化建议

丢帧问题原理

在了解如何定位应用丢帧问题之前，开发者需要简单了解HarmonyOS中图形渲染的流程，便于在遇到卡顿时可以分析卡顿可能出现的阶段和原因。

在HarmonyOS中，图形系统采用了统一渲染的模式，遵循着一个典型的流水线模式，以90Hz刷新率为例，每个Vsync周期是11.1ms，整个过程如下图所示。如果是60Hz，每个Vsync的周期是16.7ms；如果是120Hz，则每个Vsync的周期是8.3ms。

图1 90Hz刷新率渲染流程

在整个渲染流程中，首先是由应用侧响应消费者的屏幕点击等输入事件，由应用侧处理完成后再提交给Render Service，由Render Service协调GPU等资源处理后，再将最终的图像统一送到屏幕上进行显示。

1. 应用侧（App）处理用户的屏幕点击等输入事件，生成当前界面描述的数据结构。其中，界面描述数据包括UI元素的位置，大小，资源，UI元素的绘制指令，动效属性等。
2. Render Service（渲染服务部件）是图形栈中负责界面内容绘制的模块，其主要职责就是对接ArkUI框架，支撑ArkUI应用的界面显示，包括控件、动效等UI元素。Render Service的RenderThread线程在Vsync下触发UI绘制，绘制过程包含3个阶段：Animation动效，Draw描画和Flush提交。
3. Display是显示屏幕的抽象概念，可以是实际的物理屏也可以是虚拟屏。

其中应用侧的渲染流程如下图所示，了解ArkUI的渲染流程有助于我们定位应用侧的卡顿问题出现在哪个环节：

图2 ArkUI渲染管线结构与Frame Insight性能打点

• Animation：动画阶段，在动画过程中会修改相应的FrameNode节点触发脏区标记，在特定场景下会执行用户侧ets代码实现自定义动画；
• Events：事件处理阶段，比如手势事件处理。在手势处理过程中也会修改FrameNode节点触发脏区标记，在特定场景下会执行用户侧ets代码实现自定义事件；
• UpdateUI：自定义组件（@Component）在首次创建挂载或者状态变量变更时会标记为需要rebuild状态，在下一次Vsync过来时会执行rebuild流程，rebuild流程会执行程序UI代码，通过调用View的方法生成相应的组件树结构和属性样式修改任务。
• Measure：布局包装器执行相关的大小测算任务。
• Layout：布局包装器执行相关的布局任务。
• Render：绘制任务包装器执行相关的绘制任务，执行完成后会标记请求刷新RSNode绘制
• SendMessage：请求刷新界面绘制。

在整个处理流程中，应用侧和Render Service侧都有可能出现卡顿导致最终用户观测到丢帧的可能，我们分别将这两种情况命名为AppDeadlineMissed和RenderDeadlineMissed。一般而言，前者可能是应用逻辑处理代码不够高效导致的，后者可能是界面结构过于复杂或者GPU负载过大等原因导致的。这两个故障模型通过Frame模板都可以直观地看到。相应的故障模型如下面两幅图所示。

图3 应用卡顿导致丢帧的故障模型

图4 Render Service卡顿导致丢帧的故障模型