一、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 的變化而不斷地變化。

上一篇

C/S和B/S架構的工作原理及優缺點?

下一篇

創建Project提交到Github需要做什么?