View Protocol — 关键概念，SwiftUI 中的 View 协议

SwiftUI 中的 View Protocol 是什么？

View Protocol — 是 SwiftUI 的核心协议，定义了每个视觉元素如何描述其内容。与 UIKit 不同，在 UIKit 中每个元素通过类继承自 UIView，而 SwiftUI 使用面向协议的方法：任何符合 View 协议的类型都可以在屏幕上显示。

View 协议只需要实现一个计算属性 body，它返回一定的内容。然而，在这种简单性背后隐藏着一个强大的组合系统：body 可以返回任何符合 View 的类型，包括基本元素（Text、Image、Button）、容器（VStack、HStack、ZStack）和自定义复合组件。

根据 WWDC 2023，超过 95% 的 SwiftUI 应用程序中的屏幕是通过组合实现 View 协议的结构来构建的。这使得 View Protocol 成为整个 SwiftUI 架构的基石。

Value type 与 Reference type

SwiftUI 要求 View 是 value type（结构体，struct），而不是类。这是一个关键的架构决策：value types 具有可预测的生命周期，没有共享的可变状态，并允许 SwiftUI 有效确定层次结构的哪些部分已更改并需要重绘。

如果您尝试将 View 作为类，编译器将报错：View 协议继承自 DynamicViewProperty 协议，该协议要求 value semantics。类可以符合 View，但这违反了惯用方法并丧失了自动更新的优势。

body：View 协议的计算属性

body — View 协议的唯一强制性要求。它是一个计算属性，返回屏幕上显示的内容。返回值的类型 — some View，意思是“符合 View 的某种类型，将由编译器确定”。

struct GreetingView: View {
    var name: String

    var body: some View {
        VStack {
            Text("你好，\(name)!")
                .font(.title)
                .foregroundColor(.blue)
            Button("开始") {
                print("按钮已按下")
            }
        }
    }
}

body 如何工作：每当应用程序状态发生变化并需要重绘时，SwiftUI 都会调用 body。框架将新的 View 树与旧的进行比较，并且只应用必要的更改（diffing）。这是一种完全声明性的方法——您描述应该显示什么，SwiftUI 负责如何实现它。

一个重要细节：body 不应有副作用。它在应用程序的生命周期内被多次调用，如果在 body 内部改变了外部状态——这会导致不可预测的行为。对于副作用，请使用 task、onChange 或 DispatchQueue。

元素数量限制

SwiftUI 施加了一个限制：body 只能返回一个根元素。如果您需要在同一级别显示多个元素，请将它们包装在容器中——VStack、HStack、ZStack 或 Group。随着 @ViewBuilder 的出现，这个限制变得不那么明显，但从概念上讲，body 总是返回一个 View。

some View：协议中的不透明类型

some View — 是在 Swift 5.1 中专门为 SwiftUI 引入的不透明类型（opaque type）语法。这意味着函数或属性返回符合 View 协议的具体类型，但调用代码不知道也不应该知道返回的具体类型是什么。

Swift 编译器在编译阶段为每个 body 实现确定具体类型，但对外部世界隐藏它。这允许 SwiftUI 通过知道所有组件的确切类型来优化 View 层次结构，同时赋予开发人员在更改实现时无需更改签名的灵活性。

struct ContentView: View {
    var body: some View {
        Text("你好，世界！") // 编译器知道这是 Text
    }
}

为什么是 some View，而不是 View？如果 body 只是返回 View（作为协议），SwiftUI 将无法在编译时确定具体类型。这会导致额外的开销，需要打包到存在容器（existential container）中。some View 为编译器提供了足够的信息进行优化，同时保持了协议的灵活性。

some View 的限制

主要限制 — body 必须返回相同的类型。没有特殊的包装器（AnyView、Group 或 @ViewBuilder），不能在条件的一个分支中返回 Text 而在另一个分支中返回 Image。编译器在编译阶段检查这一点：所有可能的返回路径必须具有相同的类型。

为了绕过这个限制，使用 @ViewBuilder（创建统一的 TupleView 类型）、Group（也返回统一的类型）或 AnyView（擦除类型，但增加开销）。AnyView 应该只在其他选项不可行时使用，因为它会禁用 SwiftUI 的优化。

@ViewBuilder：组合多个 View

@ViewBuilder — 是一个 result builder，其注释允许将多个 View 组合成一个组合体，无需嵌套容器。@ViewBuilder 自动将多个表达式包装成元组（TupleView），或者应用条件逻辑（If / else / switch）并返回正确的类型。

struct DashboardView: View {
    var isLoggedIn: Bool

    @ViewBuilder
    var body: some View {
        if isLoggedIn {
            Text("欢迎！")
                .font(.largeTitle)
            ProfileCard()
        } else {
            LoginButton()
                .padding()
        }
    }
}

@ViewBuilder 如何工作：编译器将 @ViewBuilder 内的每个代码块转换为 buildBlock、buildEither、buildOptional 等静态方法的调用。如果块包含多个表达式——它们被包装在 TupleView 中。如果块包含条件逻辑——编译器生成 ConditionalContent 隐藏分支的类型。

@ViewBuilder 施加了一个限制：一个块中最多 10 个元素（TupleView 限制）。如果需要组合超过十个元素，请使用 Group、ForEach 或分解为子组件。这个限制的存在是因为 Swift 为从 1 到 10 的每个参数数量生成了单独的 buildBlock 重载。

View 的组合与修饰符

组合 — SwiftUI 的关键原则：复杂的界面由小的、可重用的 View 组件构建而成。每个组件实现 View 协议并负责屏幕的自己的部分。修饰符（font、padding、foregroundColor）应用于 View 并返回一个具有修改设置的新 View。

SwiftUI 中的修饰符不是突变，而是在原始 View 周围创建新的包装。每个修饰符返回一个新类型（ModifiedContent），允许 SwiftUI 构建一个 修饰符树 并有效地只重绘更改的部分。修饰符的应用顺序很重要：不同的顺序会产生不同的视觉结果。

Text("你好，SwiftUI！")
    .font(.title)        // ModifiedContent
    .padding()           // ModifiedContent<..., PaddingModifier>
    .background(.yellow) // ModifiedContent<..., BackgroundModifier>
    .cornerRadius(8)    // ModifiedContent<..., CornerRadiusModifier>

性能优化：SwiftUI 比较的不是 View 的具体值，而是通过 identity 机制（id、ForEach、结构的稳定标识）比较它们的身份。如果 View 结构没有改变——body 不会被调用。这是通过 Equatable 比较和用于在层次结构中向上传递数据的 PreferenceKey 机制实现的。

为了有效的组合，建议将复杂的屏幕分解为 独立的子组件，每个组件都有自己的最小状态。这允许 SwiftUI 只重绘层次结构中已更改的部分，而不是整个屏幕。