如果您曾经为UIKit或AppKit（Apple的iOS和macOS原始用户界面框架）编程，您会知道它们使用类而非结构体来构造视图。SwiftUI并非如此：我们更喜欢将结构体用于整体视图，这有两个原因。
首先，有一个性能因素：结构体比类更简单，更快。我之所以说性能因素，是因为很多人认为这是SwiftUI使用结构体的主要原因，而实际上这只是更大范围的一部分。
在UIKit中，每个视图都来自一个名为UIView的类，该类具有许多属性和方法：背景色，确定其放置方式的约束，用于将其内容呈现到其中的图层等等。其中有很多，每个UIView和UIView子类都必须具有它们，因为继承是这样工作的。
struct or class
通常这不是问题，但是有一个名为UIStackView的特定子类，它类似于SwiftUI中的VStack和HStack。在UIKit中，UIStackView是一种非渲染视图类型，旨在简化布局，但这意味着即使它因为继承的原因具有背景色，也从未真正使用过。
在SwiftUI中，我们所有的视图都是简单的结构体，几乎可以自由创建。想想看：如果您制作一个仅包含一个整数的结构体，则结构体的整个大小就是：一个整数。没有其他的。没有从父类，祖父母类或曾祖父母类等继承的多余值——它们完全包含您可以看到的内容，仅此而已。
得益于现代iPhone的强大功能，我不会慎重考虑后创建1000个整数甚至100,000个整数——眨眼之间就会发生。1000个SwiftUI视图甚至100,000个SwiftUI视图也是如此。他们是如此之快，以至于不再值得考虑。
但是，尽管性能很重要，但视图作为结构体还是有很多更重要的事情：它迫使我们考虑以一种干净的方式隔离状态。您会发现，类能够自由更改其值，这可能导致代码混乱——SwiftUI如何知道什么更改了值并需要更新UI？
通过生成不会随时间变化的视图，SwiftUI鼓励我们转向更具功能性的设计方法：在将数据转换为UI时，我们的视图变成简单的，惰性的东西，而不是会失去控制的智能化的东西。
当您查看可以作为视图的事物时，可以看到这一点。我们已经使用了Color.red和LinearGradient作为视图——包含很少数据的简单类型。实际上，您不能找到比使用Color.red作为视图的更好的主意：除了“用红色填充我的空间”之外，它不包含任何信息。
相比之下，Apple的UIView文档列出了UIView拥有的约200种属性和方法，无论是否需要它们，所有这些属性和方法都将传递给其子类。
提示：如果您在视图中使用类，则可能会发现代码无法编译或在运行时崩溃。 相信我：使用结构体。
