SwiftUI是一種新穎的構建UI方式和全新的編碼風格，本文以通俗易懂的語言，從Swift 5.1語法新特性和SwiftUI的優勢方面進行分享，希望對熱愛移動端的同學有一定的幫助，讓大家儘可能快速、全面和透徹地理解SwiftUI。

一、背景

蘋果於2019年度WWDC全球開發者大會上，釋出了基於Swift建立的宣告式框架–SwiftUI，其可以用於watchOS、tvOS、macOS等蘋果旗下產品的應用開發，統一了蘋果平臺的UI框架。

正如官網所言Better apps. Less code：用更少的程式碼構建更好的應用。目前想要體驗SwiftUI，需要以下的準備：Xcode 11 beta和macOS Mojave or Higher，如果想要體驗實時預覽和完整的Xcode 11功能，需要macOS 10.15 beta。

本文主要從以下三個方面講述SwiftUI的特性：

從程式碼層面理解Swift 5.1新語法的底層實現；
從資料流方面闡述SwiftUI的黑魔法；
從佈局原理層面闡述SwiftUI元件化的優勢；

二、SwiftUI的特性

本節對Opaque Result Type, PropertyDelegate, FunctionBuilder三個語法新特性進行講解，結合部分虛擬碼和資料流分析，由淺入深地理解，其在SwiftUI中的作用。

2.1 Opaque Result Type

新建一個SwiftUI的新專案，會出現如下程式碼：一個Text展示在body中。

struct ContentView : View { 
      var body: some View { 
            Text("Hello World") 
      } }

對於some View的出現，大家可能會覺得很突兀。一般情況下，閉包中返回的型別應該是用來指定body的型別，如下程式碼所示，如果閉包中只有一個Text，那麼body的型別應該就是Text。

struct ContentView : View { 
      var body: Text { 
            Text("Hello World") 
      } }

然而，很多時候在UI佈局中是確定不了閉包中的具體型別，有可能是Text、Button、List等，為了解決這一問題，就產生了Opaque Result Type。

其實View是SwiftUI一個核心的協議，代表了閉包中元素描述。如下程式碼所示，其是透過一個associatedtype修飾的，帶有這種修飾的協議不能作為型別來使用，只能作為型別約束來使用。

透過Some View的修飾，其向編譯器保證：每次閉包中返回的一定是一個確定，而且遵守View協議的型別，不要去關心到底是哪種型別。這樣的設計，為開發者提供了一個靈活的開發模式，抹掉了具體的型別，不需要修改公共API來確定每次閉包的返回型別，也降低了程式碼書寫難度。

public protocol View : _View { 
       associatedtype Body : View 
       var body: Self.Body { get } }

這是我的iOS開發交流群： 519832104不管你是小白還是大牛歡迎入駐，可以一起分享經驗，討論技術，共同學習成長！
另附上一份各好友收集的大廠面試題，需要iOS開發學習資料、面試真題，進群即可自行下載！

點選此處，立即與iOS大牛交流學習

2.2 PropertyDelegate

複雜的UI結構一直是前端佈局的痛點，每次使用者互動或者資料發生改變，都需要及時更新UI，否則會引起某些顯示問題。但是，在SwiftUI裡面，檢視中宣告的任何狀態、內容和佈局，源頭一旦發生改變，會自動更新檢視，因此，只需要一次佈局。在屬性前面加上@State關鍵詞，即可實現每次資料改動，UI動態更新的效果。

@propertyDelegate public struct State<Value> : DynamicViewProperty, BindingConvertible

上述程式碼中，一個@State關鍵詞繼承了DynamicViewProperty和BindingConvertible，BindingConvertible是對屬性值的繫結，DynamicViewProperty是動態繫結了View和屬性。

也就是說，宣告一個屬性時，SwiftUI會將當前屬性的狀態與對應檢視的繫結，當屬性的狀態發生改變的時候，當前檢視會銷燬以前的狀態並及時更新，下面具體分析一下這個過程。一般情況下實現一個String屬性的初始化，程式碼如下：

public struct MyValue { 
    var myValueStorage: String? = nil
    public var myValue: String { 
        get { 
            myValue = myValueStorage 
            return myValueStorage 
        } 
        set { 
           myValueStorage = newValue 
        }
    } }

