12-1.【SwiftUI】View 是值类型，为何 UI 依然可以“持续存在”？

项阿丑
26 阅读5分钟

要理解这个机制，你需要区分 View（描述信息） 和 Render Tree（底层实体） 。

在 SwiftUI 中，你编写的 struct View 实际上并不是真正的 UI 控件，它只是 UI 的一份“配方”或“快照” 。

1. 视图 vs. 树（The Blueprint vs. The Building）

SwiftUI 的核心架构分为三层：

  1. View Tree（值类型层） ： 你定义的 struct。它是瞬时的、廉价的。每当状态改变，SwiftUI 都会重新生成这一层。它的生命周期可能只有几微秒。
  2. Attribute Graph（逻辑树层） ： 这是 SwiftUI 内部维护的长久存在的结构。它负责管理状态（State/Binding） 、依赖关系和布局计算。
  3. Render Tree / UIKit（渲染层） ： 最终生成的像素、Core Animation 图层或底层的 UIView（如果是混合开发）。

2. 为何 UI 依然可以持续存在？

UI 能够“持续存在”并保持动画平滑，是因为 Identity（标识符） 机制。

身份一致性 (Identity)

即使 struct View 是全新的值类型，SwiftUI 依然可以通过两种方式识别它是否是“同一个”控件：

  • 显式标识 (Explicit Identity) ：使用 .id() 手动指定。
  • 结构标识 (Structural Identity) ：根据 View 在代码树中的位置（第几个子节点、在哪个 if-else 分支）来判断。

防御式理解： 当状态改变时，SwiftUI 会生成一个新的 View 值，并将其与 Attribute Graph 中的旧快照进行 Diff（差异对比） 。

  • 如果标识（Identity）没变，SwiftUI 只会更新底层实体的属性（如颜色、文字），而不会销毁并重建该控件。
  • 这就是为什么按钮的点击动画不会因为 View 的重新创建而中断。

3. 生命周期：State 的寄生

由于 View 是值类型，它无法存储状态。这就是为什么我们需要 @State、@StateObject。

  • 当你声明 @State 时，SwiftUI 实际上在 Attribute Graph（长久存在的那一层）里为这个 View 预留了一个存储空间。
  • View struct 本身并不持有这个状态，它只持有一个指向该空间的索引。
  • 即使 View 被销毁重造，只要 Identity 保持不变，新生成的 View 依然会指向同一个内存槽位。

4. 性能优化：为什么值类型更优？

相比 UIKit 的引用类型（Class），值类型的优势在于：

  1. 零引用计数开销：创建和销毁极快。
  2. 线程安全：不需要担心多线程竞争导致 UI 渲染出错。
  3. 易于 Diff：对比两个 struct 是否相等比对比复杂的对象树要快得多。

5. 防御式编程避坑指南

理解了这一机制，你在开发中应注意：

  • 保持结构稳定：避免频繁改变 View 的层次结构（例如过度使用 AnyView），因为这会破坏结构标识，导致 SwiftUI 误认为是一个新 View，从而丢失 @State 并重置滚动位置。
  • 合理使用 .id() ：当你希望某个组件彻底重置（如切换用户后重置表单），改变 .id() 是最高效的方法，它会强制销毁旧的 Attribute 节点。

总结一句话：你的 View 是影子（随时随光影改变），而底层的 Attribute Graph 才是实体。

12-1. [SwiftUI] Views are Value Types—How does the UI "Persist"?

To understand this mechanism, you must distinguish between the View (Description) and the Render Tree (Underlying Entity) .

In SwiftUI, the struct View you write is not actually a real UI control; it is merely a "recipe" or "blueprint" for the UI.

1. The Blueprint vs. The Building

SwiftUI's core architecture is divided into three distinct layers:

  1. View Tree (Value Type Layer) : This is the struct you define. It is transient and inexpensive. SwiftUI regenerates this layer every time a state changes. Its lifespan may only be a few microseconds.
  2. Attribute Graph (Logic Tree Layer) : This is a long-lived structure maintained internally by SwiftUI. It is responsible for managing states (@State/@Binding) , dependencies, and layout calculations.
  3. Render Tree / UIKit (Rendering Layer) : The final pixels, Core Animation layers, or underlying UIViews (in hybrid apps) that appear on the screen.

2. Why does the UI persist?

The UI "persists" and maintains smooth animations because of the Identity mechanism.

Identity Consistency

Even though a struct View is a brand-new value type instance, SwiftUI recognizes whether it represents the "same" control through two methods:

  • Explicit Identity: Manually specified using the .id() modifier.
  • Structural Identity: Determined by the View's position in the code hierarchy (e.g., its position as a child node or its branch within an if-else statement).

Key Concept: When state changes, SwiftUI generates a new View value and performs a Diff (Difference comparison) against the old snapshot in the Attribute Graph.

  • If the Identity remains the same, SwiftUI only updates the properties of the underlying entity (like color or text) rather than destroying and rebuilding the control.
  • This is why a button’s press animation is not interrupted just because the View struct was recreated.

3. Lifecycle: The "Parasitic" Nature of State

Since Views are value types, they cannot store persistent data. This is why we need @State and @StateObject.

  • When you declare @State, SwiftUI allocates storage space within the Attribute Graph (the long-lived layer) specifically for that View.
  • The View struct itself does not hold this state; it only holds an index or "pointer" to that allocated space.
  • Even if the View struct is destroyed and recreated, as long as the Identity remains consistent, the new View will point to the exact same memory slot.

4. Why are Value Types Superior for UI?

Compared to UIKit's reference types (Classes), value types offer several advantages:

  1. Zero Reference Counting Overhead: Creation and destruction are extremely fast.
  2. Thread Safety: You don't have to worry about race conditions during UI rendering.
  3. Efficient Diffing: Comparing two structs is significantly faster than traversing complex object trees.

5. Pro-Developer Troubleshooting Tips

Understanding this mechanism helps you avoid common pitfalls:

  • Maintain Structural Stability: Avoid frequently changing the View hierarchy (e.g., overusing AnyView). This breaks structural identity, causing SwiftUI to think it's a new View, which leads to lost @State and reset scroll positions.
  • Strategic use of .id() : If you want a component to be completely reset (e.g., clearing a form when switching users), changing the .id() is the most efficient way. It forces the destruction of the old Attribute node.

Summary in one sentence: Your View is the shadow (changing instantly with light and movement), while the underlying Attribute Graph is the solid object casting it.

avatar
文章
阅读
粉丝