首先，涉及一个性能原理：结构体比类更简单，更轻量。之所以名列前茅个说这个原因，是因为大多数都认为这是 SwiftUI 采用结构体的主要原因。其实，纵观全局，这只是原因之一。
一、SwiftUI用struct来表示view的原因
首先，涉及一个性能原理：结构体比类更简单，更轻量。之所以名列前茅个说这个原因，是因为大多数都认为这是 SwiftUI 采用结构体的主要原因。其实，纵观全局，这只是原因之一。
在 UIKit 中，所有的视图都继承自一个叫UIView的类，它有非常多的属性和方法 —— 背景颜色，布局约束，用于渲染的层，等等。还有更多诸如此类的属性，而每一个UIView和UIView的子类都有，因为这正是继承的工作方式。
通常这样也不会带来问题，但有一个特殊的子类UIStackView，它和 SwiftUI 里的VStack和HStack相似。在UIKi 里，出于使布局更简单的设计意图，UIStackView是一个不会被渲染的视图类型。但由于继承机制，尽管它不渲染，它也有那些包括背景颜色在内的各种用不上的属性。
在 SwiftUI 中，所有的视图都是细碎的结构体，创建开销几乎可以忽略。 想象一下：你创建了一个结构体，持有一个整数，整个结构体的大小只有——那个整数，再无其他。没有从父类、爷爷类、爷爷的爷爷类那里继承来的“意外财产”。它所包含的一切你都看得见。
得益于现代 iPhone 的能力，创建 1000 甚至 100,000 个整数只在眨眼之间。对于 SwiftUI 的 1000 个 view 或者 100,000 个 view。这个时间仍然成立。太快了，你都不必考虑它们。
不过，除了性能，用 struct 表示 view 还有其他重要原因：它强迫我们以一种更干净的方式隔离状态。类可以自由地修改它的值 —— 这可能导致更凌乱的代码，这样的话 SwiftUI 就无法通过某个值的变化来自动更新 UI 了。
通过创建不会跟随时间改变的视图，SwiftUI 鼓励我们迁移到一种可以更好地工作的设计方式：视图变简单，变“蠢”，它只做把数据变成 UI 的事情，而不是滋生出控制逻辑这样更“智能”的工作。
当你审视什么样的东西在 SwiftUI 中可以作为一个 view 的时候，你就会发现前面说的方式正在运作。我们用 Color.red 和 LinearGradient 作为视图 —— 一些存储非常简单数据的细碎类型。实际上，相对于把 Color.red 直接当成 view，你找不到更好的方案了。除了“把我的空间填满红色”，它没有携带其他任何多余的信息。
作为比较，你可以看下 Apple 的UIView文档。上面列出了200 多个UIView的属性和方法 ——不管子类需不需要，都拿着。
提示:如果你试图给你的 view 用上 class，那么代码要么编译不过要么就会崩溃。不要犹豫：用 struct 。
延伸阅读：
二、视图值树是什么
在 SwiftUI 中，视图是状态的函数。
开发者通过符合 View 协议的结构体来声明界面，SwiftUI 通过调用结构体实例的 body 获取对应的视图值。body 则根据用户的界面描述和对应的依赖（Source of truth）计算结果。
在 app 运行后进行名列前茅次渲染时，SwiftUI 将依据类型树按图索骥，创建类型实例，实例的 body 根据初始状态计算视图值，并组织成视图值树。需要创建哪些实例，则是根据当时的状态决定的，每次的状态变化都可能会导致最终生成的视图值树不同（可能仅是某个节点的视图值发生变化，也可能是视图值树的结构都发生了巨大的变化）。
当 State 发生变化后，SwiftUI 会生成一棵新的视图值树（Source of truth 没有发生变化的节点，不会重新计算，直接使用旧值），并同老的视图值树进行比对，SwiftUI 将对其中有变化的部分重新布局渲染，并用新生成的视图值树取代老的视图值树。
视图值树通常只保存当前布局、渲染所需的内容（个别情况下，会缓存少数不参与布局、渲染的视图值），在 app 的生命周期中，随着 State 的变化而不断地变化。
