界面卡顿、掉帧，很多时候是渲染范围没控制好。本文基于官方文档，把控制 UI 渲染范围的四种优化梳理清楚：合理控制元素显示与隐藏、懒加载、组件复用、分帧渲染。

一、目标

在应用开发中，控制 UI 渲染范围，防止界面卡顿或掉帧。

二、合理控制元素显示与隐藏

控制元素显示与隐藏是一种常见场景，使用 Visibility.None、if 条件判断等都能够实现该效果。

两种方式的区别

方式	控制阶段	说明
if 条件判断	控制的是组件的创建、布局阶段	条件不满足时，组件不创建
visibility 属性	控制的是元素在布局阶段是否参与布局渲染	组件已创建，但可能不参与布局渲染

三、懒加载

懒加载是一种延迟加载的技术，它是在需要的时候才加载数据或资源，并在每次迭代过程中创建相应的组件，而不是一次性将所有内容都加载出来。

缓存数量配置

懒加载可以通过设置 cachedCount 来指定缓存数量：

除屏幕内显示的 Item 组件外，还会预先将屏幕可视区外指定数量的数据缓存。

典型场景

• 长列表加载

四、组件复用

组件复用通过重用已有组件节点减少创建开销，显著提升 UI 线程响应速度。

适用范围

组件复用针对的是自定义组件，只要发生了相同自定义组件销毁和再创建的场景，都可以使用组件复用。

场景

场景
长列表加载丢帧优化
瀑布流加载丢帧优化
Swiper 组件加载丢帧优化

这些场景会出现大量重复布局的创建，使用组件复用可以大幅度降低因频繁创建与销毁组件带来的性能损耗。

五、分帧渲染

在应用开发中，页面内列表结构复杂，每个列表项包含的组件较多，就会导致：

• 嵌套层级较深

• 组件负载加重

• 绘制耗时增长

在这种情况下，转场或者列表滑动的时候列表项就会一次性加载大量的数据。

解决方案

采用分帧渲染，将本来一帧内加载的数据分成多帧加载。

提醒

分帧渲染需要开发者计算每帧中加载多少数据，操作复杂，因此在必要的情况下才推荐使用。

说明：

1. if 和 visibility 不是一回事：

   • if：控制组件创建阶段，条件不满足组件根本不创建

   • visibility：组件已创建，控制的是布局阶段是否参与渲染

   • 用错方式会引发性能问题，比如频繁切换 if 条件会导致组件反复创建销毁。

2. 懒加载的核心是"按需" ：不是一次性把所有内容加载出来，而是需要时才加载，配合 cachedCount 预缓存屏幕外的数据，滑动时更流畅。

3. 组件复用针对"自定义组件" ：只要出现相同自定义组件销毁再创建的场景，就可以用组件复用。长列表、瀑布流、Swiper 是典型场景。

4. 组件复用的益处：重用已有组件节点，减少创建开销，直接提升 UI 线程响应速度，频繁创建销毁的场景收益尤其明显。

5. 懒加载和组件复用经常配合使用：长列表场景下，懒加载控制加载时机，组件复用控制节点复用，两者结合效果最好。