關於swiftUI，看這一篇就夠了

時間  2020-07-04
標籤 關於 swiftui 看這 一篇 夠了 简体版
原文   原文鏈接

SwiftUI是一種新穎的構建UI方式和全新的編碼風格，本文以通俗易懂的語言，從Swift 5.1語法新特性和SwiftUI的優點方面進行分享，但願對熱愛移動端的同窗有必定的幫助，讓你們儘量快速、全面和透徹地理解SwiftUI。前端

1、背景

蘋果於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

  • 從代碼層面理解Swift 5.1新語法的底層實現；
  • 從數據流方面闡述SwiftUI的黑魔法；
  • 從佈局原理層面闡述SwiftUI組件化的優點；

2、SwiftUI的特性

本節對Opaque Result Type, PropertyDelegate, FunctionBuilder三個語法新特性進行講解，結合部分僞代碼和數據流分析，由淺入深地理解，其在SwiftUI中的做用。xcode

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修飾的，帶有這種修飾的協議不能做爲類型來使用，只能做爲類型約束來使用。app

經過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 Blocks
static 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自己。

3、Components

本節經過DSL視圖的分析，分析SwfitUI在佈局上的特色，以及利用該特色在組件化過程當中的優點。

目前，組件化編程是主流的開發方式，SwfitUI帶來了全新的功能–能夠構建可重用的組件，採用了聲明式編程思想。將單1、簡單的響應視圖組合到繁瑣、複雜的視圖中去，並且在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很大的亮點。

4、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+鼠標點擊組件，能夠快速、方便地添加組件和設置組件屬性。

5、暢想

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

做者介紹：

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

本文轉載自公衆號攜程技術中心（ID：ctriptech）原文連接
點擊此處，當即與iOS大牛交流學習

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程