為什麼SwiftUI的視圖使用結構體？

如果您曾經為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種屬性和方法，無論是否需要它們，所有這些屬性和方法都將傳遞給其子類。

提示：如果您在視圖中使用類，則可能會發現程式碼無法編譯或在運行時崩潰。相信我：使用結構體。