#2023盲盒+码# OpenHarmony应用懒加载LazyForEach学习 原创

【本文正在参加 2023「盲盒」+码有奖征文活动】 https://ost.51cto.com/posts/25284

• 摘要：列表场景在应用程序中很常见，列表性能非常影响用户体验。本文会介绍开发OpenHarmony列表页面时需要考虑的性能提升方法。

• 关键字：OpenHarmony HarmonyOS 鸿蒙 懒加载 列表滑动性能 LazyForEach cachedCount IDataSource

背景与问题

在信息爆炸时代，用户需要浏览和处理大量的信息，例如，在电商平台上，用户可能会浏览一个包含多个商品的长列表，以便进行购物决策。在社交媒体平台上，用户可能会浏览一个包含多个帖子或消息的长列表，以便了解最新的动态。列表是一种有效的信息组织方式，可以将杂乱的信息整理成有规律、易于理解和操作的形式。列表可以按照一定的排序规则（如时间顺序、字母顺序等）展示信息，使得用户可以更加方便地查找和获取所需的信息。应用程序中常见的列表场景有新闻列表，通讯软件消息列表，联系人列表，排行榜，各种账单等。

随着信息数据的累积，列表数据会达到上万条，一些热门帖子的回复量甚至突破了800万。长列表数据会导致页面渲染卡顿，甚至长时间无响应。在滑动长列表时，帧率降低，滑动滞后。这些问题会给用户带来糟糕的体验，在应用开发时，解决长列表数据带来的性能问题给应用开发带来很大的挑战。

解决思路

在开发OpenHarmony应用时，优化长列表性能的方向主要包含：提升页面的响应速度和滑动时提升帧率。针对这些问题，主要有如下几个技术手段：

• 通过延迟加载技术，对列表数据不进行一次性加载，实现按需加载
• 通过长列表分页缓存，屏幕外数据预热缓存，进入屏幕后再渲染，进一步提升渲染效率
• 通过可复用组件池，减少每次重新创建组件的时间
• 通过减少需要被渲染元素的数量，缩短渲染CPU耗时和内存开销

本文，先记录学习下懒加载LazyForEach。因水平有限，如有失误，请随时指教。

懒加载

OpenHarmony应用框架对数组类型的数据执行循环渲染，提供了2个接口，一个是ForEach循环渲染接口，一个是LazyForEach懒加载渲染接口。使用ForEach循环列表数据时，会一次加载全量数据，会为列表数据的所有元素都创建组件，挂载在组件树上，也就是说ForEach遍历多少个列表元素，就有多少个LiteItem组件节点挂载在List父组件节点上。屏幕滑动时，屏幕外的元素渲染到屏幕内，不需要再创建节点。上滑下滑展示屏幕外的组件时，不会渲染、销毁组件；列表变化时，重新渲染组件。

对于节点数特别多的场景下，使用ForEach创建耗时长，资源开销大。一次性加载所有的列表数据，一方面会导致页面启动时间过长，影响用户体验，另一方面也会增加服务器的压力和流量，加重系统负担。LazyForEach懒加载在需要数据时才加载数据。数据懒加载可以从数据源中按需迭代加载数据并创建相应组件。如图：

使用LazyForEach懒加载时，界面展示多少列表项组件，就按需创建渲染多少组件。上滑下滑时，要出现在屏幕上的组件才会创建渲染；列表数据变化时，出现在屏幕上的才会创建渲染。默认缓存数量cachedCount为0。对于列表数据获取耗时长，列表组件复杂的场景，LazyForEach懒加载可以显著提升性能。

参考资料

[1] Sample聊天实例应用

[2] LazyForEach数据懒加载

[3] List cachedCount属性

[4] 组件复用场景

[5] 性能提升的推荐方法

[6] 挂载卸载事件