前言: iOS開發者的UI開發體驗一直在大前端中體驗是比較差的, 原始的Frame布局系統, API比較難用的Autolayout, 性能相對較差的Xib, SB, 而對于基礎的業務開發, UI的開發又占用了大量的時間, 但是在2019 WWDC上Apple給我們帶來了新的布局方式 “SwiftUI”; SwiftUI對大量的UI控件進行了重新"定義" Text, Button, List等等

相較于前兩篇, 這篇進行了深入的探討了SwiftUI, 在新版本編譯器上的表現, 數據流是什么, 以及SwiftUI2.0的重大變革等

1. SwiftUI的優缺點

1.1 SwiftUI的優勢

• 聲明式UI語法
• 亞秒級別的實時刷新
• 官方原生的大力支持
• 實時預覽功能, 可視化修改增刪代碼

1.2 SwiftUI的劣勢

• iOS13以后支持
• API的不穩定性

2. 語法細節-聲明式語法

struct TextTest: View {
    var body: some View {
        VStack(spacing: 15) {
            Text("SwiftUI")
            Text("SwiftUI")
                .foregroundColor(.orange)
                .bold()
                .font(.system(.largeTitle))
                .fontWeight(.medium)
                .italic()
                .shadow(color: .black, radius: 1, x: 0, y: 2)
            
            Text(summerxx)
                .underline(true, color: Color.gray)
                .font(.system(size: 16, design: .serif)).onTapGesture {
                    print(summerxx)
            }
            
            HStack {
                Text("Text")
                Text("Text.bold").bold()
                Text("SecureField").foregroundColor(.orange)
            }
            
            Text("Views and controls are the visual building blocks of your app’s user interface." +
                " Use them to present your app’s content onscreen.")
                .lineLimit(nil)
        }
    }
}

• 同是聲明式布局, Flutter給人眼花繚亂的感覺, 而Swift 的 View 組合并不是由, 分割，而是由換行分割，在 Swift 中 函數調用是可以換行分割的。這樣的方式對開發者的體驗更為友好

3. 實時預覽

曾經我是很羨慕前端的同學實時預覽的, 有時候一個項目編譯鏈接要幾分鐘, 我寫一個UI效果想看看很令人頭大, 但是現在Apple平臺上也擁有了同樣的方式, 這次 蘋果官方 給開發者帶來了此項功能。

• MacOS catalina Xcode11以上, SwiftUI就可以嘗鮮此項功能可以實時預覽

• 自動填充代碼, 大大的方便了廣大開發者. 淚目.GIF

• 可以通過 Group 功能同時預覽多個設備，多個不同的環境

備注: SwiftUI 可以在 Xcode 里面直接切換 LiveMode 可以不運行設備直接進入交互模式，再具有多個預覽設備時可以很方便的動態調試 UI 布局。如何進入多設備預覽模式? 代碼如下:

struct TextTest_Previews: PreviewProvider {
    static var previews: some View {
        Group {
            TextTest()
                .previewDevice("iPhone 8")
            TextTest()
                .previewDevice("iPhone 11 Pro Max")
        }
    }
}

4. Xcode Library

在編寫真實項目中，一個公司的 APP UI 包含成百上千種風格的 View 組件，對于 UI 組件豐富的產品，如果一個新需求可以由現有的組件組合，那么需求交付的時間也會大大縮短。
但是對于一個大型的開發團隊而言，一個開發同學是很難知道公司內到底有多少種組件庫，而且即便知道有某種組件庫，開發同學初期看到的也是代碼，找到合適的還是有一定的難度

在 Xcode 12 中提供了更強大的工具，一個自定義組件，只需要遵守一個 LiberyContentProvider 協議就可被Xcode識別，可以像系統控件一樣直接從 Xcode 里面識別并預覽。

5. Switch Case Support

在 SwiftUI 的 ViewBuilder DSL體系中也支持了 Switch case 語法

 var body: some View {
            switch c {
            case .a:
                return Text("A")
            case .b:
                return Text("B")
            case .c:
                return Text("C")
            }
        }

