本文转载自微信公众号《Swift社区》，作者魏贤智。转载本文请联系Swift社区公众号。如果您曾经为UIKit或AppKit（Apple针对iOS和macOS的原始用户界面框架）编程过，您就会知道它们使用类而不是结构来构造视图。SwiftUI并非如此：出于两个原因，我们更喜欢整体视图的结构。首先是性能因素：结构比类更简单、更快。我说性能是因为很多人认为这是SwiftUI使用结构体的主要原因，而实际上它只是全局的一部分。在UIKit中，每个视图都来自一个名为UIView的类，该类具有许多属性和方法：背景颜色、确定其放置方式的约束、将其内容渲染到的图层等。它们有很多，每个UIView和UIView子类都必须有它们，因为这就是继承的工作方式。结构或类通常这不是问题，但是有一个特定的子类称为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文档[1]列出了UIView拥有的大约200个属性和方法，无论是否需要，所有这些都被传递给它的子类。**提示：**如果您在视图中使用类，您可能会发现您的代码无法编译或在运行时崩溃。参考资料[1]UIView文档：https://developer.apple.com/documentation/uikit/uiview