如果程式碼中有很多這樣的屬性，而且對某些屬性進行特定的處理，上面的寫法無疑會產生很多冗餘。屬性代理（propertyDelegate）的出現就是解決這個問題的，屬性代理是一個泛型型別，不同型別的屬性都能夠透過該屬性代理進行特定的處理：

@propertyDelegate public struct LateInitialized<Value> {
  private var storage: Value?
  
  public init() {
    storage = nil  }
  
  public var value: Value {
    get{
      guard let value = storage 
      createDependency(view, value) // 建立檢視與資料依賴關係
      return value
    }
    set {
      if(storage != newValue){
        storage = newValue        notify(to: swiftui) // 通知 SwiftUI 資料有變化
      }
    }
  }}

上述程式碼的功能如上圖所示。透過@propertyDelegate的修飾，能夠解決不同型別的value進行特定的處理；上述包裝的方法，能夠建立檢視與資料之間的關係，並且會判斷在屬性值發生變化的情況下，通知SwiftUI重新整理檢視，編譯器能夠為String型別的myValue生成如下的程式碼，經過修飾後的程式碼看起來很簡潔。

public struct MyValue {
  var $myValue: LateInitialized<String> = LateInitialized<String>()
  public var myValue: String {
      get { $myValue }
      set { $myValue.value = newValue}
  }}

接下來，我們看一下@State的原始碼：

@available(iOS 13.0, OSX 10.15, tvOS 13.0, watchOS 6.0, *)@propertyDelegate public struct State<Value> : DynamicViewProperty, BindingConvertible {
    /// Initialize with the provided initial value.
    public init(initialValue value: Value)
    /// The current state value.
    public var value: Value { get nonmutating set }
    /// Returns a binding referencing the state value.
    public var binding: Binding<Value> { get }
    /// Produces the binding referencing this state value
    public var delegateValue: Binding<Value> { get }
    /// Produces the binding referencing this state value
    /// TODO: old name for storageValue, to be removed
    public var storageValue: Binding<Value> { get }}@available(iOS 13.0, OSX 10.15, tvOS 13.0, watchOS 6.0, *)extension State where Value : ExpressibleByNilLiteral {
    /// Initialize with a nil initial value.
    @inlinable public init()}

Swift 5.1的新特性Property Wrappers（一種屬性裝飾語法糖）來修飾State，內部實現的大概就是在屬性Get、Set的時候，將部分可複用的程式碼包裝起來，上文中說的“屬性代理是一個泛型型別”正能夠高效的實現這部分功能。

@State內部是在Get的時候建立資料來源與檢視的關係，並且返回當前的資料引用，使檢視能夠獲取，在Set方法中會監聽資料發生變化、會通知SwiftUI重新獲取檢視body，再透過Function Builders方法重構UI，繪製介面，在繪製過程中會自動比較檢視中各個屬性是否有變化，如果發生變化，便會更新對應的檢視，避免全域性繪製，資源浪費。

透過這種程式設計模式，SwiftUI幫助開發者建立了各種檢視和資料的連線，並且處理兩者之間的關係，開發者僅需要關注業務邏輯，其官方的資料結構圖如下：

使用者互動過程中，會產生一個使用者的action，從上圖可以看出，在SwiftUI中資料的流轉過程如下：

該行為觸發資料改變，並透過@State資料來源進行包裝；
@State檢測到資料變化，觸發檢視重繪；
SwiftUI內部按上述所說的邏輯，判斷對應檢視是否需要更新UI，最終再次呈現給使用者，等待互動；

以上就是SwiftUI的互動流程，其每一個節點之間的資料流轉都是單向、獨立的，無論應用程式的邏輯變得多麼複雜，該模式與Flux和Redux架構的資料模式相類似。

內部由無數這樣的單向資料流組合而成，每個資料流都遵循相應的規範，這樣開發者在排查問題的時候，不需要再去找所有與該資料相關的介面進行排查，只需要找到相應邏輯的資料流，分析資料在流程中運轉是否正常即可。

不同場景中，SwiftUI提供了不同的關鍵詞，其實現原理上如上文所示：

