鸿蒙原生APP性能优化之高负载场景下分帧渲染

往期推文全新看点

• 鸿蒙（HarmonyOS）北向开发知识点记录~
• 鸿蒙（OpenHarmony）南向开发保姆级知识点汇总~
• 鸿蒙应用开发与鸿蒙系统开发哪个更有前景？
• 嵌入式开发适不适合做鸿蒙南向开发？看完这篇你就了解了~
• 对于大前端开发来说，转鸿蒙开发究竟是福还是祸？
• 鸿蒙岗位需求突增！移动端、PC端、IoT到底该怎么选？
• 记录一场鸿蒙开发岗位面试经历~
• 持续更新中……

简介

在应用开发中，页面内列表结构复杂，每个列表项包含的组件较多，就会导致嵌套层级较深，从而引起组件负载加重，绘制耗时增长。

在这种情况下，转场或者列表滑动的时候列表项就会一次性加载大量的数据，此时可以采用分帧渲染，将本来一帧内加载的数据分成多帧加载，但是分帧渲染需要开发者计算每帧中加载多少数据，操作复杂，因此在必要的情况下才推荐使用。

实现原理

原理说明

对于一些单帧内组件负载重、加载数据多和绘制耗时长的问题场景。开发者可以根据实际的业务逻辑、应用页面布局和数据量，提前计算规划出需要通过多少帧完成加载以及每帧具体加载的数据。应用页面实际加载绘制的时候，结合页面的布局，使用帧回调监听修改状态变量或补充数据到数据结构等方式，对每一帧需要处理的渲染数据进行计算和设置，保证每一帧内只处理提前设置好的数据。因为已经设置了帧回调监听，具体的页面组件加载数据时，只需要通过状态变量或者数据结构，即可实现按帧分批加载数据。这样就达到了原本在一帧中加载的数据分到多帧加载的目的，有效减少了首帧的耗时，避免首帧卡顿现象的出现。如下图所示，将一帧数据拆分到三帧示例：

具体实现

在高负载场景下使用分帧渲染的关键操作是把数据拆分到每一帧中加载，但这个过程中加载新的数据时可能会将已有数据再次绘制，因此需要搭配合理的页面布局来避免重绘。可以通过if或ForEach两种方法来实现布局，两种方法的更新机制如下：

• if更新机制 是根据状态判断条件，如果分支没有变化，不会对条件渲染语句进行更新。
• ForEach非首次渲染 会检查新生成的键值是否在上次渲染中已经存在。如果键值不存在，则会创建一个新的组件；如果键值存在，则不会创建新的组件，而是直接渲染该键值所对应的组件。

因此在分帧逐步加载数据时使用上述两种方法不会引起重绘。并且在页面布局时可以给分帧渲染的外部容器组件设置宽高，这样组件本身不会触发重新进行Measure的过程，对组件的宽高不会重新测算，避免因外部容器大小改变引起重绘。

保证页面不会重绘后，在实际开发过程中为了逐步增加页面数据，可以使用ArkTS中提供的displaySync（可变帧率） API接口，通过Vsync信号控制数据刷新的时机，来实现绘制内容帧率的控制。先通过页面UI中aboutToAppear(