企业官网建设流程全解析

HarmonyOS 7 瀑布流越滑越跳：LazyCustomLayoutAlgorithm 如何保存列高又不污染测量阶段

瀑布流首屏看起来正常，向下滑动再返回时，卡片却换了列，滚动条也发生跳动。常见原因是每次测量都从零开始分配最短列，或者把可变状态直接写进 onMeasure。官方接口要求 onMeasure 和 onLayout 中不要改变状态变量，因此列高和位置必须由可重放输入计算，缓存也要有明确的失效条件。

先把边界说明白

这张表不是把官方文档换一种说法，而是把接口边界变成能检查的工程条件。适配前先确认当前应用是否命中条件，再决定是否改代码。没有命中的模块不应为了“统一写法”一起重构，命中的模块也不能只改到编译不报错。

案例一：用稳定规则生成布局快照

下面的函数接收每项高度和列数，输出每项所在列与 y 坐标。它没有读取页面状态，也不会在重复执行时得到不同结果。ArkUI 算法类可以保存这份普通对象快照，但不在测量回调里修改装饰器状态。

type Placement = { column: number; y: number }; function placeWaterfall(heights: number[], columns: number, gap: number): Placement[] { const colHeights = Array(Math.max(1, columns)).fill(0) as number[]; return heights.map((height) => { let column = 0; for (let i = 1; i < colHeights.length; i++) if (colHeights[i] < colHeights[column]) column = i; const result = { column, y: colHeights[column] }; colHeights[column] += Math.max(0, height) + gap; return result; }); } const a = placeWaterfall([100, 180, 120, 90], 2, 12); const b = placeWaterfall([100, 180, 120, 90], 2, 12); if (JSON.stringify(a) !== JSON.stringify(b)) throw new Error('布局不可重放');

这一段先验证外围决策。它的价值是让输入和结果可重复，不依赖页面当前碰巧处于什么状态；接入 ArkUI 或系统能力时，再把结果映射成实际节点、路由或接口调用。

案例二：宽度变化时只保留还能证明正确的缓存

平板分屏拖动会改变容器宽度，列数和卡片测量高度都可能改变。缓存键至少包含容器宽度档位、列数和数据版本；其中任一变化，就重新计算快照。仅用数据长度作为缓存键，会在图片比例、字体放大或排序变化后继续使用旧位置。

type LayoutKey = { widthBucket: number; columns: number; dataVersion: number }; function sameLayoutKey(a: LayoutKey, b: LayoutKey): boolean { return a.widthBucket === b.widthBucket && a.columns === b.columns && a.dataVersion === b.dataVersion; } const oldKey = { widthBucket: 800, columns: 3, dataVersion: 7 }; const newKey = { widthBucket: 600, columns: 2, dataVersion: 7 }; if (sameLayoutKey(oldKey, newKey)) throw new Error('窗口变化后错误复用缓存');

第二个案例故意覆盖与第一个不同的失败条件。真实工程还应加入快速重复操作、前后台切换、窗口尺寸变化、空数据和恢复路径，避免只验证一次成功流程。

为什么选择这种做法

完全不缓存会重复计算，按索引缓存会在排序后错位，按稳定键和布局条件缓存更可靠。上线前要用同一批不同高度数据反复滚动、插入、删除、排序和调整窗口，比较节点创建数、首帧时间与滚动位置，而不是只看静态截图。

如果团队准备封装，建议把公开接口保持在“输入事实、输出决策”的层级，不让调用方直接依赖底层节点对象。这样既方便复用，也便于写断言；需要系统能力的部分留在薄薄的适配层，升级时更容易定位。

怎样验证，哪些结论还不能提前说

先把验证分成三层。第一层是纯逻辑：输入、状态转换和边界条件可以在宿主环境运行断言；第二层是 API 26 编译：检查接口签名、系统能力和模型约束；第三层才是目标设备：检查触摸、键鼠、屏幕朗读、横竖屏、窗口缩放和前后台恢复。三层证据不能混在一句“已经跑通”里。

当前示例中的纯 TypeScript 决策函数可以独立测试，用于证明分支没有自相矛盾；涉及 ArkUI 节点、系统手势、跨设备能力和系统服务的片段，仍要使用 API 26 SDK 编译，并在支持该能力的 HarmonyOS 7 设备或云调试设备上验收。这样写不是保守，而是避免把没有发生过的真机结果当成事实。

动态页面还要观察状态变化后的第二次结果：首次进入正确，不代表弹窗关闭、列表更新或窗口缩放后仍然正确。每次状态切换都应重新核对当前节点、焦点目标、返回路径和数据快照，避免旧缓存继续影响新页面。

建议每次留下以下记录：

• DevEco Studio、SDK、targetSdkVersion 和设备系统版本。
• 触发输入、页面层级、窗口尺寸、操作方式与最终状态。
• 正常路径、空数据、快速重复操作、旋转或窗口缩放后的结果。
• 屏幕朗读、字体放大、深浅色和键盘焦点是否仍然可用。
• 性能对照使用同一批数据、同一设备状态和同一测量区间。

可以复用成什么

不要把适配判断散落在页面 Builder 中。更稳的结构是“能力探测或尺寸输入 -> 纯函数决策 -> 页面渲染 -> 设备证据”。纯函数负责输出稳定的布局或交互意图，页面只消费结果；下一次系统升级时，优先修改边界层和测试样本，不必把所有页面重新翻一遍。

发布前自查

• 文章讨论的是 HarmonyOS 7 / API 26 当前资料，不拿旧版本页面替代新接口。
• 两个案例的输入、失败现象和解决目标不同，不是同一段代码换名称。
• 代码中的常量有来源；没有来源的数值明确写成示例策略，不伪装成系统规定。
• 性能、兼容性与无障碍结论都有可重复的检查方法。
• 日志不保存账号、文件内容、设备标识和其他敏感数据。

官方资料

• LazyLayoutAlgorithm API 参考
• HarmonyOS 7 API 26 升级适配指南