12-20.【SwiftUI】 @ObservedObject / @StateObject 的滥用可能导致哪些性能问题？

在 SwiftUI 中，@StateObject 和 @ObservedObject 的误用是导致 App 卡顿、内存泄漏和逻辑异常的头号诱因。这种滥用通常表现为对**所有权（Ownership）和重绘范围（Redraw Scope）**的理解偏差。

以下是由于滥用而引发的四大核心性能问题：

这是最常见于将 @ObservedObject 用作“创建者”的场景。

错误做法：在 View 内部直接初始化一个 ObservedObject。

Swift

struct ChildView: View {
    @ObservedObject var viewModel = MyViewModel() // ❌ 严重错误
}

性能影响：
- CPU 峰值：由于 View 是值类型，父视图任何微小的状态改变都会导致 ChildView 重新 init。这意味着 MyViewModel 会被反复创建，消耗大量 CPU。
- 逻辑失效：如果 viewModel 的 init 里有网络请求，你会发现 App 疯狂发请求。更糟的是，原本的状态会被不断重置，导致 UI 永远无法保持正确。
防御对策：负责创建对象的视图必须使用 @StateObject。

当一个巨大的“上帝对象”（God Object）被作为 ObservedObject 注入到大量子视图时，会产生此问题。

现象：
- 你的 MainViewModel 里有 50 个 @Published 属性。
- 你有 20 个子视图都观察这个 MainViewModel。
性能影响：
- 只要这 50 个属性中任意一个发生变化，所有 20 个子视图的 body 都会被标记为“脏”，并强制执行重新求值和 Diff。
- Jank（掉帧） ：这种由于无关状态改变引发的联级刷新会导致主线程在 Diff 复杂视图树时超过 16ms 的渲染窗口。
防御对策：状态切片。将 ViewModel 拆分为更小的单元，或者在子视图中只接收必要的具体参数，而不是整个对象。

滥用 @ObservedObject 容易忽略其背后的 Combine 订阅开销。

现象：
- 在一个 List 的每一行都创建一个 @StateObject（如果列表有 1000 行）。
- 或者在 ObservedObject 的 init 中注册了长生命周期的监听（如 NotificationCenter）而没有妥善释放。
性能影响：
- 堆内存积压：StateObject 的生命周期随视图 Identity 消失而结束，但如果 Identity 没消失（如被 LazyVStack 缓存），这些对象会持续占用内存。
- 闭包捕获：如果在 ViewModel 中使用了异步闭包且没有 [weak self]，会导致视图即使退出后，整个对象树依然残留在内存中。

SwiftUI 必须在内部维护一张复杂的依赖表，记录哪个 View 观察了哪个 Object。

现象：过度使用多层嵌套的 @EnvironmentObject。
性能影响：
- 当环境对象更新时，SwiftUI 需要递归遍历整个视图树来寻找所有订阅者。如果层级过深，这种查找和依赖匹配的开销会显著增加，尤其是在动态变化的复杂导航结构中。
防御对策：优先使用局部状态，仅对真正全局的数据使用环境注入。