6. Data Flow 數據流

SwiftUI中的界面是嚴格數據驅動的：運行時界面的修改，只能通過修改數據來間接完成，而不是直接對界面進行修改操作。

6.1 數據處理的基本原則

1. Data Access as a Dependency：在 SwiftUI 中數據一旦被使用就會成為視圖的依賴，也就是說當數據發生變化了，視圖展示也會跟隨變化，不會像 MVC 模式下那樣要不停的同步數據和視圖之間的狀態變化。

2. A Single Source Of Truth： 保持單一數據源，在 SwiftUI 中不同視圖之間如果要訪問同樣的數據，不需要各自持有數據，直接共用一個數據源即可，這樣做的好處是無需手動處理視圖和數據的同步，當數據源發生變化時會自動更新與該數據有依賴關系的視圖。

6.2 數據流工具

6.2.1 Property 相對簡單, 在View內部定義常量, 變量, 之后在使用

Example Code:

struct Model {
    
    var title: String
    var info: String
}

struct DataFlowTest : View {
    
    var model = Model(title: "WWDC 2019", info: "SwiftUI是一個全新的UI框架")
    
    var body: some View {
        
        VStack {
            Text(model.title).font(.title)
            Text(model.info)
        }
    }
}

6.2.2 @State

• 作用是讓被它標記的屬性可以在 View 內部進行修改，因為直接修改會報錯。

• 用@State修飾的屬性，只要屬性改變，SwiftUI 內部會自動的重新計算 View的body部分，構建出View Tree，由于 View 都是結構體，SwiftUI 每次構建這個 View Tree 都極快，這使得性能有很強的保障。

• 開發者不需要關心數據和視圖的狀態同步工作，只需要關心數據的獲取以及邏輯處理，使用起來非常簡單，大大提高了開發效率。

• 使用的時候，屬性前添加 $ 符號，這種屬性稱之為projection property（投影屬性）。

• 只能在當前 View 的 body 內修改，所以它的使用場景是只影響當前 View 內部的變化的操作。

• 通常應該被標記private。

6.2.3 @Binding

• 傳統的 GUI 程序中最復雜的部分莫過于狀態管理，尤其是多數據同步，一個數據存在于不同的 UI 中，針對某個數據導致的 UI 變化理論上應該同步，狀態量的變多加上異步的操作，會使程序的可讀性直線下降，并且伴隨著而來的就是各種 Bug，SwiftUI 的解決辦法就是使用 @Binding。

• 系統提供的 Control（可操作的View） 的構造器基本都需要 @Binding 屬性，可以自動的同步來自 API 調用方的數據。

@Binding

在不持有數據源的情況下，任意讀取。

從 @State 中獲取數據應用，并保持同步。

Example Code

struct DataFlowStateBindingTest: View {
    // 用@State修飾需要改變的變量
    @State private var count: Int = 0
    
    var body: some View {
        VStack {
            Text("\(count)").foregroundColor(.orange).font(.largeTitle).padding()
            // $訪問傳遞給另外一個UI
            CountButton(count: $count)
        }
    }
}

struct CountButton : View {
    // 用@Binding修飾，綁定count的值
    @Binding var count: Int
    
    var body: some View {
        Button(action: {
            // 此處修改數據會同步到上面的UI
            self.count = self.count + 1
            
        }) { Text("CountButton點擊改變")
        }
    }
}

@State只能在當前修飾的屬性改變時會觸發UI刷新，所以很適合值類型，因為對值類型里面屬性的更新，也會觸發整個值類型的重新設置。不過值類型在傳遞時會發生復制操作，所以給傳遞后的值類型即使屬性更新了也不會觸發最初的傳過來的值類型的重新賦值，所以界面并不會刷新，此時需要用@Binding，因為它可以將值類型轉為引用類型，這樣在傳遞時，其實是一個引用，任何一方修改屬性都會觸發值類型的重新設置，UI界面也隨之更新

6.2.4 ObservableObject

