在 ArkUI 的响应式系统中，**“状态粒度”**直接决定了框架在更新 UI 时需要“扫描”的范围。理解大对象与小对象的性能差异，本质上是在理解 依赖收集（Dependency Collection） 与 局部渲染（Partial Rerendering） 的成本。
1. 为什么“状态粒度过大”会导致性能下降？
当一个组件依赖于一个 @State 变量时，它就成了该变量的订阅者。
- 冗余检查（Redundant Check） ：如果一个大对象包含 50 个字段，而你的组件只用到了其中 1 个。只要这 50 个字段中的任意一个发生改变，框架都会通知该组件：“喂，你订阅的对象变了，快查查你的 UI 需不需要重画。”
- Diff 范围扩散：框架虽然有局部刷新机制，但它需要遍历该组件
build()函数中涉及该对象的所有 UI 节点。对象越大，涉及的节点往往越多，Diff 算法的计算量呈指数级增长。 - 内存屏障：由于装饰器会对对象进行 Proxy 代理，大对象的每个属性访问都会经过一层拦截逻辑。高频访问大对象属性会累积显著的 CPU 耗时。
2. 一个大对象 vs. 多个小对象
在实际开发中，这两者的性能表现有着天壤之别：
一个大对象 (Monolithic Object)
- 结构：
@State user: User = { name, age, avatar, score, history... } - 结果：修改
score（高频），会导致显示name和avatar的组件也跟着触发“检查”逻辑。 - 场景：适合数据结构极简、且各字段总是同步变化的场景。
多个小对象 (Granular States)
- 结构：
@State name: string,@State score: number,@State avatar: string - 结果：修改
score时，只有显示分数的那个Text组件会重新执行渲染逻辑。其他组件（如头像、姓名）在底层完全静默。 - 场景：推荐方案。通过物理拆分，实现了真正的“按需刷新”。
3. 如何通过组件拆分优化？
组件拆分不仅是为了代码复用，更是**“缩小刷新范围”**的头号手段。
A. 状态下沉（State Sinking）
不要在父组件（Page）里管理所有的状态。
- 策略：将只属于某个局部功能的状态定义在子组件内部。
- 效果：当状态改变时，刷新被锁定在子组件内部，父组件的
build()完全不会被重新调用。
B. 局部化订阅 (@ObjectLink)
如果你必须传递一个复杂的 Observed 对象，不要让父组件去解构它。
- 做法：将对象传给专门的子组件，子组件内部用
@ObjectLink接收。 - 优化点：父组件只负责传递“引用”，不参与具体的属性展示。这样，属性变化时，只有那个拥有
@ObjectLink的子组件会动。
C. 容器与展示组件分离
- 容器组件：负责逻辑处理、网络请求。
- 展示组件：只负责接收细粒度的数据片段（如
string或number）。 - 效果：通过减少子组件对“大对象”的直接依赖，切断无效的联动链条。
4. 实战对比：优化前后
| 方案 | 刷新范围 | CPU 占用 | 响应速度 |
|---|---|---|---|
| 未拆分（一个大 State） | 整个页面重绘 | 高（频繁触发布局计算） | 略有肉眼可见的延迟 |
| 已拆分（细粒度组件） | 仅受影响的微小节点 | 极低（指令级更新） | 极其丝滑 |
架构师的黄金建议：
“能拆则拆，越碎越好。” 在 ArkUI 中，创建一个自定义组件（@Component）的开销远比处理一个庞大状态导致的重绘开销要小。如果你发现一个页面里 @State 超过了 10 个，或者一个对象超过了 5 个属性，就该考虑拆分组件了。