@State - 檢視和資料存在依賴，資料變化要同步到檢視；
@Binding - 父子檢視直接有資料的依賴，資料變化要同步到父子檢視；
@BindableObject - 外部資料結構與SwiftUI建立資料存在依賴；
@EnvironmentObject - 跨元件快速訪問全域性資料來源；

以上特性的實現是基於Swift的Combine框架，下面簡單介紹一下。該框架有兩個非常重要的概念，觀察者模式和響應式程式設計。

觀察者模式是描述一對多關係：一個物件發生改變時將自動通知其他物件，其他物件將相應做出反應。這兩類物件分別被稱為被觀察目標和觀察者，一個觀察目標可以對應多個觀察者，觀察者可以訂閱它們感興趣的內容，這也就是文中關鍵詞@State的實現來源，將屬性作為觀察目標，觀察者是存在該屬性的多個View。

響應式程式設計的核心是面向非同步資料流和變化的，響應式程式設計將所有事件轉成為非同步的資料流，更加方便的對這些資料流進行組合變換，最終只需要監聽資料流的變化並做出處理即可，因此在SwiftUI中處理使用者互動和響應等非常簡潔。

2.3 FunctionBuilder

在認識FunctionBuilder之前，必須先了解一下ViewBuilder，其是用 @_functionBuilder來修飾的，編譯器會使用。並且對它所包含的方法有一定要求，其隱藏在各個容器型別的最後一個閉包引數中。下面具體介紹所謂的“要求”。

在組合檢視中，閉包中會處理大量的UI元件，FunctionBuilder是透過閉包建立樣式，將閉包中的UI描述傳遞給專門的構造器，提供了類似DSL的開發模式。如下實現一個簡單的View：

struct RowCell : View {
    let image : UIImage    let title : String    let tip : String
    
    var body: some View {
        HStack{
            Image(uiImage: image)
            Text(title)
            Text(tip)
        }
    }}

檢視HStack的初始化程式碼，如下所示：其最後的content是用ViewBuilder進行修飾的，也就是透過functionBuilder對閉包表示式進行了特殊處理，最終構造出檢視。

init(alignment: VerticalAlignment = .center, spacing: Length? = nil, @ViewBuilder content: () -> Content)

如果沒有FunctionBuilder這一新特性，那麼開發者必須對容器檢視進行管理，以HStack為例（如下程式碼所示）。若存在大量的表示式，無疑會讓開發者感覺到頭疼，而且程式碼也會很雜亂，結構也不夠清晰。

struct RowCell : View {
    let image : UIImage
    let title : String
    let tip : String
    
    var body: some View {
        var builder = HStackBuilder()
        builder.add(Image(uiImage: image))
        builder.add(Text(title))
        builder.add(Text(tip))
        return builder.build()
    }}

用@_functionBuilder修飾的內容，均會實現一個構造器，構造器的功能如上述程式碼所示。構建器宣告幾種buildBlock方法用來構造檢視，這幾種方法能夠滿足各種各樣的閉包表示式。下面是SwiftUI的ViewBuilder幾種方法：

Building Blocksstatic func buildBlock() -> EmptyView//Builds an empty view from a block containing no statements.static func buildBlock<Content>(Content) -> Content//Passes a single view written as a child view through unmodified.static func buildBlock<C0, C1>(C0, C1) -> TupleView<(C0, C1)>static func buildBlock<C0, C1, C2>(C0, C1, C2) -> TupleView<(C0, C1, C2)>static func buildBlock<C0, C1, C2, C3>(C0, C1, C2, C3) -> TupleView<(C0, C1, C2, C3)>...

上文被ViewBuilder修飾的content，content在呼叫的時候，會按照上述合適的buildBlock進行構建檢視，將閉包中出現的Text或者其他的元件build成一個TupleView，並且返回。

但是，@_functionBuilder也存在一定侷限性，ViewBuilder的buildBlock最多傳入十個引數，也就是佈局中最多隻能有十個View；如果超過十個View，可以考慮使用TupleView來用多元的方式合併View。

作為SwiftUI的新特點之一，FunctionBuilder傾向於目前流行的程式設計方式，開發者能夠使用基於DSL的架構，像SwiftUI，而不用去考慮具體的實現細節，因為構建器實現的就是一個DSL本身。

三、Components

本節透過DSL檢視的分析，分析SwfitUI在佈局上的特點，以及利用該特點在元件化過程中的優勢。