• 在應用開發過程中，很多數據其實并不是在 View 內部產生的，這些數據有可能是一些本地存儲的數據，也有可能是網絡請求的數據，這些數據默認是與 SwiftUI 沒有依賴關系的，要想建立依賴關系就要用 ObservableObject，與之配合的是@ObservedObject和@Published。

• @Published 是 Xcode11 beta5 之后新增的代理屬性，此屬性如果用在 ObservableObject 內，一旦修飾的屬性發送了變化，會自動觸發 ObservableObject 的objectWillChange 的 send方法，刷新頁面，SwiftUI 已經默認幫我實現好了，但也可以自己手動觸發這個行為。

• ObservableObject 是一個協議，必須要類去實現該協議。

• ObservableObject 適用于多個 UI 之間的同步數據。

Example Code:

class UserSettings: ObservableObject {
    // 有可能會有多個視圖使用，所以屬性未聲明為私有
    // @Published修飾需要監聽的屬性，一旦變化就會發出通知，它是發布者
    @Published var score = 123
}

struct DataFlowObservableObjectTest: View {
    // @ObservedObject修飾UserSettings
    @ObservedObject var settings = UserSettings()

    var body: some View {
        VStack {
            Text("人氣值： \(settings.score)").font(.title).padding()
            Button(action: {
                self.settings.score += 1
            }) {
                Text("增加人氣")
            }
        }
    }
}

手動發送狀態 Example Code

class UserSettings: ObservableObject {
    
    // 1.添加發布者，實現一個屬性，名字不能亂寫，否則沒有效果
    let objectWillChange = ObjectWillChangePublisher()
    
    //2.只要name發生更改，屬性觀察器就會調用，告訴objectWillChange發布者發布有關我們的數據已更改的消息，以便所有訂閱的視圖都可以刷新的消息
    var name = "" {
        willSet {
            
            // 3.使用發布者
            objectWillChange.send()
        }
    }
}

struct DataFlowObservableObjectTest: View {
    @ObservedObject var settings = UserSettings()
    
    var body: some View {
        VStack {
            TextField("姓名", text: $settings.name)
                .textFieldStyle(RoundedBorderTextFieldStyle()).padding()
            
            Text("你的姓名: \(settings.name)")
        }
    }
}

6.2.5 @EnvironmentObject

• 主要是為了解決跨組件（跨應用）數據傳遞的問題。

• 組件層級嵌套太深，就會出現數據逐層傳遞的問題， @EnvironmentObject可以幫助組件快速訪問全局數據，避免不必要的組件數據傳遞問題。

• 使用基本與@ObservedObject一樣，但@EnvironmentObject突出強調此數據將由某個外部實體提供，所以不需要在具體使用的地方初始化，而是由外部統一提供。

• 使用@EnvironmentObject，SwiftUI 將立即在環境中搜索正確類型的對象。如果找不到這樣的對象，則應用程序將立即崩潰。

Example Code

class UserSettings2: ObservableObject {
    @Published var score = 123
}

struct DataFlowEnvironmentObjectTest: View {
    
    @EnvironmentObject var settings2: UserSettings2
    
    var body: some View {
        NavigationView{
            VStack {
                // 顯示score
                Text("人氣值： \(settings2.score)").font(.title).padding()
                // 改變score
                Button(action: {
                    self.settings2.score += 1
                }) {
                    Text("增加人氣")
                }
                // 跳轉下一個界面
                NavigationLink(destination: DetailView()) {
                    Text("下一個界面")
                }
            }
        }
    }
}

struct DetailView: View {
    
    @EnvironmentObject var settings2: UserSettings2
    
    var body: some View {
        VStack {
            Text("人氣值： \(settings2.score)").font(.title).padding()
            Button(action: {
                self.settings2.score += 1
            }) {
                Text("增加人氣")
            }
        }
    }
}

7. New Controls

2020年真正重要的是今年新增的各類新控件，其中通過導出來自 Xcode11.5 和 Xcode12.0 beta 版本的 Swift 聲明文件，可以觀察到整個聲明文件從原來的 10769 行增加到20564行。

新增了約87 個 struct 16 個 protocol。有了這些豐富的組件非常利于我們更好的構建我們的 APP 。

