12-18.【SwiftUI】SwiftUI / TCA 中，State 变化与 ARC、diff 的关系？在 Swif

在 SwiftUI（尤其是结合 TCA）的上下文中，State（状态） 、ARC（自动引用计数） 和 Diff（差异对比） 三者构成了一个性能平衡的三角关系。

我们可以通过以下三个层面来拆解它们之间的内在联系：

在 SwiftUI 中，我们强调 State 应该是 值类型（Struct/Enum） 。这直接改变了 ARC 的工作方式。

减少引用计数开销：
- UIKit 时代（引用类型） ：每一个 UI 控件和数据模型都是 Class。修改一个属性可能涉及多个对象的强引用、弱引用判断，ARC 需要频繁地原子性地增减引用计数（Retain/Release），这在多线程环境下有非零的锁开销。
- SwiftUI/TCA 时代（值类型） ：State 是一个结构体。当你修改 State 时，Swift 并没有“修改”原对象，而是利用 写时拷贝（COW） 或在栈上创建一个新值。对于纯值类型（不包含 String/Array 等引用包装），ARC 的开销几乎为零。
ARC 仅在“容器”层面工作：
- 在 TCA 中，虽然 State 是值类型，但承载它的 Store 或 ViewStore 是引用类型。ARC 只负责维持这个“大型容器”的生命周期。容器内部千变万化的状态转换，完全避开了 ARC 的追踪压力。

SwiftUI 的 Diff 算法（Attribute Graph 的更新）极度依赖于 State 的 Value Semantics（值语义） 。

从“引用对比”到“内容对比” ：
- 引用类型的问题：如果 State 是 Class，SwiftUI 很难知道内部属性是否变了（因为指针没变）。它不得不保守地认为“可能变了”，从而强制重绘。
- 值类型的优势：SwiftUI 可以直接进行二进制级别或字段级别的对比。如果 oldState == newState（通过 Equatable），SwiftUI 会直接跳过整个子树的 body 执行。
TCA 的优化：
- TCA 强制 State 遵循 Equatable。在 ViewStore 中，它通过 observe 闭包来切片状态。只有当切片后的值发生变化时，才会触发布局更新。这本质上是在 Diff 发生之前，先进行了一层逻辑过滤。

假设用户在 TCA 架构中点击了一个按钮：

Action 发送：用户点击按钮。
Reducer 处理（与 ARC 相关） ：
- Reducer 接收旧 State（值类型）。
- 修改某个字段，Swift 执行 COW。如果该字段是简单的 Int，则在栈上完成；如果是 Array，ARC 会处理内部引用计数的转移。
- 生成全新的 State 结构体，存入 Store。
触发监听（与 Diff 相关） ：
- ViewStore 发现 State 内存地址或值变了。
- 执行 Equatable 的 == 操作。如果相等，流程结束（性能优化点）。
UI Diff（最终渲染） ：
- 如果不相等，SwiftUI 调用 body。
- SwiftUI 生成新的 View 值类型树。
- 将新树与旧树 Diff。因为 View 也是值类型，对比极快。
- 计算出最小改动集合，提交给 GPU 渲染。

如果处理不当，这三者的关系会变成性能杀手：

在 State 中嵌套大型 Class：
- 如果你在 struct State 里放了一个复杂的 class 对象，每次 State 拷贝时，ARC 依然要处理这个对象的引用计数。这破坏了值类型的性能优势。
- 优化方案：尽量将 Class 转换为 Struct，或者将其移出 State，作为 Effect 处理。
不合理的 Equatable 实现：
- 如果你的 == 实现非常重（例如对比两个包含一万个元素的数组），那么 Diff 之前的过滤开销甚至会超过重绘本身的开销。
- 优化方案：在 TCA 中使用 observe 只监听必要的字段。
ARC 循环引用（Memory Leak） ：
- 在 TCA 的 Effect（副作用）中，如果闭包强引用了 self（ViewModel/Store），ARC 无法释放它们。
- 防御点：在 Effect 中始终使用 [weak self] 或直接利用 TCA 的 Environment 机制避免直接引用。