SwiftUI 架构选型与 trade-off：从 UIKit 到声明式的演进

一、为什么 SwiftUI 是范式转移

iOS 架构演进了 14 年，SwiftUI（2019） 是继 Objective-C → Swift 之后的第二大范式转移。它的核心不是"更简单的语法"，而是状态驱动 UI——开发者只描述 UI 应该长什么样，由框架根据状态变化自动 reconcile。这与 React、Flutter、Compose 走的是同一条路。

范式转移带来三个根本变化：状态管理显式化、UI 与逻辑分离、跨平台 UI 一致性。这三点决定了 SwiftUI 的架构决策与 UIKit 时代完全不同。

graph LR
    A[UIKit 命令式
手动 setNeedsLayout] --> B[状态不一致]
    B --> C[UI 与逻辑耦合]
    C --> D[测试困难]
    E[SwiftUI 声明式
state 自动驱动] --> F[单一数据源]
    F --> G[UI 与逻辑分离]
    G --> H[易测试]

二、UIKit 时代架构回顾

理解 SwiftUI 的价值，先要理解 UIKit 时代架构的痛点。我们用 8 年时间经历了 MVC → MVP → MVVM → VIPER 四代演进，每代都在解决前代的"胖问题"。

2.1 MVC：胖 Controller

Apple 原生推荐的 MVC 在 iOS 里被戏称"MVC = Massive View Controller"——ViewController 同时管 UI、布局、网络、跳转、业务逻辑，几千行代码成常态。

2.2 MVP / MVVM：职责拆分

MVP 把逻辑挪到 Presenter，MVVM 用 ViewModel + 双向绑定（RxSwift / Combine）。痛点是双向数据流——一个状态变化可能引发意想不到的副作用，调试时要追一堆回调。

2.3 VIPER：过度工程

VIPER（View-Interactor-Presenter-Entity-Router）走极端——一个页面 5 个文件，10 个协议。对小项目是负担，对超大型项目（几十个模块）才有价值。

graph TB
    A[MVC] --> B[MVP]
    B --> C[MVVM
双向绑定]
    C --> D[VIPER
5 文件]
    D --> E[SwiftUI UDF
单向数据流]

三、SwiftUI 单向数据流（UDF）

SwiftUI 的官方推荐架构是单向数据流（UDF）——State 由 ViewModel 持有，UI 只读取 + 发送 Event。这是 SwiftUI 时代最确定的架构原则，Apple 在 WWDC 反复强调。

graph LR
    A[State] --> B[View]
    B -->|Event| C[Action]
    C --> D[Reducer]
    D --> A

3.1 UDF 的三大原则

• 单一数据源：状态只在一个地方定义，UI 永远从同一处读取
• 状态只读：UI 不能直接修改状态，必须通过 Action
• 副作用隔离：网络、数据库等副作用集中在特定层

3.2 trade-off

UDF 不是免费的。代价是代码量增加——一个简单页面需要 State + Action + Reducer 三套定义。但收益是可预测性指数级提升——任何 UI 异常都能通过状态历史回放找到原因。

四、TCA vs MVVM vs Redux 模式选型

SwiftUI 时代有三个主流架构模式：TCA（The Composable Architecture）、MVVM+Combine、Redux-like。每个都有明确的适用场景和 trade-off。

4.1 TCA：函数式架构

TCA（Point-Free 出品）是 SwiftUI 时代最完整的 UDF 实现——State + Action + Reducer + Effect 严格分离，支持时间旅行调试。适合大型团队 + 复杂业务 + 强一致性场景。代价是学习曲线陡、第三方依赖重。

4.2 MVVM + Combine

经典 MVVM 套 Combine，ViewModel 用 @Published 暴露状态，View 用 @ObservedObject 订阅。适合中小型 App + 快速迭代。代价是没有强制 UDF，可能退化为双向绑定。

4.3 Redux-like

借鉴 Web Redux，Store 全局管理 State，View 订阅 Store。适合跨页面共享状态多的场景。代价是 Store 膨胀、Action 爆炸。

五、迁移策略：渐进式 vs 重写式

已有 UIKit 项目迁移到 SwiftUI，不能一次重写。两种策略：渐进式（新页面 SwiftUI + 老页面 UIKit）和重写式（一次性全切）。我们选了渐进式——5 年迁移完，最稳。

5.1 渐进式迁移

SwiftUI 通过 UIHostingController 嵌入 UIKit 工程，通过 UIViewRepresentable 在 SwiftUI 中使用 UIKit 组件。新页面用 SwiftUI，老页面逐步替换。优势是风险可控、可回滚；劣势是技术栈长期分裂。

5.2 重写式风险

一次性重写风险极高——业务不能停、UI 不能崩、API 不能变。我们见过两次大重写失败的案例：项目延期 6 个月 + 用户流失 20%。小项目才适合重写，大项目只能渐进。

5.3 迁移节奏

我们的节奏：每年迁移 25% 页面，4 年完成切换。新模块强制 SwiftUI + TCA，老模块按 ROI 排序逐步替换。期间维护"双技术栈"——这本身是个 trade-off。

