HarmonyOS掌上记账APP开发实践第22篇：Scroll + List 虚拟列表 — 长列表性能优化全攻略

Scroll List 虚拟列表 — 长列表性能优化全攻略一、引言在记账应用中账单列表是最核心的数据展示场景可能包含数百甚至上千条交易记录。如果一次性渲染所有列表项将导致严重的内存占用和帧率下降。鸿蒙系统提供了 Scroll List 组合方案结合 ForEach / LazyForEach 实现虚拟列表渲染只渲染可视区域内的列表项大幅提升长列表性能。MoneyTrack 在资产详情页和首页账单流中广泛运用了这套方案。二、核心知识点2.1 Scroll 容器Scroll 是可滚动容器组件常用属性如下scrollable控制滚动方向取值ScrollDirection.Vertical垂直或ScrollDirection.Horizontal水平默认垂直scrollBar滚动条显示模式可选BarState.Auto自动显隐、BarState.Always常驻、BarState.Off隐藏edgeEffect边缘效果EdgeEffect.Spring弹性回弹、EdgeEffect.Fade淡出渐变、EdgeEffect.None无效果enableScrollInteraction布尔值控制是否允许用户手势滚动设为false可禁用滚动交互Scroll 可以包裹任意内容但不具备虚拟化能力适合内容长度可控如几十个组件的场景。当内容数据量较大时应优先使用 List。2.2 List ForEach / LazyForEachList 是专门为列表场景优化的组件支持虚拟列表机制。ForEach 与 LazyForEach 的对比如下对比维度ForEachLazyForEach渲染策略全量参与布局计算渲染可视项按需创建/销毁组件实例内存占用中等几十条可接受极低适合几百上千条适用场景数据量 ≤ 50 条数据量 50 条以上key 要求必须提供稳定唯一 key必须提供稳定唯一 key数据变更全量刷新按索引增量更新LazyForEach 需要实现 IDataSource 接口classTransactionDataSourceimplementsIDataSource{privatedataArray:TransactionItem[][];totalCount():number{returnthis.dataArray.length;}getData(index:number):TransactionItem{returnthis.dataArray[index];}registerDataChangeListener(listener:DataChangeListener):void{}unregisterDataChangeListener(listener:DataChangeListener):void{}}// 使用 LazyForEachList({space:8,scroller:this.listScroller}){LazyForEach(this.dataSource,(item:TransactionItem){ListItem(){TransactionCard({transaction:item})}},(item:TransactionItem)item.id)}2.3 List 辅助属性除了基础滚动List 还提供以下实用属性stickyHeader设置分组粘性标题取值StickyStyle.Header吸顶或StickyStyle.None不吸顶。在按日期分组的账单列表中非常实用用户滚动时始终能看到当前日期分组divider列表项分割线配置颜色和左右边距例如.divider({ strokeWidth: 1px, color: #E8E8E8, startMargin: 16, endMargin: 16 })cachedCount设置列表项缓存数量在可视区域外额外预创建 N 个组件提升快速滚动时的体验建议设为 1~3List({space:8,scroller:this.listScroller}){ForEach(this.viewModel.transactions,(tx:TransactionItem){ListItem(){TransactionCard({transaction:tx})}},(tx:TransactionItem)tx.id)}.edgeEffect(EdgeEffect.Spring).divider({strokeWidth:1px,color:#E8E8E8}).stickyHeader(StickyStyle.Header).cachedCount(2)三、虚拟列表渲染原理是否数据源 DataSource虚拟列表引擎判断是否在可视区域创建/复用 ListItem 组件不创建 / 销毁回收渲染到屏幕用户滚动触发新位置虚拟列表的核心思想是只渲染用户看得到的部分。当用户快速滚动时滑出屏幕的列表项被回收新进入区域的列表项被创建或复用从而将 DOM 节点数量控制在可视高度对应的范围内。四、性能监控验证虚拟列表是否生效使用 DevEco Studio 的 Profiler 工具可以监控列表性能查看组件树节点数打开 DevTools Elements 面板滚动列表时观察节点数是否保持稳定。若节点数随滚动持续增长说明虚拟化未生效分析内存占用Profiler Memory观察滚动过程中内存是否平稳。若内存持续上涨可能存在列表项未被正确回收帧率检测Profiler Frame确保滚动帧率稳定在 60fps。若出现掉帧可适当增大cachedCount减少快速滚动时的白屏五、最佳实践ListItem 组件化将列表项封装为独立组件如TransactionCard避免列表项内部状态变化触发整个列表刷新稳定 key 值务必为 ForEach/LazyForEach 提供唯一且稳定的 key 函数避免使用索引作为 key否则会导致渲染异常合理配置缓存大小cachedCount并非越大越好过大会增加内存占用建议设为 1~3兼顾快速滚动体验与内存效率选择正确的渲染方式数据量超过 50 条时优先使用 LazyForEach对于频繁增删操作的列表LazyForEach 的增量更新优势更明显六、总结Scroll List ForEach/LazyForEach 构成了鸿蒙长列表性能优化的核心方案。Scroll 作为通用滚动容器适合内容可控的场景List 结合虚拟列表机制专门针对大量列表数据优化。ForEach 适用于中等数据量LazyForEach 更适合大数据量场景其 IDataSource 接口提供了灵活的数据管理能力。在实际开发中配合 stickyHeader、divider 等辅助属性和 cachedCount 缓存优化可以构建出流畅、高性能的长列表页面。七、参考文档列表组件性能优化指南List 组件 API 参考LazyForEach 使用说明