在 ArkUI 中，build() 函数的执行频率与最终的渲染性能并不直接挂钩。
简单直接的回答是：build() 可能会被多次触发，但 ArkUI 绝不会全量重建真实的底层渲染节点。
1. build() 执行 全量重绘
当状态（如 @State）改变时，ArkUI 的执行逻辑分为“逻辑层”和“渲染层”：
- 逻辑层（
build()执行）： 框架会重新运行build()函数中的逻辑代码。这确实会有一定的 CPU 开销，但它只是为了生成一套新的声明式描述。 - 渲染层（增量更新）： 框架会将新生成的描述与旧的描述进行对比。只有发生变化的属性（如
Text的内容、Image的路径）才会通过后端接口（C++ 层）同步到真实的渲染树上。
2. 核心机制：增量更新与局部 Diff
ArkUI 并不是像传统的浏览器那样进行全量 DOM Diff，它采用的是指令级增量更新：
- 属性级对比： 如果你修改了
this.color，框架在build()运行后发现只有FontColor属性变了。底层 C++ 节点只会执行一个类似updateColor()的指令，而不会销毁并重建整个Text组件。 - 结构级稳定： 除非你使用了
if/else导致的条件分支切换，否则 UI 的树形结构在内存中是保持稳定的。
3. 什么时候 build() 频繁执行会导致性能差？
虽然底层是增量更新，但如果 build() 执行太频繁，以下三点会拖累性能：
A. 在 build() 中编写复杂逻辑
这是最常见的坑。 build() 应当只包含 UI 描述。
- 错误示范： 在
Text()里面调用一个涉及循环排序、日期格式化或大量计算的函数。 - 后果： 每次状态微调，CPU 都要重新跑一遍这些沉重的计算，导致掉帧。
B. 状态关联范围过大
如果你在父组件定义了一个 @State，并在 build() 里传给了 20 个子组件。
- 后果： 状态一变，20 个子组件的
build()都会触发执行。虽然最终可能只有 1 个组件有属性变化，但另外 19 个组件的“逻辑检查”开销累加起来也是很可观的。
C. 闭包与匿名函数
在 build() 中频繁创建匿名函数（如 onClick(() => { ... })）。
- 后果： 每次
build都会生成新的函数实例，这虽然不影响渲染，但会增加 JS 引擎的内存分配和 GC（垃圾回收）压力。
4. ArkUI 的“伪全量更新”：ForEach vs LazyForEach
ForEach（全量预加载）： 当数据源变动时，ForEach倾向于重新执行内部所有项的build。如果列表有 100 项，改一个 ID 可能导致 100 项都触发 Diff 检查，性能较差。LazyForEach（按需增量）： 它只对屏幕可见的项进行 Key 比对。只有 Key 发生变化的项才会触发build。这是处理海量数据时性能卓越的根本原因。
总结：性能优化清单
| 维度 | 优化建议 |
|---|---|
| 函数逻辑 | 禁止在 build() 内进行耗时计算，数据应提前处理好。 |
| 组件粒度 | 拆分组件。将高频变化的状态封装在小的自定义组件内部，减小 build 影响范围。 |
| 条件渲染 | 尽量使用 visibility 隐藏组件，而非 if/else 物理移除，减少结构重建。 |
| 列表性能 | 超过 20 条数据，必须使用 LazyForEach 并提供稳定的 keyGenerator。 |
一句话总结： build() 的执行是“剧本更新”，而渲染层的更新是“局部微调”。只要你不在剧本里写复杂的微积分计算，频繁更新剧本并不会让剧场（GPU）崩溃。
