4. 可观察状态模型：LiveData、StateFlow、ObservableObject的选择对比与平台解耦策略

4.1 边界定义：本章讨论的是什么，不讨论什么

在MVVM架构中，可观察状态模型是连接ViewModel（业务逻辑层）与View（表示层）的核心纽带。本章的边界明确限定为：Android平台的 LiveData 与 StateFlow，以及Apple平台的 ObservableObject（含 @Published 与 @Observable 宏）。

• 不讨论：RxJava、Combine（Apple原生响应式框架的内部细节）、Kotlin Flow的非状态化用法（如 SharedFlow 的纯事件用法将在后续章节单独展开）。
• 不讨论：跨平台框架（Flutter/React Native）的可观察模型，本章仅关注原生平台。

4.2 分层与组件职责

可观察状态模型在MVVM架构中位于中间层，其上下边界必须清晰：

• 上层（View/UI Layer）：只消费状态，不生产状态。通过 observe()、collect() 或 body 属性访问触发重绘。
• 中间层（可观察状态模型）：负责包装业务层产出的快照，提供线程安全、生命周期感知、多观察者通知能力。
• 下层（Platform Binder）：将中间层适配到平台UI框架的特定观察机制（如Android的 LifecycleOwner、iOS的 ObservationRegistrar）。

4.3 数据流、控制流与信任链路

以一张内联SVG结构图展示三种模型在架构中的位置与数据流动方向：

信任链路分析：

• 数据流：业务层 → ViewModel → 可观察状态模型 → 绑定层 → UI重绘。
• 控制流：UI事件 → ViewModel → 状态更新 → 自动扩散至所有活动观察者。
• 信任边界：可观察状态模型必须保证状态变更的幂等性与线程安全性；绑定层负责将平台特定的生命周期事件隔离在内部，不泄漏到业务层。

4.4 选型权衡：LiveData vs StateFlow vs ObservableObject

4.5 风险点与逃逸场景

以下风险直接影响架构的长期稳定性：

• LiveData 粘性事件误用：使用 SingleLiveEvent 或对粘性行为不理解的团队可能产生状态回放错误。缓解：强制要求所有“一次性事件”走 Channel 或 SharedFlow。
• StateFlow 冷启动事件覆盖：若初始值设置错误或 update 操作在 collect 之前丢失，UI 可能展示错误状态。缓解：保证 ViewModel init 阶段完成初始赋值。
• ObservableObject 线程安全：@Published 属性在非主线程修改可能导致 SwiftUI 崩溃。缓解：统一使用 @MainActor 标记 ViewModel。
• 平台解耦假象：团队声称使用 StateFlow 实现跨平台，但实际在 ViewModel 中直接调用 Android Lifecycle API。缓解：在架构契约中明确 平台绑定层 不可被业务层引用。

4.6 落地步骤

1. 分平台隔离选择：Android 模块统一使用 StateFlow，iOS 模块使用 ObservableObject，预留跨平台桥接接口。
2. 定义统一接口：在共享层（KMP 或抽象接口）声明 interface StateModel<T>，包含 subscribe()、unsubscribe()、snapshot()。
3. 实现平台绑定器：Android 绑定器将 StateFlow 转化为 LiveData 或通过 asLiveData() 暴露给传统 View 层；iOS 绑定器将 ObservableObject 适配为 PassthroughSubject 桥接。
4. 单元测试验证：对每个可观察状态模型单独测试状态变更（不依赖UI），验证 多收集者并发 update 场景。
5. 验收度量：记录状态模型从变更到 UI 刷新的延迟（Android < 16ms 为绿灯），以及每个 View 持有的订阅数（< 5 个为合理）。

4.7 验收标准