graph LR
    A[2022 SwiftUI 10%] --> B[2023 SwiftUI 35%]
    B --> C[2024 SwiftUI 60%]
    C --> D[2025 SwiftUI 85%]
    D --> E[2026 SwiftUI 100%]

六、SwiftUI 性能优化与陷阱

SwiftUI 看起来简单，性能陷阱却不少。我们踩过的 5 大坑——

6.1 过度重绘

SwiftUI 自动检测状态变化重绘视图，但子视图重绘成本被低估。常见错误：把整个列表项做成一个 View，每次状态变化整个列表项重绘。正确做法是拆分小组件 + Equatable，让 SwiftUI 知道哪些子视图无需重绘。

6.2 大列表性能

List 内部用 LazyVStack，理论上是懒加载。但数据源处理不当会导致全量重算——比如 onAppear 中做耗时操作、ID 不稳定导致 diff 失败。

6.3 动画失控

SwiftUI 动画 API 优雅，但隐式动画容易失控——一个状态变化触发意料之外的连锁动画。原则：显式动画（withAnimation），避免依赖隐式传播。

七、状态管理：@State / @ObservedObject / @Environment

SwiftUI 状态管理有几个 Property Wrapper，选错会引发各种 bug。我总结成一张选型表——

7.1 选型原则

• @State：视图内部状态（开关、文本框值）
• @Binding：父子视图双向传递状态
• @ObservedObject：视图持有外部 ObservableObject
• @StateObject：视图创建并持有 ObservableObject（生命周期跟视图）
• @EnvironmentObject：从环境依赖注入的全局对象

7.2 经典 bug

最常见 bug 是@ObservedObject 与 @StateObject 混用导致状态被重置。比如把 ViewModel 写成 @ObservedObject，每次父视图重绘都新建一个实例，旧状态丢失。正确做法是@StateObject——生命周期跟视图，不是跟重绘。

graph LR
    A[父视图重绘] -->|@ObservedObject| B[ViewModel 重建
状态丢失]
    A -->|@StateObject| C[ViewModel 复用
状态保持]

八、导航架构：从 NavigationView 到 NavigationStack

iOS 16 起 SwiftUI 引入了NavigationStack——基于路径（Path）的声明式导航，彻底替代了老的 NavigationView。这是导航架构的重大改进，解决了之前的"导航状态丢失"问题。

8.1 NavigationStack 优势

NavigationStack 把导航路径变成一等公民——可以用数组描述页面栈，可以用 binding 控制前进后退，可以用 deep link 直接跳到指定页面。这对复杂业务流（电商下单流程、多步骤表单）是革命性改进。

8.2 路径管理

路径必须放在ViewModel 而非 View 里，否则页面栈状态无法持久化。NavigationStack(path:) 接受 binding，让 ViewModel 完全控制导航。

8.3 Deep Link

NavigationStack 让 deep link 实现变得自然——把 URL 路径解析成 NavigationPath，绑定到 NavigationStack 即可。我们用它实现了"分享链接直达商品详情页"功能，比 UIKit 时代简单 10 倍。

九、与 UIKit 混编：UIViewRepresentable 实战

渐进式迁移期间必须与 UIKit 混编。两个关键 API：UIHostingController（在 UIKit 中嵌入 SwiftUI）和 UIViewRepresentable（在 SwiftUI 中嵌入 UIKit）。

9.1 UIHostingController 模式

把 SwiftUI View 包装成 UIViewController，可以像普通 UIViewController 一样 push/present。这是新页面嵌入老工程的主要方式。注意：UIHostingController 的生命周期由 UIKit 管理，SwiftUI 的状态可能丢失。

9.2 UIViewRepresentable 模式

反过来，把 UIKit 控件包装成 SwiftUI View，用于SwiftUI 中使用 UIKit 组件。比如地图、相机、视频播放器等 SwiftUI 还没原生支持的组件。

graph LR
    A[UIKit 工程] -->|UIHostingController| B[SwiftUI View]
    C[SwiftUI View] -->|UIViewRepresentable| D[UIKit 控件]

十、未来形态：SwiftUI 跨端与 visionOS

SwiftUI 不再是 iOS 专属——它已经扩展到 macOS、watchOS、tvOS、visionOS。Apple 的愿景是用一套 SwiftUI 代码覆盖所有平台，这是它真正的战略价值。

10.1 visionOS 适配

visionOS（Apple Vision Pro）原生 SwiftUI——3D 空间、立体渲染、眼动追踪。手势 / 眼动作为输入，View 自动适配。这是 SwiftUI 在新平台的第一波红利，提前布局的团队能吃到。

10.2 跨端架构演进

SwiftUI 的下一步是真正的"一次编写，多端运行"——通过条件编译 + 平台适配层，同一套代码在 iOS / macOS / watchOS / visionOS 运行。我们正在试点，预计 2027 年成为现实。

graph LR
    A[SwiftUI 代码] --> B[iOS]
    A --> C[macOS]
    A --> D[watchOS]
    A --> E[visionOS]
    A --> F[tvOS]

📌 关键架构决策清单