系列文章深度解讀|SwiftUI 背後那些事兒

今年蘋果的WWDC你看了嗎？蘋果在2019年的WWDC的重頭戲當然非SwiftUI莫屬：全新的聲明式語法、綁定式API、和響應式變成框架Combine。這一切的一切都預示著即將在Apple Native布局系統掀起一場革命。為此，蘋果在很多方面都做了努力，這才促成了SwiftUI現在的樣子。想要了解Swift的新特性、SwiftUI數據流和SwiftUI布局系統等新知識嗎？一起來看吧。

Swift 5.1 新語法

單表達式隱式返回值

在 Swift 5.0 之前的語法中，如果一個閉包表達式只有一個表達式，那麼可以省略 return 關鍵字。現在 Swift 5.1 以後的版本中計算屬性和函數語句同樣適用。如：

// before swift 5.0

struct Rectangle {
var width = 0.0, height = 0.0
var area1: Double {
return width * height
}

func area2() -> Double {
return width * height
}
}

// after switft 5.1
struct Rectangle {
var width = 0.0, height = 0.0
var area1: Double { width * height }

func area2() -> Double { width * height }
}

關於這個新特性的完整提案可以參考（https://github.com/apple/Swift-evolution/blob/master/proposals/0255-omit-return.md）

根據結構體默認成員合成默認初始化器

在 Swift 5.0 之前結構體聲明，編譯器會默認生成一個逐一成員初始化器，同時如果都有默認值，還會生成一個無參的初始化器。但如果此時結構體成員屬性過多，且較多都有默認值，則只能使用逐一成員初始化器，會使每處調用的地方寫法過於冗餘，在傳統 OOP 語言中可以使用 Builder 模式解決，但在 Swift 5.1 之後編譯器會按需合成初始化器，避免初始化寫法的冗餘。如：

struct Dog { var name = "Generic dog name" var age = 0 } let boltNewborn = Dog() let daisyNewborn = Dog(name: "Daisy", age: 0) // before swift 5.0 ? let benjiNewborn = Dog(name: "Benji") // after switft 5.1 ? let benjiNewborn = Dog(name: "Benji")

關於這個新特性的完整提案可以參考（https://github.com/apple/Swift-evolution/blob/master/proposals/0242-default-values-memberwise.md）

字元串插入運算符新設計

這個特性主要擴大了字元串插入運算符的使用範圍，以前我們只能用在 String 的初始化中，但是不能在參數處理中使用字元串插入運算符。在以前的語法中只能分開書寫，雖然沒什麼大問題，但總歸要多一行代碼，現在可以直接使用了，尤其是對於 SwiftUI，Text 控制項就使用到了這種新語法，可以使我們在單行表達式中即可初始化 Tetx。

// before swift 5.0 ? let quantity = 10 label.text = NSLocalizedString( "You have (quantity) apples, comment: "Number of apples" )

label.text = String(format: formatString, quantity)

// after switft 5.1 ?
let quantity = 10
return Text(.
"You have (quantity) apples"
).

// 實際上編譯器會翻譯為如下幾句
var builder = LocalizedStringKey.StringInterpolation(
literalCapacity: 16, interpolationCount: 1
)
builder.appendLiteral("You have ")
builder.appendInterpolation(quantity)
builder.appendLiteral(" apples")
LocalizedStringKey(stringInterpolation: builder)

關於這個新特性的完整提案可以參考（https://github.com/apple/Swift-evolution/blob/master/proposals/0228-fix-expressiblebystringinterpolation.md）

屬性包裝器

當我們在一個類型中聲明計算屬性時，大部分屬性的訪問和獲取都是有相同的用處，這些代碼是可抽取的，如我們標記一些用戶偏好設置，在計算屬性的設置和獲取中直接代理到 UserDefault的實現中，我們可以通過聲明 @propertyWarpper 來修飾，可以減少大量重複代碼。在 SwiftUI中， @State @EnviromemntObject @bindingObject @Binding 都是通過屬性包裝器代理到 SwiftUI 框架中使其自動響應業務狀態的變化。

// before swift 5.0 ? struct User { static var usesTouchID: Bool { get { return UserDefaults.standard.bool(forKey: "USES_TOUCH_ID") } set { UserDefaults.standard.set(newValue, forKey: "USES_TOUCH_ID") } } static var isLoggedIn: Bool { get { return UserDefaults.standard.bool(forKey: "LOGGED_IN") } set { UserDefaults.standard.set(newValue, forKey: "LOGGED_IN") } } }

