【鸿蒙实战开发】列表加载ForEach和LazyForEach

HarmonyOS应用框架为容器类组件的数据加载和渲染提供了2种方式：

• 方式一，循环渲染

通过循环渲染（ForEach）从数组中获取数据，并为每个数据项创建相应的组件，可减少代码复杂度。

• 方式二，数据懒加载

通过数据懒加载（LazyForEach）从提供的数据源中按需迭代数据，并在每次迭代过程中创建相应的组件。

ForEach循环渲染的过程如下：

1. 从列表数据源一次性加载全量数据。
2. 为列表数据的每一个元素都创建对应的组件，并全部挂载在组件树上。即，ForEach遍历多少个列表元素，就创建多少个ListItem组件节点并依次挂载在List组件树根节点上。
3. 列表内容显示时，只渲染屏幕可视区内的ListItem组件，可视区外的ListItem组件滑动进入屏幕内时，因为已经完成了数据加载和组件创建挂载，直接渲染即可。

LazyForEach懒加载的原理和渲染过程如下：

1. LazyForEach会根据屏幕可视区能够容纳显示的组件数量按需加载数据。
2. 加载的数据量创建组件，挂载在组件树上，构建出一棵短小的组件树。即，屏幕可以展示多少列表项组件，就按需创建多少个ListItem组件节点挂载在List组件树根节点上。
3. 可视区只展示部分组件。当可视区外的组件需要在屏幕内显示时，需要从头完成数据加载、组件创建、挂载组件树这一过程，直至渲染到屏幕上。

使用规则

ForEach、LazyForEach必须在容器组件内使用，且仅有List、Grid、Swiper以及WaterFlow组件支持LazyForEach的数据懒加载功能，用于循环渲染具有相同布局的子组件，其他组件仍然是一次性加载所有的数据。

从测试数据可以看出：

1. 在100条数据范围内ForEach和LazyForEach差距不大，总体而言两者各项性能指标都在可接受范围内，而ForEach代码逻辑比LazyForEach简单，此场景下使用ForEach即可。
2. 据大于1000条，特别是当数据达到10000条时，ForEach在列表渲染、应用内存占用、丢帧率等各个方面都会有“指数级别”的显著劣化，滑动会出现明显的卡顿，甚至会出现应用crash等现象。
3. LazyForEach除了最后内存稍微增大以外，其列表渲染时间、丢帧率都不会出现明显变化，具有较好的性能。

缓存列表项

如果不提前缓存部分数据，当下滑到列表最底端时，再快速下滑，可能会引起“滑动白块”的现象。

LazyForEach懒加载可以通过设置cachedCount来指定缓存数量，在设置cachedCount后，除屏幕内显示的ListItem组件外，还会预先将屏幕可视区外指定数量的列表项数据缓存。

LazyForEach添加了cachedCount缓存列表项后，其渲染过程如下：

1. 首先，请求n+cachedCount条数据，并在屏幕上显示n条数据。
2. 当列表滑动，缓存列表项需要从屏幕可视区外进入可视区内时，此时只用渲染组件即可，相比不设置cachedCount提升了显示效率。
3. 当列表不断滑动，屏幕可视区外缓存的列表项数量少于cachedCount设置数量时，会触发列表项数据加载事件，继续预加载下一组缓存列表项（cachedCount个）。
4. 当上滑下滑间隔进行时，列表两个方向分别缓存cachedCo