播面

这是一个非常经典且触及 SwiftUI 核心架构设计的问题。

简单来说，SwiftUI 使用 Struct（结构体）而不是 Class（类），主要是为了性能（Performance）、线程安全（Thread Safety）以及配合其声明式（Declarative）的编程范式。

以下是详细的深度解析：

1. 性能：极度轻量化 (Performance)

• 栈（Stack）vs 堆（Heap）：
  • Class (引用类型): 分配在堆内存中，需要昂贵的内存分配和释放操作，并且涉及引用计数（ARC）的管理。
  • Struct (值类型): 通常分配在栈内存中（非常快），不需要引用计数。
• 创建成本：
  • 在 UIKit 中，UIView 是一个非常“重”的对象。它包含图层（CALayer）、手势识别器、约束系统、背景色、事件响应链等大量属性。创建一个 UIView 的开销很大。
  • 在 SwiftUI 中，View 只是一个遵循 View 协议的 Struct。它几乎不占用内存，它只包含极少量的属性（通常只是用来保存状态的变量）。创建一个 SwiftUI View 的成本几乎可以忽略不计。 这使得 SwiftUI 可以频繁地销毁并重新创建整个视图层级，而不会造成卡顿。

2. 声明式范式：View 只是“蓝图” (Blueprint)

这是理解 SwiftUI 的关键。

• UIKit (命令式): UIView 对象就是屏幕上的像素表示。你长期持有这个对象，并修改它的属性（如 label.text = "Hello"）。
• SwiftUI (声明式): SwiftUI 的 View Struct 并不是屏幕上实际渲染的组件，它只是一份说明书或蓝图。
  • 当你写一个 Text("Hello") 时，你并没有创建一个渲染文本的组件，你只是创建了一个轻量级的数据结构，告诉 SwiftUI 系统：“我希望这里显示一个文本”。
  • SwiftUI 的底层框架（Attribute Graph）会读取这份蓝图，并负责在屏幕上生成真正的渲染对象（底层可能依然是 CoreAnimation 或 Metal）。
  • 因为蓝图（Struct）很便宜，所以每次数据变化时，SwiftUI 都会直接销毁旧蓝图，创建新蓝图，而不是修改旧对象。

3. 状态管理与不可变性 (Immutability & State)

• 单一数据源 (Source of Truth):
  • Class 是可变的（Mutable）。如果多个地方引用同一个 Class 对象，任何一方修改了它，其他方都会受到影响。这在复杂的 UI 开发中容易导致状态不同步的 Bug。
  • Struct 是值类型，默认是不可变的。当你改变 Struct 的属性时，实际上是创建了一个新的 Struct。
• 强制解耦:
  • SwiftUI 强制你将数据（State）和视图（View）分离。View 只是数据的函数（View = f(State)）。
  • 当 @State 或 @ObservedObject 发生变化时，SwiftUI 知道数据变了，它会再次调用 body 属性生成新的 View Struct。这种机制消除了“视图状态”和“数据状态”不一致的可能性。

4. 高效的 Diff 算法 (Diffing)

SwiftUI 需要知道什么时候更新屏幕。

• 如果 View 是 Class，要判断两个 View 是否“内容相同”非常困难（需要深度遍历对象图，检查每一个属性）。
• 因为 View 是 Struct（值类型），SwiftUI 可以非常高效地对比新旧两个 View 的结构。
  • 它只需要对比简单的值（比如 Text 的字符串内容、Frame 的数值）。
  • 如果新旧 Struct 的值一样，SwiftUI 就知道不需要重绘屏幕；如果不一样，它只更新变化的部分。
  • 这种对比在内存中进行（memcmp），速度极快。

5. 避免内存泄漏 (No Retain Cycles)

• 使用 Class 构建 UI 时，开发者必须时刻小心循环引用（Retain Cycles），比如 Closure 中必须使用 [weak self]。
• 使用 Struct View，因为它们是值类型，不涉及引用计数，因此在 View 层级结构内部几乎完全消除了循环引用的风险。

总结：UIKit vs SwiftUI

一句话总结：
SwiftUI 的 View 之所以是 Struct，是因为它们被设计为极度廉价、不可变且短暂的“渲染说明书”，这使得系统可以极其快速地通过销毁和重建来响应状态变化，从而实现声明式 UI 的核心逻辑。