一、SwiftUI用struct來表示view的原因

首先，涉及一個性能原理：結(jié)構(gòu)體比類更簡單，更輕量。之所以名列前茅個說這個原因，是因為大多數(shù)都認為這是 SwiftUI 采用結(jié)構(gòu)體的主要原因。其實，縱觀全局，這只是原因之一。

在 UIKit 中，所有的視圖都繼承自一個叫UIView的類，它有非常多的屬性和方法 —— 背景顏色，布局約束，用于渲染的層，等等。還有更多諸如此類的屬性，而每一個UIView和UIView的子類都有，因為這正是繼承的工作方式。

通常這樣也不會帶來問題，但有一個特殊的子類UIStackView，它和 SwiftUI 里的VStack和HStack相似。在UIKi 里，出于使布局更簡單的設(shè)計意圖，UIStackView是一個不會被渲染的視圖類型。但由于繼承機制，盡管它不渲染，它也有那些包括背景顏色在內(nèi)的各種用不上的屬性。

在 SwiftUI 中，所有的視圖都是細碎的結(jié)構(gòu)體，創(chuàng)建開銷幾乎可以忽略。 想象一下：你創(chuàng)建了一個結(jié)構(gòu)體，持有一個整數(shù)，整個結(jié)構(gòu)體的大小只有——那個整數(shù)，再無其他。沒有從父類、爺爺類、爺爺?shù)臓敔旑惸抢锢^承來的“意外財產(chǎn)”。它所包含的一切你都看得見。

得益于現(xiàn)代 iPhone 的能力，創(chuàng)建 1000 甚至 100,000 個整數(shù)只在眨眼之間。對于 SwiftUI 的 1000 個 view 或者 100,000 個 view。這個時間仍然成立。太快了，你都不必考慮它們。

不過，除了性能，用 struct 表示 view 還有其他重要原因：它強迫我們以一種更干凈的方式隔離狀態(tài)。類可以自由地修改它的值 —— 這可能導致更凌亂的代碼，這樣的話 SwiftUI 就無法通過某個值的變化來自動更新 UI 了。

通過創(chuàng)建不會跟隨時間改變的視圖，SwiftUI 鼓勵我們遷移到一種可以更好地工作的設(shè)計方式：視圖變簡單，變“蠢”，它只做把數(shù)據(jù)變成 UI 的事情，而不是滋生出控制邏輯這樣更“智能”的工作。

當你審視什么樣的東西在 SwiftUI 中可以作為一個 view 的時候，你就會發(fā)現(xiàn)前面說的方式正在運作。我們用?Color.red?和?LinearGradient?作為視圖 —— 一些存儲非常簡單數(shù)據(jù)的細碎類型。實際上，相對于把?Color.red?直接當成 view，你找不到更好的方案了。除了“把我的空間填滿紅色”，它沒有攜帶其他任何多余的信息。

作為比較，你可以看下 Apple 的UIView文檔。上面列出了200 多個UIView的屬性和方法 ——不管子類需不需要，都拿著。

提示:如果你試圖給你的 view 用上 class，那么代碼要么編譯不過要么就會崩潰。不要猶豫：用 struct 。

延伸閱讀：

二、視圖值樹是什么

在 SwiftUI 中，視圖是狀態(tài)的函數(shù)。

開發(fā)者通過符合 View 協(xié)議的結(jié)構(gòu)體來聲明界面，SwiftUI 通過調(diào)用結(jié)構(gòu)體實例的 body 獲取對應(yīng)的視圖值。body 則根據(jù)用戶的界面描述和對應(yīng)的依賴（Source of truth）計算結(jié)果。

在 app 運行后進行名列前茅次渲染時，SwiftUI 將依據(jù)類型樹按圖索驥，創(chuàng)建類型實例，實例的 body 根據(jù)初始狀態(tài)計算視圖值，并組織成視圖值樹。需要創(chuàng)建哪些實例，則是根據(jù)當時的狀態(tài)決定的，每次的狀態(tài)變化都可能會導致最終生成的視圖值樹不同（可能僅是某個節(jié)點的視圖值發(fā)生變化，也可能是視圖值樹的結(jié)構(gòu)都發(fā)生了巨大的變化）。

當 State 發(fā)生變化后，SwiftUI 會生成一棵新的視圖值樹（Source of truth 沒有發(fā)生變化的節(jié)點，不會重新計算，直接使用舊值），并同老的視圖值樹進行比對，SwiftUI 將對其中有變化的部分重新布局渲染，并用新生成的視圖值樹取代老的視圖值樹。

視圖值樹通常只保存當前布局、渲染所需的內(nèi)容（個別情況下，會緩存少數(shù)不參與布局、渲染的視圖值），在 app 的生命周期中，隨著 State 的變化而不斷地變化。