目前，元件化程式設計是主流的開發方式，SwfitUI帶來了全新的功能–可以構建可重用的元件，採用了宣告式程式設計思想。將單一、簡單的響應檢視組合到繁瑣、複雜的檢視中去，而且在Apple的任何平臺上都能使用該元件，達到了跨平臺（僅限蘋果裝置）的效果。按照用途大概能夠分為基礎元件、佈局元件和功能元件。

更多的元件詳見 example link。

下面以一個Button為例子：

struct ContentView : View {
    var body: some View {
        Button(action: {
            // did tap
        },label: {Text("Click me")}
        )
        .foregroundColor(Color.white)
        .cornerRadius(5)
        .padding(20)
        .background(Color.blue)
    }}

其中包含了一個Button，其父檢視是一個ContenView，其實ContenView還會被一個RootView包含起來，RootView是SwiftUI在Window上建立出來了。透過簡單的幾行程式碼，設定了按鈕的點選事件，樣式和文案。

其檢視DSL結構如下圖所示，SwiftUI會直接讀取 DSL內部描述資訊並收集起來，然後轉換成基本的圖形單元，最終交給底層Metal或OpenGL渲染出來。

透過該結構發現，與UIKit的佈局結構有很大的不同，像按鈕的一些屬性background、padding、cornerRadius等不應該出現在檢視主結構中，應該出現在Button檢視的結構中。

因為，在 SwiftUI中這些屬性的設定在內部都會用一個View來承載，然後在佈局的時候就會按照上面示例的佈局流程，一層層View的計算佈局下來，這樣做的優點是：方便底層在設計渲染函式時更容易做到monomorphic call，省去無用的分支判斷，提高效率。

同時SwiftUI中也是支援frame設定，但也不會像UIKit中那樣作用於當前元素，在內部也是形成一個虛擬的View來承載frame設定，在佈局過程中進行frame計算最終顯示出想要的結果。

總之在SwiftUI中給一個View設定屬性，已經不是為當前元素提供約束，而是用一系列容器來包含當前元素，為後續佈局計算做準備。

SwiftUI的介面不再像UIKit那樣，用ViewController 承載各種UIVew控制元件，而是一切皆View，所以可以把View切分成各種細緻化的元件，然後透過組合的方式拼裝成最終的介面，這種檢視的拼裝方式提高了介面開發的靈活性和複用性。因此，檢視元件化是SwiftUI很大的亮點。

四、See it live in Xcode

SwiftUI的Preview是Apple的一大突破，類似RN、Flutter的Hot Reloading。Apple選擇了直接在macOS上進行渲染，不過需要搭載有SwiftUI.framework的macOS 10.15才能夠看到Xcode Previews介面。

Xcode將對程式碼進行靜態分析 (得益於SwiftSyntax框架)，找到所有遵守PreviewProvider 協議的型別進行預覽渲染。在Xcode 11中提供了實時預覽和靜態預覽兩項功能，實時預覽：程式碼的修改能夠實時呈現在Xcode的預覽視窗中；此外，Xcdoe還提供了快捷功能，透過command+滑鼠點選元件，可以快速、方便地新增元件和設定元件屬性。

五、暢想

SwiftUI不僅為Apple的平臺帶來了一種新的構建UI的方式，還有全新的Swift編碼風格；
可以推斷出：SwiftUI會出現很多元件庫，方便前端開發；
支援熱更新，這一點可能讓更多的開發者擁抱SwiftUI；
雖然SwiftUI優點很多，但是其使用的門檻很高，只能在iOS 13以上的系統使用；僅這點，很多公司和開發者望而卻步，目前主流應用最低支援iOS 9，至少3年之內，SwiftUI只能作為一個理論的知識儲備，所以其還有很長的路要走；
SwiftUI這種與平臺無關、純描述的UI框架，恰恰是跨平臺方案的正確方向，將來其能否統一整個大前端呢？這點非常值得期待；

作者介紹：

梁啟健，攜程金融支付中心開發工程師，主要負責支付iOS端的開發與最佳化工作，喜歡研究大前端和跨平臺技術。

本文轉載自公眾號攜程技術中心（ID：ctriptech）原文連結

點選此處，立即與iOS大牛交流學習

關於SwiftUI，看這一篇就夠了