鸿蒙 ArkTS 长列表性能优化：LazyForEach 与组件复用的实战取舍

一、长列表为什么会卡

在鸿蒙应用里，消息流、商品列表、待办清单几乎都离不开长列表。列表一长就容易出现两个问题：首屏打开慢，上下滑动掉帧。根源往往不在数据量本身，而在渲染方式：页面一次性创建了成百上千个列表项组件，每个组件都要执行构建、布局和绘制，内存和主线程都被占满。优化长列表，核心思路只有一句话：只渲染看得见的部分，并把滑出屏幕的组件复用起来。

二、LazyForEach：只创建看得见的项

ArkTS 提供了 LazyForEach，专门用于长列表的懒加载。它只为当前可视区域及少量缓冲区创建组件，滚动到哪里，才创建到哪里；滑出屏幕的组件会被销毁或回收。

List() {
  LazyForEach(this.dataSource, (item: ItemData) => {
    ListItem() {
      RowItem({ data: item })
    }
  }, (item: ItemData) => item.id.toString())
}

用好 LazyForEach 有三个要点。第一，数据源要实现 IDataSource 接口，数据增删改要通过接口通知框架，框架才知道刷新哪一项，而不是整列表重建。第二，键值生成器必须返回稳定唯一的键，键一变，组件就会被误认为是新项，复用和缓存都会失效。第三，列表项高度尽量固定，避免滚动位置反复修正。

三、ForEach 与 LazyForEach 怎么选

两者不是谁替代谁，而是分工不同。ForEach 会一次性创建全部子组件，写法简单，适合选项少、数量固定的短列表，例如设置页的十几个开关。LazyForEach 按需创建，适合数据量大、会滚动加载的长列表，代价是需要配套的数据源和键管理。

常见误区是几十条数据也硬上 LazyForEach：全量创建的开销很小，懒加载反而多了数据源维护成本；反过来，几百上千条数据还用 ForEach，首屏构建时间会直线上升。判断标准就是列表长度和是否滚动加载。

四、组件复用：滑出去的项接着用

只做懒加载还不够。用户快速滑动时，不断创建和销毁组件同样会掉帧。这时要用到组件复用：给列表项组件加上 @Reusable 装饰器，框架会把滑出屏幕的组件放进复用池，滚动回来时直接复用，只更新数据，不再重新创建。

复用池按类型匹配，结构要基本一致。还要注意：不要在可复用组件里保存与数据无关的临时状态，例如展开收起，否则复用后会把旧状态带给新数据；正确做法是把状态放到数据源里，或在 aboutToReuse 中按新数据重新初始化。

五、实战清单：按顺序做，别一次全改

1. 先换 LazyForEach，配稳定键和 IDataSource 数据源，验证滑动是否顺畅。
2. 再把列表项拆成独立小组件，加上 @Reusable，清理组件内的临时状态。
3. 把状态下沉到子组件，避免一次点赞或勾选就触发整列表刷新。
4. 图片按需加载、避免在 build 方法里做格式化、排序等重计算。
5. 最后在真机上验证快速滑动、来回滚动、增删数据，确认没有闪烁和错位。

六、结语

长列表优化没有银弹：LazyForEach 解决创建时机，组件复用解决创建成本，两者配合才能同时改善首屏时间和滑动帧率。先测出瓶颈在创建还是刷新，再决定先改哪一处，比一次性重构更稳妥。