8. 復雜列表組件

WWDC20 SwiftUI 2.0 推出了 LazyHStack 和 lazyVStack 加上 List 渲染模式默認就是 Lazy 的直接解決了最大的性能問題。

9. 混合UIKit

對于舊的技術 雖然經過了很多年的歷史沉淀，有很多的積累，但是這些積累同時變成了包袱，如何背著包袱負重前行，是任何一門新技術都要考慮的問題， 顯然 Swift UI 也考慮到了，目前官方給出的文檔中， SwiftUI 是可以和 UIKit 原有的體系很輕松的混合在一起。讓開發者可以漸進式的接入 SwiftUI。

10. 版本支持

官方聲稱 SwiftUI 目前僅支持 iOS 13.x 以上，很多 APP 目前還在兼容 iOS 10左右 ，看起來用上 Swift UI 還需要 3年左右，但是觀察今年 蘋果的重大改變，包括， iOS 12 以下 蜂窩網絡下載可以大于 200M , 蘋果官方包優化大小 減少 50% ，iOS 13 以上甚至完全不限制在蜂窩網絡下下載的大小等, 所以我在想是否為了推行新的SwiftUI, Apple做一下向下兼容, 也未可知吧~ [笑]

11. 全平臺支持 - SwiftUI Apps

蘋果在最近幾年的動作中一直在搞 Apple Platform 統一的事情，從最近幾年的 iPad 多任務 多窗口，到 Mac Catalyst 再到今年更進一步直接推出了 Apple silicon 芯片更是從硬件上做到了真正統一.

• 寫法基本無差異(SwiftUI 的理念是 Learn once, Apply anywhere)
• AppKit, UIKit, WatchKit 都有對應的視圖實現

相較于硬件的變化, 作為軟件工程師我還是要更關注軟件生態的變化, 首先了解下創建 APP 時的變化, 可以看到創建新工程時有了一套全新的模板基于 SwiftUI App Lifecycle 的跨平臺項目。以下是對比

Before

class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        let contentView = ContentView()
        if let windowScene = scene as? UIWindowScene {
            let window = UIWindow(windowScene: windowScene)
            window.rootViewController = UIHostingController(rootView: contentView)
            self.window = window
            window.makeKeyAndVisible()
        }
    }
}

After

import SwiftUI
@main
struct SwiftUI2App: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

這次重要的變化是, 這是第一次跨平臺代碼，完全無需引入任何 UIKit, APPKit, WatckKit 等相關Framewok, 即可直接運行在不同平臺上。這意味著我們后續在UI布局系統上可以逐漸擺脫對傳統命令式 UI 編程的依賴。達到真正的平臺無關。

SwiftUI 將整個原有的平臺差異部分抽象為 App 和 Scene，對于一個 mac/iOS/iPad/watch/tv/…應用，來說 App 代表了整個應用，Scene 代表了與 Window 相關的多窗口，有些設備只有一個 Scene 有些則有多個，雖然不同的 OS 確實存在差異，但是在語義層面達到了一致。

12. SwiftUI 的機會在哪里？

1. 效率

從研發效率上來說， Swift 對比 Objective-C 的精簡程度不言而喻，我嘗試寫了一些頁面代碼量都有一定程度的下降, 如果編寫 UI 界面從 UIKit 轉向了 SwiftUI 代碼量更加的精簡

2. 體驗

更少的代碼意味者更小的包大小，目前國內巨頭 APP iOS 端 APP 包大小都朝著 200 MB 奔去，如果能減少更多的代碼對包大小也可以在 200MB 的限制下承載更多而業務。對用戶的體驗也有較大的提升。

更進一步由于 Swift 選擇使用值類型構建整個APP，值類型的有點在于更扁平化的內聯數據結構去分配內存，而不是使用更多間接指針引用，減少了大量不必要的堆內存消耗，意味著整體內存使用量的降低。對整個 APP 的穩定性也有較大的提高

Demo地址** 將會持續更新SwiftUI相關代碼
https://github.com/summerxx27/SwiftUITutorials