5-6.【性能优化】为什么频繁修改深层对象会产生性能问题？为什么修改数组元素 UI 不刷新？如何设计不可变数据优化？

在 ArkUI 的状态管理机制中，性能问题和“UI 不刷新”的现象通常指向同一个底层逻辑：装饰器对数据追踪的深度限制。

频繁修改深层对象（如 this.obj.a.b.c.d = value）会导致性能下降，主要源于以下三个开销：

观察者链路的遍历开销：当一个对象被 @State 装饰时，它被包装成一个 Proxy 或具有 Getter/Setter 的观察对象。修改深层属性时，框架需要从底层向上追踪到根对象，以确定哪些组件依赖于这个“变化源”。
冗余的“脏检查” ：如果一个大对象被多个组件引用，修改其中一个末端属性可能会触发该对象下所有关联组件的重新 Diff 逻辑。即便某些组件只用到了该对象的其他字段，它们仍会被卷入“潜在更新”的流程中。
Proxy 代理的堆叠开销：为了实现深度监听，框架往往需要对嵌套的每一层对象都进行代理包装。高频修改深层属性意味着 JS 引擎需要频繁穿透多层拦截器（Interceptors），这会产生显著的 CPU 累积耗时。

这是初学者最常遇到的“坑”。

监听维度的局限性：@State 装饰的数组，框架只能自动监听数组长度的变化（如 push, pop, splice）以及数组引用的更替。
索引赋值的“静默” ：当你执行 this.array[0] = newValue 时，数组的内存地址没变，长度也没变。ArkUI 的拦截器无法捕捉到这种基于索引的直接赋值操作，因此不会触发重绘。
元素内部属性的不可见性：如果数组元素是对象，修改 this.array[0].name = 'NewName' 同样无效，因为数组只负责看管“成员是谁”，而不负责看管“成员内部长什么样”。

解决方案：

不可变数据的核心思想是：不修改旧对象，而是返回一个包含变化部分的新对象。这种设计在声明式 UI 中有天然的优势：

由于每次修改都会生成新引用，框架只需要进行简单的“全等对比”（oldObj === newObj）。如果引用没变，框架可以瞬间跳过整棵子树的检查。

使用不可变数据并不意味着全量拷贝。你可以只替换变化的那一部分：

TypeScript

// 假设更新用户积分，而不改变用户信息
this.user = { ...this.user, score: newScore };

扁平化 Store：将嵌套深的对象拆分为多个独立的状态变量，减少 ...spread 操作的深度。
计算属性优先：不要在状态里存储“派生数据”。例如，不要存 fullName，而是通过 get 函数由 firstName 和 lastName 动态组合。
配合 @Track：在最新的 ArkTS 中，给类属性加上 @Track 装饰器。这能确保只有被标记且实际变化的属性才会触发更新，从而在“可变对象”上模拟出“不可变数据”的精准刷新性能。