// after switft 5.1 ?
@propertyWrapper
struct UserDefault<T> {
let key: String
let defaultValue: T
init(_ key: String, defaultValue: T) {
print("UserDefault init")
self.key = key
self.defaultValue = defaultValue
UserDefaults.standard.register(defaults: [key: defaultValue])
}
var value: T {
get {
print("getter")
return UserDefaults.standard.object(forKey: key) as? T ?? defaultValue
}
set {
print("setter")
UserDefaults.standard.set(newValue, forKey: key)
}
}
}
struct User2 {
@UserDefault("USES_TOUCH_ID", defaultValue: false)
static var usesTouchID: Bool
@UserDefault("LOGGED_IN", defaultValue: false)
var isLoggedIn: Bool
}

print("hello world")
let user = User2()
User2.usesTouchID = true
let delegate = User2.$usesTouchID
print("(delegate)")
let detelate2 = user.$isLoggedIn

實際上屬性包裝器是在編譯時期翻譯為以下的代碼, 並且編譯器禁止使用 $ 開頭的標識符。

struct User2 { static var $usesTouchID = UserDefault<Bool>("USES_TOUCH_ID", defaultValue: false) static var usesTouchID: Bool { set { $usesTouchID.value = newValue } get { $usesTouchID.value } } @UserDefault("LOGGED_IN", defaultValue: false) var isLoggedIn: Bool }

使用屬性包裝器的好處除了可以減少重複代碼，Swift Runtime 還保證了以下幾點：

對於實例的屬性包裝器是即時載入的
對於類屬性的屬性保證器是懶載入的
屬性包裝器是線程安全的
通過 $ 運算符可以獲取到原始的屬性包裝器實例，這大量使用在 SwiftUI 的數據依賴中

關於這個新特性的完整提案可以參考（https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md）

註：在目前的 Beta 版本中 @PropertyDelegate 和 @PropertyWrapper 是一致的，正式版本發布會應該只會保留一種語法。

不透明返回類型

在 Swift 5.0 之前我們如果想返回抽象類型一般使用 Generic Type 或者 Protocol, 使用泛型會顯示的暴露一些信息給 API 使用者，不是完整的類型抽象。但是使用 Protocol 也有幾個限制: 泛型返回值在運行時都是一個容器，效率較差，返回值不能調用自身類型的方法，協議不允許擁有關聯類型，由於編譯時丟失了類型信息，編譯器無法推斷類型，導致無法使用 == 運算符。

在 Swift 5.1 中新增了 opaque result type，這個特性使用 some 修飾協議返回值，具有以下特性：

所有的條件分支只能返回一個特定類型，不同則會編譯報錯
方法使用者依舊無法知道類型，（使用方不透明）
編譯器知情具體類型，因此可以使用類型推斷。

// before swift 5.0 ? public protocol View : _View { associatedtype Body : View

var body: Self.Body { get }
}
// compile error
func getText() -> View {
return Text("")
}

func getText<T: Text>() -> T {
return Text("")
}
// after switft 5.1 ?
struct ContentView: View {
var body: some View {
Text("")
}
}

關於這個新特性的完整提案可以參考（https://github.com/apple/Swift-evolution/blob/master/proposals/0244-opaque-result-types.md）

Swift Style DSL / Function Builder

此項提案是一個比較特殊的提案，原因在於目前還在審核中，並沒有正式加入 Swift 語言中，但是 Xcode11 自帶的 Swift 5.1 已經集成了這項語法. 使用 Function Builder 可以使表達式語句隱含的返回在函數返回值中，這樣可以在嵌套邏輯和返回值表達式的 DSL 中十分具有表現力。如下面的語句是等同的：

// Original source code: @TupleBuilder func build() -> (Int, Int, Int) { 1 2 3 }

// This code is interpreted exactly as if it were this code:
func build() -> (Int, Int, Int) {
let _a = 1
let _b = 2
let _c = 3
return TupleBuilder.buildBlock(_a, _b, _c)
}

在 SwiftUI 中的所有布局類控制項，幾乎全部使用了 Function Builder 特性，可讀性要遠遠大於 Flutter 的 DSL語法，以下是一個蘋果 WWDC Session 的例子。

head { meta().charset("UTF-8") if cond { title("Title 1") } else { title("Title 2") } }

