|
SwiftUI是一種新穎的構(gòu)建UI方式和全新的編碼風(fēng)格，本文以通俗易懂的語(yǔ)言，從Swift 5.1語(yǔ)法新特性和SwiftUI的優(yōu)勢(shì)方面進(jìn)行分享，希望對(duì)熱愛移動(dòng)端的同學(xué)有一定的幫助，讓大家盡可能快速、全面和透徹地理解SwiftUI。 一、背景蘋果于2019年度WWDC全球開發(fā)者大會(huì)上，發(fā)布了基于Swift建立的聲明式框架–SwiftUI，其可以用于watchOS、tvOS、macOS等蘋果旗下產(chǎn)品的應(yīng)用開發(fā)，統(tǒng)一了蘋果平臺(tái)的UI框架。 正如官網(wǎng)所言Better apps. Less code：用更少的代碼構(gòu)建更好的應(yīng)用。目前想要體驗(yàn)SwiftUI，需要以下的準(zhǔn)備：Xcode 11 beta和macOS Mojave or Higher，如果想要體驗(yàn)實(shí)時(shí)預(yù)覽和完整的Xcode 11功能，需要macOS 10.15 beta。 本文主要從以下三個(gè)方面講述SwiftUI的特性：
二、SwiftUI的特性本節(jié)對(duì)Opaque Result Type, PropertyDelegate, FunctionBuilder三個(gè)語(yǔ)法新特性進(jìn)行講解，結(jié)合部分偽代碼和數(shù)據(jù)流分析，由淺入深地理解，其在SwiftUI中的作用。 2.1 Opaque Result Type新建一個(gè)SwiftUI的新項(xiàng)目，會(huì)出現(xiàn)如下代碼：一個(gè)Text展示在body中。 struct ContentView : View {
var body: some View {
Text("Hello World")
}
}對(duì)于some View的出現(xiàn)，大家可能會(huì)覺(jué)得很突兀。一般情況下，閉包中返回的類型應(yīng)該是用來(lái)指定body的類型，如下代碼所示，如果閉包中只有一個(gè)Text，那么body的類型應(yīng)該就是Text。 struct ContentView : View {
var body: Text {
Text("Hello World")
}
}然而，很多時(shí)候在UI布局中是確定不了閉包中的具體類型，有可能是Text、Button、List等，為了解決這一問(wèn)題，就產(chǎn)生了Opaque Result Type。 其實(shí)View是SwiftUI一個(gè)核心的協(xié)議，代表了閉包中元素描述。如下代碼所示，其是通過(guò)一個(gè)associatedtype修飾的，帶有這種修飾的協(xié)議不能作為類型來(lái)使用，只能作為類型約束來(lái)使用。 通過(guò)Some View的修飾，其向編譯器保證：每次閉包中返回的一定是一個(gè)確定，而且遵守View協(xié)議的類型，不要去關(guān)心到底是哪種類型。這樣的設(shè)計(jì)，為開發(fā)者提供了一個(gè)靈活的開發(fā)模式，抹掉了具體的類型，不需要修改公共API來(lái)確定每次閉包的返回類型，也降低了代碼書寫難度。 public protocol View : _View {
associatedtype Body : View
var body: Self.Body { get }
}
2.2 PropertyDelegate復(fù)雜的UI結(jié)構(gòu)一直是前端布局的痛點(diǎn)，每次用戶交互或者數(shù)據(jù)發(fā)生改變，都需要及時(shí)更新UI，否則會(huì)引起某些顯示問(wèn)題。但是，在SwiftUI里面，視圖中聲明的任何狀態(tài)、內(nèi)容和布局，源頭一旦發(fā)生改變，會(huì)自動(dòng)更新視圖，因此，只需要一次布局。在屬性前面加上@State關(guān)鍵詞，即可實(shí)現(xiàn)每次數(shù)據(jù)改動(dòng)，UI動(dòng)態(tài)更新的效果。 @propertyDelegate public struct State<Value> : DynamicViewProperty, BindingConvertible 上述代碼中，一個(gè)@State關(guān)鍵詞繼承了DynamicViewProperty和BindingConvertible，BindingConvertible是對(duì)屬性值的綁定，DynamicViewProperty是動(dòng)態(tài)綁定了View和屬性。 也就是說(shuō)，聲明一個(gè)屬性時(shí)，SwiftUI會(huì)將當(dāng)前屬性的狀態(tài)與對(duì)應(yīng)視圖的綁定，當(dāng)屬性的狀態(tài)發(fā)生改變的時(shí)候，當(dāng)前視圖會(huì)銷毀以前的狀態(tài)并及時(shí)更新，下面具體分析一下這個(gè)過(guò)程。一般情況下實(shí)現(xiàn)一個(gè)String屬性的初始化，代碼如下： public struct MyValue {
var myValueStorage: String? = nil
public var myValue: String {
get {
myValue = myValueStorage
return myValueStorage
}
set {
myValueStorage = newValue
}
}
}如果代碼中有很多這樣的屬性，而且對(duì)某些屬性進(jìn)行特定的處理，上面的寫法無(wú)疑會(huì)產(chǎn)生很多冗余。屬性代理（propertyDelegate）的出現(xiàn)就是解決這個(gè)問(wèn)題的，屬性代理是一個(gè)泛型類型，不同類型的屬性都能夠通過(guò)該屬性代理進(jìn)行特定的處理： @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) // 建立視圖與數(shù)據(jù)依賴關(guān)系
return value
}
set {
if(storage != newValue){
storage = newValue
notify(to: swiftui) // 通知 SwiftUI 數(shù)據(jù)有變化
}
}
}
}上述代碼的功能如上圖所示。通過(guò)@propertyDelegate的修飾，能夠解決不同類型的value進(jìn)行特定的處理；上述包裝的方法，能夠建立視圖與數(shù)據(jù)之間的關(guān)系，并且會(huì)判斷在屬性值發(fā)生變化的情況下，通知SwiftUI刷新視圖，編譯器能夠?yàn)镾tring類型的myValue生成如下的代碼，經(jīng)過(guò)修飾后的代碼看起來(lái)很簡(jiǎn)潔。 public struct MyValue {
var $myValue: LateInitialized<String> = LateInitialized<String>()
public var myValue: String {
get { $myValue }
set { $myValue.value = newValue}
}
}接下來(lái)，我們看一下@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（一種屬性裝飾語(yǔ)法糖）來(lái)修飾State，內(nèi)部實(shí)現(xiàn)的大概就是在屬性Get、Set的時(shí)候，將部分可復(fù)用的代碼包裝起來(lái)，上文中說(shuō)的“屬性代理是一個(gè)泛型類型”正能夠高效的實(shí)現(xiàn)這部分功能。 @State內(nèi)部是在Get的時(shí)候建立數(shù)據(jù)源與視圖的關(guān)系，并且返回當(dāng)前的數(shù)據(jù)引用，使視圖能夠獲取，在Set方法中會(huì)監(jiān)聽數(shù)據(jù)發(fā)生變化、會(huì)通知SwiftUI重新獲取視圖body，再通過(guò)Function Builders方法重構(gòu)UI，繪制界面，在繪制過(guò)程中會(huì)自動(dòng)比較視圖中各個(gè)屬性是否有變化，如果發(fā)生變化，便會(huì)更新對(duì)應(yīng)的視圖，避免全局繪制，資源浪費(fèi)。 通過(guò)這種編程模式，SwiftUI幫助開發(fā)者建立了各種視圖和數(shù)據(jù)的連接，并且處理兩者之間的關(guān)系，開發(fā)者僅需要關(guān)注業(yè)務(wù)邏輯，其官方的數(shù)據(jù)結(jié)構(gòu)圖如下： 用戶交互過(guò)程中，會(huì)產(chǎn)生一個(gè)用戶的action，從上圖可以看出，在SwiftUI中數(shù)據(jù)的流轉(zhuǎn)過(guò)程如下：
以上就是SwiftUI的交互流程，其每一個(gè)節(jié)點(diǎn)之間的數(shù)據(jù)流轉(zhuǎn)都是單向、獨(dú)立的，無(wú)論應(yīng)用程序的邏輯變得多么復(fù)雜，該模式與Flux和Redux架構(gòu)的數(shù)據(jù)模式相類似。 內(nèi)部由無(wú)數(shù)這樣的單向數(shù)據(jù)流組合而成，每個(gè)數(shù)據(jù)流都遵循相應(yīng)的規(guī)范，這樣開發(fā)者在排查問(wèn)題的時(shí)候，不需要再去找所有與該數(shù)據(jù)相關(guān)的界面進(jìn)行排查，只需要找到相應(yīng)邏輯的數(shù)據(jù)流，分析數(shù)據(jù)在流程中運(yùn)轉(zhuǎn)是否正常即可。 不同場(chǎng)景中，SwiftUI提供了不同的關(guān)鍵詞，其實(shí)現(xiàn)原理上如上文所示：
以上特性的實(shí)現(xiàn)是基于Swift的Combine框架，下面簡(jiǎn)單介紹一下。該框架有兩個(gè)非常重要的概念，觀察者模式和響應(yīng)式編程。 觀察者模式是描述一對(duì)多關(guān)系：一個(gè)對(duì)象發(fā)生改變時(shí)將自動(dòng)通知其他對(duì)象，其他對(duì)象將相應(yīng)做出反應(yīng)。這兩類對(duì)象分別被稱為被觀察目標(biāo)和觀察者，一個(gè)觀察目標(biāo)可以對(duì)應(yīng)多個(gè)觀察者，觀察者可以訂閱它們感興趣的內(nèi)容，這也就是文中關(guān)鍵詞@State的實(shí)現(xiàn)來(lái)源，將屬性作為觀察目標(biāo)，觀察者是存在該屬性的多個(gè)View。 響應(yīng)式編程的核心是面向異步數(shù)據(jù)流和變化的，響應(yīng)式編程將所有事件轉(zhuǎn)成為異步的數(shù)據(jù)流，更加方便的對(duì)這些數(shù)據(jù)流進(jìn)行組合變換，最終只需要監(jiān)聽數(shù)據(jù)流的變化并做出處理即可，因此在SwiftUI中處理用戶交互和響應(yīng)等非常簡(jiǎn)潔。 2.3 FunctionBuilder在認(rèn)識(shí)FunctionBuilder之前，必須先了解一下ViewBuilder，其是用 @_functionBuilder來(lái)修飾的，編譯器會(huì)使用。并且對(duì)它所包含的方法有一定要求，其隱藏在各個(gè)容器類型的最后一個(gè)閉包參數(shù)中。下面具體介紹所謂的“要求”。 在組合視圖中，閉包中會(huì)處理大量的UI組件，F(xiàn)unctionBuilder是通過(guò)閉包建立樣式，將閉包中的UI描述傳遞給專門的構(gòu)造器，提供了類似DSL的開發(fā)模式。如下實(shí)現(xiàn)一個(gè)簡(jiǎn)單的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進(jìn)行修飾的，也就是通過(guò)functionBuilder對(duì)閉包表達(dá)式進(jìn)行了特殊處理，最終構(gòu)造出視圖。 init(alignment: VerticalAlignment = .center, spacing: Length? = nil, @ViewBuilder content: () -> Content) 如果沒(méi)有FunctionBuilder這一新特性，那么開發(fā)者必須對(duì)容器視圖進(jìn)行管理，以HStack為例（如下代碼所示）。若存在大量的表達(dá)式，無(wú)疑會(huì)讓開發(fā)者感覺(jué)到頭疼，而且代碼也會(huì)很雜亂，結(jié)構(gòu)也不夠清晰。 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修飾的內(nèi)容，均會(huì)實(shí)現(xiàn)一個(gè)構(gòu)造器，構(gòu)造器的功能如上述代碼所示。構(gòu)建器聲明幾種buildBlock方法用來(lái)構(gòu)造視圖，這幾種方法能夠滿足各種各樣的閉包表達(dá)式。下面是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在調(diào)用的時(shí)候，會(huì)按照上述合適的buildBlock進(jìn)行構(gòu)建視圖，將閉包中出現(xiàn)的Text或者其他的組件build成一個(gè)TupleView，并且返回。 但是，@_functionBuilder也存在一定局限性，ViewBuilder的buildBlock最多傳入十個(gè)參數(shù)，也就是布局中最多只能有十個(gè)View；如果超過(guò)十個(gè)View，可以考慮使用TupleView來(lái)用多元的方式合并View。 作為SwiftUI的新特點(diǎn)之一，F(xiàn)unctionBuilder傾向于目前流行的編程方式，開發(fā)者能夠使用基于DSL的架構(gòu)，像SwiftUI，而不用去考慮具體的實(shí)現(xiàn)細(xì)節(jié)，因?yàn)闃?gòu)建器實(shí)現(xiàn)的就是一個(gè)DSL本身。 三、Components本節(jié)通過(guò)DSL視圖的分析，分析SwfitUI在布局上的特點(diǎn)，以及利用該特點(diǎn)在組件化過(guò)程中的優(yōu)勢(shì)。 目前，組件化編程是主流的開發(fā)方式，SwfitUI帶來(lái)了全新的功能–可以構(gòu)建可重用的組件，采用了聲明式編程思想。將單一、簡(jiǎn)單的響應(yīng)視圖組合到繁瑣、復(fù)雜的視圖中去，而且在Apple的任何平臺(tái)上都能使用該組件，達(dá)到了跨平臺(tái)（僅限蘋果設(shè)備）的效果。按照用途大概能夠分為基礎(chǔ)組件、布局組件和功能組件。 更多的組件詳見 example link。 下面以一個(gè)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)
}
}其中包含了一個(gè)Button，其父視圖是一個(gè)ContenView，其實(shí)ContenView還會(huì)被一個(gè)RootView包含起來(lái)，RootView是SwiftUI在Window上創(chuàng)建出來(lái)了。通過(guò)簡(jiǎn)單的幾行代碼，設(shè)置了按鈕的點(diǎn)擊事件，樣式和文案。 其視圖DSL結(jié)構(gòu)如下圖所示，SwiftUI會(huì)直接讀取 DSL內(nèi)部描述信息并收集起來(lái)，然后轉(zhuǎn)換成基本的圖形單元，最終交給底層Metal或OpenGL渲染出來(lái)。 通過(guò)該結(jié)構(gòu)發(fā)現(xiàn)，與UIKit的布局結(jié)構(gòu)有很大的不同，像按鈕的一些屬性background、padding、cornerRadius等不應(yīng)該出現(xiàn)在視圖主結(jié)構(gòu)中，應(yīng)該出現(xiàn)在Button視圖的結(jié)構(gòu)中。 因?yàn)椋?SwiftUI中這些屬性的設(shè)置在內(nèi)部都會(huì)用一個(gè)View來(lái)承載，然后在布局的時(shí)候就會(huì)按照上面示例的布局流程，一層層View的計(jì)算布局下來(lái)，這樣做的優(yōu)點(diǎn)是：方便底層在設(shè)計(jì)渲染函數(shù)時(shí)更容易做到monomorphic call，省去無(wú)用的分支判斷，提高效率。 同時(shí)SwiftUI中也是支持frame設(shè)定，但也不會(huì)像UIKit中那樣作用于當(dāng)前元素，在內(nèi)部也是形成一個(gè)虛擬的View來(lái)承載frame設(shè)定，在布局過(guò)程中進(jìn)行frame計(jì)算最終顯示出想要的結(jié)果。 總之在SwiftUI中給一個(gè)View設(shè)置屬性，已經(jīng)不是為當(dāng)前元素提供約束，而是用一系列容器來(lái)包含當(dāng)前元素，為后續(xù)布局計(jì)算做準(zhǔn)備。 SwiftUI的界面不再像UIKit那樣，用ViewController 承載各種UIVew控件，而是一切皆View，所以可以把View切分成各種細(xì)致化的組件，然后通過(guò)組合的方式拼裝成最終的界面，這種視圖的拼裝方式提高了界面開發(fā)的靈活性和復(fù)用性。因此，視圖組件化是SwiftUI很大的亮點(diǎn)。 四、See it live in XcodeSwiftUI的Preview是Apple的一大突破，類似RN、Flutter的Hot Reloading。Apple選擇了直接在macOS上進(jìn)行渲染，不過(guò)需要搭載有SwiftUI.framework的macOS 10.15才能夠看到Xcode Previews界面。 Xcode將對(duì)代碼進(jìn)行靜態(tài)分析 (得益于SwiftSyntax框架)，找到所有遵守PreviewProvider 協(xié)議的類型進(jìn)行預(yù)覽渲染。在Xcode 11中提供了實(shí)時(shí)預(yù)覽和靜態(tài)預(yù)覽兩項(xiàng)功能，實(shí)時(shí)預(yù)覽：代碼的修改能夠?qū)崟r(shí)呈現(xiàn)在Xcode的預(yù)覽窗口中；此外，Xcdoe還提供了快捷功能，通過(guò)command+鼠標(biāo)點(diǎn)擊組件，可以快速、方便地添加組件和設(shè)置組件屬性。 五、暢想
作者介紹： 梁?jiǎn)⒔?，攜程金融支付中心開發(fā)工程師，主要負(fù)責(zé)支付iOS端的開發(fā)與優(yōu)化工作，喜歡研究大前端和跨平臺(tái)技術(shù)。 本文轉(zhuǎn)載自公眾號(hào)攜程技術(shù)中心（ID：ctriptech）原文鏈接 |
|
|
