一、SwiftUI用struct來表示view的原因
首先,涉及一個性能原理:結(jié)構(gòu)體比類更簡單,更輕量。之所以名列前茅個說這個原因,是因為大多數(shù)都認(rèn)為這是 SwiftUI 采用結(jié)構(gòu)體的主要原因。其實,縱觀全局,這只是原因之一。
在 UIKit 中,所有的視圖都繼承自一個叫UIView的類,它有非常多的屬性和方法 —— 背景顏色,布局約束,用于渲染的層,等等。還有更多諸如此類的屬性,而每一個UIView和UIView的子類都有,因為這正是繼承的工作方式。
通常這樣也不會帶來問題,但有一個特殊的子類UIStackView,它和 SwiftUI 里的VStack和HStack相似。在UIKi 里,出于使布局更簡單的設(shè)計意圖,UIStackView是一個不會被渲染的視圖類型。但由于繼承機(jī)制,盡管它不渲染,它也有那些包括背景顏色在內(nèi)的各種用不上的屬性。
在 SwiftUI 中,所有的視圖都是細(xì)碎的結(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 還有其他重要原因:它強(qiáng)迫我們以一種更干凈的方式隔離狀態(tài)。類可以自由地修改它的值 —— 這可能導(dǎo)致更凌亂的代碼,這樣的話 SwiftUI 就無法通過某個值的變化來自動更新 UI 了。
通過創(chuàng)建不會跟隨時間改變的視圖,SwiftUI 鼓勵我們遷移到一種可以更好地工作的設(shè)計方式:視圖變簡單,變“蠢”,它只做把數(shù)據(jù)變成 UI 的事情,而不是滋生出控制邏輯這樣更“智能”的工作。
當(dāng)你審視什么樣的東西在 SwiftUI 中可以作為一個 view 的時候,你就會發(fā)現(xiàn)前面說的方式正在運作。我們用?Color.red?和?LinearGradient?作為視圖 —— 一些存儲非常簡單數(shù)據(jù)的細(xì)碎類型。實際上,相對于把?Color.red?直接當(dāng)成 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 運行后進(jìn)行名列前茅次渲染時,SwiftUI 將依據(jù)類型樹按圖索驥,創(chuàng)建類型實例,實例的 body 根據(jù)初始狀態(tài)計算視圖值,并組織成視圖值樹。需要創(chuàng)建哪些實例,則是根據(jù)當(dāng)時的狀態(tài)決定的,每次的狀態(tài)變化都可能會導(dǎo)致最終生成的視圖值樹不同(可能僅是某個節(jié)點的視圖值發(fā)生變化,也可能是視圖值樹的結(jié)構(gòu)都發(fā)生了巨大的變化)。
當(dāng) State 發(fā)生變化后,SwiftUI 會生成一棵新的視圖值樹(Source of truth 沒有發(fā)生變化的節(jié)點,不會重新計算,直接使用舊值),并同老的視圖值樹進(jìn)行比對,SwiftUI 將對其中有變化的部分重新布局渲染,并用新生成的視圖值樹取代老的視圖值樹。
視圖值樹通常只保存當(dāng)前布局、渲染所需的內(nèi)容(個別情況下,會緩存少數(shù)不參與布局、渲染的視圖值),在 app 的生命周期中,隨著 State 的變化而不斷地變化。