列表是应用开发中最常见的一类开发场景，应用程序中常见的列表场景有新闻列表、购物车列表、各类排行榜等。随着信息数据的累积，特别是一些新闻应用、购物应用、聊天应用，列表数据往往会达到上万条，针对这类大量数据加载的长列表应用，如何对长列表的性能进行优化是非常重要的。一个正确、高性能的长列表应用能明显降低列表渲染时间、提升页面的滑动帧率、降低应用内存占用，大幅提升用户体验。
鸿蒙当中常用的列表主要有List、Grid、Swiper以及WaterFlow等。
ForEach循环加载数据
通过循环渲染（ForEach）从数组中获取数据，并为每个数据项创建相应的组件，可减少代码复杂度。
ForEach(
arr: any[],
itemGenerator: (item: any, index?: number) => void,
keyGenerator?: (item: any, index?: number) => string
)
ForEach循环渲染的过程：
- 从列表数据源一次性加载全量数据。
- 为列表数据的每一个元素都创建对应的组件，并全部挂载在组件树上。即，ForEach遍历多少个列表元素，就创建多少个ListItem组件节点并依次挂载在List组件树根节点上。
- 列表内容显示时，只渲染屏幕可视区内的ListItem组件，可视区外的ListItem组件滑动进入屏幕内时，因为已经完成了数据加载和组件创建挂载，直接渲染即可。
LazyForEach懒加载加载数据
通过数据懒加载（LazyForEach）从提供的数据源中按需迭代数据，并在每次迭代过程中创建相应的组件。
LazyForEach(
dataSource: IDataSource,
itemGenerator: (item: any) => void,
keyGenerator?: (item: any) => string
): void
interface IDataSource {
totalCount(): number;
getData(index: number): any;
registerDataChangeListener(listener: DataChangeListener): void;
unregisterDataChangeListener(listener: DataChangeListener): void;
}
interface DataChangeListener {
onDataReloaded(): void;
onDataAdd(index: number): void;
onDataMove(from: number, to: number): void;
onDataDelete(index: number): void;
onDataChange(index: number): void;
}
LazyForEach懒加载的原理和渲染过程：
- LazyForEach会根据屏幕可视区能够容纳显示的组件数量按需加载数据。
- 根据加载的数据量创建组件，挂载在组件树上，构建出一棵短小的组件树。即，屏幕可以展示多少列表项组件，就按需创建多少个ListItem组件节点挂载在List组件树根节点上。
- 屏幕可视区只展示部分组件。当可视区外的组件需要在屏幕内显示时，需要从头完成数据加载、组件创建、挂载组件树这一过程，直至渲染到屏幕上。
两者对比：
ForEach：列表数据较少，数据一次性全量加载不是性能瓶颈时。ForEach相对LazyForEach，代码简单很多。
LazyForEach：列表数据较长，一次性加载所有的列表数据创建、渲染页面产生性能瓶颈时。
缓存列表
LazyForEach懒加载可以通过设置cachedCount来指定缓存数量，在设置cachedCount后，除屏幕内显示的ListItem组件外，还会预先将屏幕可视区外指定数量的列表项数据缓存。这样当一个屏幕数据加载完成后，再次向下滑动时，会先加载上一次请求的数据，加载完成后，再加载本次请求的数据。LazyForEach添加了cachedCount缓存列表项后，其渲染过程：
- 首先，请求n+cachedCount条数据，并在屏幕上显示n条数据。
- 当列表滑动，缓存列表项需要从屏幕可视区外进入可视区内时，此时只用渲染组件即可，相比不设置cachedCount提升了显示效率。
- 当列表不断滑动，屏幕可视区外缓存的列表项数量少于cachedCount设置数量时，会触发列表项数据加载事件，继续预加载下一组缓存列表项（cachedCount个）。
- 当上滑下滑间隔进行时，列表两个方向分别缓存cachedCount条数据。
- 如果不显式设置cachedCount，cachedCount默认为1。
10000条数据量下不同cachedCount对列表滑动帧率的影响，如下图：
一般而言，缓存的cachedCount=n/2（n为一屏显示的列表数）的时候，效果较好。在实际开发中也要根据实际场景合理去设置缓存数量，例如列表项中需要显示网络数据，而网络数据加载较慢，为了提升列表信息的浏览效率和浏览体验，可以适当的多设置一些缓存数量（cachedCount大于n/2）；如果列表中需要加载一些大图或者视频等，这些数据占用的内存较大，为了减少内存占用，需要适当减少缓存数量的设置（cachedCount小于n/2）。
动态预加载
LazyForEach懒加载可以通过使用Prefetcher来预取和预渲染数据。在使用Prefetcher后，除屏幕内显示的ListItem组件外，还会预先将屏幕可视区外的部分列表项数据进行预渲染和预取。这样当列表向下滑动时，会先显示预渲染组件，屏幕可视区外会动态调整预取范围。预取逻辑在Prefetcher的BasicPrefetcher类中实现，BasicPrefetcher支持预取和预渲染（图像解码、添加到组件树等）过程分离、自适应调整预获取范围、优先加载可视区域、以及取消不必要任务（快速滚动列表的场景下，智能取消不必要任务），其渲染过程如下：
- 首先，请求n条数据，并在屏幕上显示m条数据。
- 当列表滑动，缓存列表项需要从屏幕可视区外进入可视区内时，此时显示预渲染组件，屏幕可视区外会动态调整预取范围，相比仅设置cachedCount提升了显示效率。
- 当列表不断滑动，屏幕可视区外实时更新列表项、更新预取数据和预渲染数据。
组件复用
HarmonyOS应用框架提供了组件复用能力，可复用组件从组件树上移除时，会进入到一个回收缓存区。后续创建新组件节点时，会复用缓存区中的节点，节约组件重新创建的时间。尤其在列表等场景下，其自定义子组件具有相同的组件布局结构，列表更新时仅有状态变量等数据差异。通过组件复用可以提高列表页面的加载速度和响应速度。
组件复用机制如下：
- 标记为@Reusable的组件从组件树上被移除时，组件和其对应的JSView对象都会被放入复用缓存中。
- 当列表滑动新的ListItem将要被显示，List组件树上需要新建节点时，将会从复用缓存中查找可复用的组件节点。
- 找到可复用节点并对其进行更新后添加到组件树中。从而节省了组件节点和JSView对象的创建时间。
组件复用生效的条件是：
- 自定义组件被@Reusable装饰器修饰，即表示其具备组件复用的能力；
- 在一个自定义父组件下创建出来的具备组件复用能力的自定义子组件，在可复用自定义组件从组件树上移除之后，会被加入到其自定义父组件的可复用节点缓存中；
- 在一个自定义父组件下创建可复用的子组件时，若其父自定义组件的可复用节点缓存中有对应类型的可复用子组件，会通过更新可复用子组件的方式，快速创建可复用子组件；
-
ForEach循环渲染会一次性加载全量数据，因此不支持组件复用。
image.png
布局优化
列表不同于其他布局，包含了大量重复循环的ListItem，所以对每一个ListItem的布局优化格外重要。错误的布局方式可能会导致组件树和嵌套层数过多，在创建和布局绘制阶段产生较大的性能开销，导致界面卡顿。合理使用布局，减少嵌套层数，能提高布局效率。
布局优化前后的层级变化：
总结
针对长列表加载这一场景，本文将介绍如下5种优化手段，通过这些优化手段的单个使用或组合使用，可以对列表渲染时间、页面滑动帧率、应用内存占用等方面带来优化，提升性能和用户体验：
- 懒加载：提供列表数据按需加载能力，解决一次性加载长列表数据耗时长、占用过多资源的问题，可以提升页面响应速度。
- 缓存列表项：提供屏幕可视区域外列表项长度的自定义调节能力，配合懒加载设置可缓存列表项参数，通过预加载数据提升列表滑动体验。
- 动态预加载：根据历史任务加载耗时情况，动态调整屏幕可视区域外数据预取数量，配合懒加载设置，可在列表不断滑动时，屏幕可视区外实时更新列表数据，通过预取和预渲染数据提升列表滑动体验。
- 组件复用：提供可复用组件对象的缓存资源池，通过重复使用已经创建过并缓存的组件对象，降低相同组件短时间内频繁创建和销毁的开销，提升组件渲染效率。
- 布局优化：使用扁平化布局方案，减少视图嵌套层级和组件数，避免过度绘制，提升页面渲染效率。