實際上會被翻譯為
head {
let a: HTML = meta().charset("UTF-8")
let d: HTML
if cond {
let b: HTML = title("Title 1")
d = HTMLBuilder.buildEither(first: b)
} else {
let c: HTML = title("Title 2")
d = HTMLBuilder.buildEither(second: c)
}
return HTMLBuilder.buildBlock(a, d)
}

可讀性大大加強，但值得注意的是目前在 SwiftUI 中使用 Function Builder 實現的 ViewBuilder 功能僅僅支持 10 個泛型參數，在 SwiftUI 中，如果同級別元素中，超過 10 個則會有奇怪的編譯錯誤。

這點官方推薦使用組合降低 View 結構，這點和 Flutter 的推薦寫法不同，超過 10 個則會編譯錯誤 -_-。

目前這份提議[function-builders.md](https://github.com/apple/swift-evolution/blob/9992cf3c11c2d5e0ea20bee98657d93902d5b174/proposals/XXXX-function-builders.md)，還在草案階段，所以實現是一份下劃線關鍵字。

不排除蘋果會在 9月份正式版本來臨之前稍加修改語法，但相信這份功能的放開也會在正式版本發布之期修改完畢。

其他新特性

本文主要介紹了一些新的語法特性，且大部分都和 SwiftUI 相關，從 WWDC 的Session 演講者都透露出 Swift 語言組的核心目標，Make Your Swift API Better

主要從以下幾個體現。

Expressive 有表現力
Clear 清晰沒二義性
Easy to use 簡單易用

本文還有大量的 Swift 5.1 新特性沒有提到，如 @dynamicCallable @dynamicMemberLookup WritableKeyPath 有興趣的讀者可以參考 Swift的完整演變提案 swift-evolution。（https://github.com/apple/swift-evolution/tree/master/proposals）

Swift 從 3.x Attribute

Swift 自 3.0 版本至今添加了很多屬性（Attribut）標記，這些 Attribute 通過給編譯器提供信息，增強了 Swift 的元編程能力，如果讀者有興趣可以參考這份完整的正式版本 Attribute大全。（https://docs.swift.org/swift-book/ReferenceManual/Attributes.html）

Swift/SwiftUI API Design Guide

Swift 已經經過 9（4年內部孵化）個年頭的發展，語言的設計指南已經區域問題，其中涉及到了很多不同於其他語言的觀點，今年的 Session 著重的梳理了以下幾點。

值類型和引用類型

當你設計一個數據結構時，優先選擇結構體或者枚舉，它們都是值類型，值類型具有以下幾個有點。

1.值類型在棧上分配，性能要遠遠大於引用類型，且 Swift Runtime 有 COW 優化。

2.值類型沒有引用計數，不會引起奇怪的多線程安全問題。

3.值類型的存儲屬性是扁平化的，避免在類繼承情況下一個子類繼承過多的存儲屬性導致實例在內存中過大，如 SwiftUI 使用 Modifier的結構體優化設計。

那什麼時候我們才需要使用引用類型呢？只有當以下幾個場景存在時才有必要使用。

你需要引用計數和構造和析構的時機。
數據需要集中管理或共享，如單例或者數據緩存實例等。
ID 語義和 Equal語義衝突的時候。

協議還是泛型

隨著 Swift 中 POP 的流行，很多人涉及 API 越來越習慣使用協議，但是官方指出設計的要點， 設計是演進的而不是一步到位的，應該遵守以下步驟。

1、不要直接聲明協議

2、從實際的業務場景出發

3、從中抽象出公用代碼

4、從已有的協議中組合協議，而不是重新構建一套新的協議結構

DynamicMemberLookup & dynamicCallable

這個語法其實是 Swift 4.2 的老語法了，但是在 Xcode11 中， IDE進一步獲得了增強，可以輕鬆獲得代碼提示，如果使用過 ruby 和 python的開發者，可以輕易地理解，把一個實例當方法調用，靜態語言在保證安全的前提下可以通過編譯，並可以動態調用，相信未來在和其他語言互通時可以大方光彩。

抽象數據訪問

前面已經介紹過來 Swift 5.1 新增語法 PropertyWarpper, 在 Swift 中很多計算屬性都圍繞著數據訪問如懶載入，防禦性複製，TLS數據區，而它們的模式都是一致的，多使用 PropertyWarpper 可以抽象公用代碼，加強 API 語義。在 SwiftUI 中核心的數據流，均使用 PropertyWarpper 如 @Binding @State @EnviromentObject @Enviroment。