ArkUI 渲染架构与性能优化：状态粒度决定帧率

鸿蒙应用开发进入平稳期后，性能优化的重点从「能不能跑」转向「跑得顺不顺」。ArkUI 作为声明式 UI 框架，性能模型与 Compose、SwiftUI 同源，但有自己的实现细节。理解它的渲染流水线与状态最小化更新机制，是做好鸿蒙性能的前提。

一、ArkUI 渲染流水线：一次状态变更会发生什么

声明式 UI 的核心承诺是「状态变，UI 自动更新」，但这个自动化是有成本的。ArkUI 的一次更新链路：

• 状态感知：@State/@Prop/@Link 等装饰器建立状态与组件的依赖关系；
• 最小化重渲染：只有依赖了被改状态的组件会重新执行 build，粒度是组件级；
• 布局与绘制：被标记的节点重新布局，脏区进入绘制阶段；
• 渲染合成：最终由渲染服务合成上屏，目标是 120Hz 下每帧 8.3ms 内完成。

优化的全部思路都藏在这条链路里：减少进入「重新 build」的组件数量，减少布局层级，避免在 build 里做昂贵计算。官方性能指导见华为开发者文档性能优化章节。

二、状态管理：最常见的三个性能反模式

反模式一：大对象整体当状态。把整个列表数据放进一个 @State 数组，任何一项变化都触发依赖该数组的所有组件刷新。正确做法是把状态拆到「恰好需要的粒度」——每一项自己是子组件，只依赖自己那份数据。

反模式二：build 里做同步重活。build 应该是纯函数式的、毫秒级的；格式化大文本、加解密、JSON 解析都应移出 build，放到异步任务或提前算好。

反模式三：@Prop 深拷贝滥用。@Prop 是值拷贝语义，大对象用 @ObjectLink + @Observed 引用传递，避免每次都完整复制。

三、长列表：LazyForEach 是底线

长列表不使用 LazyForEach（按需创建、超出可视区域销毁）而用普通 ForEach，几千条数据直接把内存和首帧拖垮。配合组件复用（@Reusable）与缓存条目数设置，万级列表可以稳定满帧。关键代码形态：

List() {
  LazyForEach(this.dataSource, (item: Item) => {
    ListItem() {
      ItemView({ data: item })   // @Reusable 复用，减少创建销毁开销
    }
  }, (item: Item) => item.id)    // 键值生成函数必须稳定、唯一
}
.cachedCount(5)                  // 预加载屏外条目，平滑滚动

四、工具链：用数据定位，不靠感觉

DevEco Studio 的 Profiler 提供帧率、CPU、内存的时序分析，配合 HiTrace 能看到渲染管线各阶段的耗时分布。实操建议：先录一屏「可疑场景」的帧数据，找丢帧时刻对应的耗时峰值，再回代码查那一帧发生了什么状态变更。优化顺序永远是先解决丢帧（体验硬伤），再解决内存（稳定性），最后才是不影响体验的锦上添花。

一句话总结：ArkUI 的性能优化 = 状态粒度足够细 × build 足够便宜 × 列表按需创建。三件事做到位，绝大多数「卡顿」会直接消失。