HarmonyOS NEXT ArkTS 布局测量优化实战——避免重复 onMeasure，提升布局性能
一、引言：布局测量——性能优化的隐性战场
1.1 从帧率到测量的性能视角
在移动端应用性能优化中，开发者通常关注三个层面：网络请求速度、图片加载效率、列表滚动帧率。但在这三者之下，有一个更基础的性能因素往往被忽视——布局测量的效率。布局测量是 UI 框架执行布局算法的基础步骤，决定了每个组件在屏幕上的位置和大小。在 ArkUI 中，布局引擎执行两阶段遍历：测量阶段父组件向子组件传递尺寸约束，子组件计算并返回期望尺寸；布局阶段父组件根据测量结果为子组件分配最终位置和尺寸。但在实际场景中有一个关键问题：当子组件尺寸不确定时，父组件需要多次调用 measure 才能确定最终尺寸，这就是重复测量。每次重复测量都意味着额外的 CPU 计算。在 60fps 的渲染管线中，每帧只有 16.6ms 的预算，布局测量每多消耗 1ms，留给渲染和动画的时间就少 1ms。
1.2 ArkUI 布局测量算法
ArkUI 布局引擎采用两阶段算法。Measure 阶段从根节点自上而下遍历，父组件调用子组件测量方法并传入尺寸约束，子组件计算期望尺寸返回。Layout 阶段再次遍历，父组件为子组件分配最终尺寸和位置。当子组件尺寸不确定时——典型场景是百分比宽度加自适应高度——父组件必须先知道自己的宽度才能计算百分比，但父组件宽度又取决于子组件总宽度，形成循环依赖。引擎先假设初始值测量子组件，根据结果调整后再重测，直到尺寸收敛。这就是重复测量的本质。
1.3 本文实践内容
本文以 LayoutMeasureOptimizationDemo（434 行）为例，通过 3 组对比剖析两阶段布局算法、多 pass 测量、constraintSize 优化、布局扁平化、固定尺寸优化。项目基于 HarmonyOS NEXT 6.1.1 API 24。
二、Demo 整体架构
Demo 通过三组并排对比展示测量优化效果。演示一展示不确定尺寸与明确约束对比，演示二展示 constraintSize 作用，演示三展示嵌套深度影响。为观察组件重建行为引入全局序列号机制。
三、演示一：不确定尺寸 vs 明确约束
BadMeasureBox 使用外层 Column 自适应高度、内层 Row 100% 宽度、左右两列各 45%。框架在第 1 pass 假设父容器宽度为屏幕宽度，测量两列高度后发现不一致触发第 2 pass。GoodMeasureBox 使用固定宽高 140x60 和 constraintSize，一次通过。测量次数从多次减少到 1-2 次。
四、演示二和演示三
constraintSize 无约束时框架不知文本换行位置，需多次重测，有约束时一次确定。5 层嵌套需 10 次测量，2 层扁平需 2 次，差距 5 倍。
五、最佳实践
优先固定尺寸、为文本设 constraintSize、嵌套控制在 5 层以内、审慎用 layoutWeight、避免 wrapContent 加百分比混合。
六、总结
本文通过 434 行代码的 3 组对比分析了布局测量优化的核心维度。布局测量优化与状态粒度优化、嵌套深度优化构成 ArkUI 性能优化三大支柱。
和CAS强弱语义学习记录)
