在app中我们常会看到如下图所示类似的列表界面，有时候需求会让我们在一启动的时候就需要对数据量很大的列表进行界面数据刷新，还有我们经常会反复滑动列表界面去观看我们需要的内容，总之有很多类似的场景，那么如果是你的话在数据量很大的情况下你会怎么去处理或者说优化由于数据量大而导致界面卡顿的现象呢？下述的总结来源于官网网站学习之后的一个总结。

一、长列表优化概述针对长列表加载这一场景，对于列表渲染的时间、页面滑动的帧率、应用内存的占用等几个方面带来优化，提升性能和用户体验的手段目前已知的有如下4种：

提供列表数据按需加载能力，解决一次性加载长列表数据耗时长、占用过多资源的问题，可以提升页面响应速度。

提供屏幕可视区域外列表项长度的自定义调节能力，配合懒加载设置可缓存列表项参数，通过预加载数据提升列表滑动体验。

提供可复用组件对象的缓存资源池，通过重复使用已经创建过并缓存的组件对象，降低相同组件短时间内频繁创建和销毁的开销，提升组件渲染效率。

使用扁平化布局方案，减少视图嵌套层级和组件数，避免过度绘制，提升页面渲染效率。

二、优化的三个相关的关键指标以上图为例，对比分析如下三个关键指标：

表示应用生成具有完整内容的第一帧所用的时间，包括在第一帧之后异步加载的内容。

表示一个时间周期内的丢帧比率，是指一个时间周期内有问题的帧比例。HarmonyOS系统要求每一帧都要在11.1ms (90Hz刷新率)内绘制完成，如果页面没有在11.1ms内完成这一帧的绘制，就会出现丢帧。部分丢帧一般用户肉眼是感知不到的，只有出现连续丢帧用户才有明显感知。

一个进程所占用的私有内存，即该进程独占的内存。它反映了运行一个特定进程真实的边际成本(增量成本)。

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

该渲染方式适用于小数据量渲染时候使用。

ForEach(
arr: Array,
itemGenerator: (item: Array, index?: number) => void,
keyGenerator?: (item: Array, index?: number): string => string
)

该渲染方式适用于大数据量渲染时候使用。

LazyForEach(
datasource: IDataSource,
itemGenerator: (item: any) => void,
keyGenerator?: (item: any): string => string
)

说明：LazyForEach的数据源首先需要开发者实现IDataSource接口，具体实现可参考API)

四、数据加载流程分析

如果列表数据较少，数据一次性全量加载不是性能瓶颈时，可以直接使用ForEach，ForEach会从列表数据源一次性加载全量数据。

说明：官方在介绍这里的时候提到了HarmonyOS系统中有三棵树的概念，这三棵树分别为：数据源、组件树、渲染界面。

LazyForEach实现了按需加载，针对列表数据量大、列表组件复杂的场景，减少了页面首次启动时一次性加载数据的时间消耗，减少了内存峰值。

总结：分析到这里其实大家已经很明确了，具体还是得看你实际的需求，如果需求就只有简单的几条数据那么使用ForEach，全量加载可能会更高效更好一些，如果需求是有大量的数据那么使用LazyForEach，按需加载可能更高效更优雅一些。

五、性能对比官方也针对不同数据量下ForEach和LazyForEach性能进行了对比【性能对比】。对比的场景也很简单、很直观，本地模拟了 10、100、1000、10000条数据，分别使用ForEach、LazyForEach来测试关闭和开启懒加载情况下的完全显示所用时间、列表挂载时间、独占内存、丢帧率。得到的数据如下所示：