背景
爲了研究 SwiftUI 在業務落地的可能性，我們一直持續關注着 SwiftUI 的發展，但編程這種工作，向來是閱讀千編，不如實戰一次來的深刻，剛好我們有一個業務場景非常適合，那就是觀察穩定性大盤。
整個淘系也有一個用來觀察穩定性數據的應用，通常來說數據大盤是比較適合在 PC 瀏覽器中展示的，我們也在 PC 中使用了多年，但是淘寶 APP 是一個重運營類的 APP， 經常會有一些活動在節假日投放。
但此時值班人員或者相關人員可能在外，有時候可能並未攜帶電腦，這時候觀察穩定性情況就非常窘迫，我們迫切需要一款可以隨身攜帶的APP，用於在緊急時刻觀察穩定性問題。
項目耗時
這裏先給出時間結論，
整個 SOT APP 耗時 1.3 人力，共 10 個工作日，整個 Swift 代碼 約 2800 行。
由於這是一款必須工作在內網下的 APP， 接入內網鑑權沒有太多經驗，花費不少時間。
整體下來大約有 5天左右的工作量花在調試接口，內網鑑權，原型設計部分，真正花在 SwiftUI 的部分約有 5 天，不得不說效率驚人。
項目設計
原型設計
做一款 APP 的最核心的部分是設計 APP 的功能，熟悉 SOT 的同學，應該知道一般觀察穩定性主要是觀察數據大盤，聚合列表，分析聚合詳情，崩潰分析等比較重要的模塊。
落地 SwiftUI 的計劃預計 兩週，所以 SOT 一期只做做核心常用的部分。功能有了，那麼設計怎麼辦呢？
不要慫，作爲 9102 年的程序員，不會做 UI 怎麼可以？由於 Mac 平臺的 設計軟件 如 Keynote 和 Sketch 操作方式，基本和 StoryBoard （只會用代碼寫UI的同學要回去重新學習下 StoryBoard 了 -）操作非常接近，花了一天時間簡單設計了下界面。
這裏刻意模仿 App Store的圓角和陰影設計，至於爲什麼？原因就是負責的設計會讓 UI 代碼編寫變的更有挑戰性，如果只是用系統原生的樣式，那麼碰見的難題就會大大減少，這樣的實戰到了實際的項目中，碰見的問題還會很多。
事實證明負責的 UI 設計對理解 SwiftUI 非常有價值，單單一個圓角，就花去了 6 個小時開發時間。
數據流管理
SwiftUI 是一個典型的單向數據流得聲明式 UI 編程框架, 在 SwiftUI 中 View 只是一個頁面的描述部分，SwiftUI 提供了多個數據流管理對象。
@State @Binding @Obserabled ,通過改變這些數據流的值，SwiftUI 系統可以理解重新構建 View Tree， 並根據內部變化的範圍，有一層類似 Virtual Dom 的 ViewTree, 由於 View 都是結構體，SwiftUI 每次構建這個 View Tree 都極快，這使得性能有很強的保障。
在實踐中也發現了一些Bug，但由於目前 SwiftUI 還在高速變化，這些 Bug 都會在將來的版本中修復，這裏就不過多解釋了。
State
State 是 SwiftUI 中最常用的 代理屬性，通過對代理屬性的修改，SwiftUI 內部會自動的重新計算 View的 Body部分，構建 出View Tree。
注意 State 只能在當前 View 的 body 體裏面修改，所以 State 的適用場景就是隻影響當前 View 內部的變化的操作。
舉個實際的例子就是類似下載網絡圖片的部分，調用方通常提供一個 URL 和 Placeholder Image，在 SwiftUI 中使用 State 即可，因爲此時的網絡圖變化隻影響當前 View。
如 APP 選擇界面中，圖片資源都來源自網絡。
示例代碼如下 ：
struct NetworkImage: SwiftUI.View {
var urlPath: String?
var placeHodlerImage: UIImage
init(url path: String?, placeHolder: String) {
self.urlPath = path
self.placeHodlerImage = UIImage(named: placeHolder)!.withRenderingMode(.alwaysOriginal)
}
@State var downLoadedImage: UIImage? = nil
var body: some SwiftUI.View {
Image(uiImage: downLoadedImage ?? placeHodlerImage)
.resizable()
.aspectRatio(contentMode: .fill)
.onAppear(perform: download)
}
func download() {
if let _ = downLoadedImage {
return
}
_ = urlPath.flatMap(URL.init(string:)).map {
ImageDownloader.default.downloadImage(with: $0) { result in
switch result {
case .success(let value):
self.downLoadedImage = value.image.withRenderingMode(.alwaysOriginal)
case .failure(let error):
log.debug(error)
}
}
}
}
}
Binding
在傳統的命令式編程中，GUI 程序中最複雜的部分莫過於狀態管理，尤其是多數據同步，一個數據存在於不同的 UI 組成部分，UI 各個部分的變化理論上都有同步，狀態量的變多加上異步的操作，會使程序的可讀性直線下降，並且伴隨着而來的就是 Bug ，並且不敢重構。
SwiftUI 給我們的理念就是 Single source of truth, 簡單來說就是單一數據源，單一數據源是個很早就有的名詞/方法，但是很多系統並沒有給出很好的解決辦法，比如習慣 FRP 的同學可能用 RX/RAC 裏面的 Singnal 去描述，但是 FRP 晦澀的概念，又使其在項目中的接入成本大大提高。
SwiftUI 給我們的解決辦法就是 @Binding 。作者之前嘗試自己實現一個 Binding，實現起來就是一個簡單的閉包，通過閉包捕獲 Source of truth 的數據，同時 SwiftUI 會幫我們自動刷新需要同步的界面。使我們的數據同步變的的非常簡單。
實際例子如，系統提供的 Control（可操作的View） 的構造器基本都需要 @Binding 屬性，可以自動的同步來自 API 調用方的數據源。
這裏舉個例子如 項目中的版本選擇和日期選擇功能,我們需要講控件選擇的值同步給數據源。
struct DateVersionPanel : View {
@Binding var version: String
@State var input = ""
@Binding var date: Date
var title: String
@State private var showVersionPicker = false
@State private var showDatePicker = false
var dateFormatter: DateFormatter {
let formatter = DateFormatter()
formatter.dateFormat = "yyyy-MM-dd"
return formatter
}
private func showDate() {
showDatePicker = true
}
var body: some View {
HStack(alignment: .center) {
Text(title)
.font(.system(size: 14))
HStack(alignment: .center) {
TextField(version.isEmpty ? "不區分版本" : version, text: $input, onEditingChanged: { (changed) in
log.debug("TextFieldonEditing: \(changed)")
}) {
log.debug("TextFielduserName: \(self.version)")
self.version = self.input
}
.font(.system(size: 9))
.padding(.leading, 20)
.frame(width: 100, height: 20)
NavigationLink(destination: VersionSelectView(version: $version)) {
Image("down_arrow")
.frame(width: 24, height: 14)
.aspectRatio(contentMode: .fill)
}
.offset(x: -20)
}
.frame(width: 100, height: 25)
.border(Color.grayText, width: 0.5)
.padding(.leading, 40)
NavigationLink(destination: CalendarView(date: self.$date)) {
HStack {
Text(dateFormatter.string(from: date) )
.font(.system(size: 9))
.padding(.leading, 10)
Image("down_arrow").padding(.trailing, 10)
}
.frame(width: 100, height: 25)
.border(Color.grayText, width: 0.5)
.padding(.leading, 40)
}
}
.padding(.bottom, 10)
}
}
ObservableObject
ObservableObject 在 Xcode11 Beta 4 之前叫 ObjectBinding , 這個類型是一個協議，要求我們實現一個來自 Combine 框架的 Subject Subject 是一個和命令式編程世界交互的橋樑，是一個特殊的 Publisher，SwiftUI 內部會自動的訂閱這個 Subject，在 Subject 發送變化時 SwiftUI 會自動刷新數據。
ObservableObject 適用於多個 UI 組成部分同步數據，ObservableObject 取代了，Cocoa 框架基本編程風格 MVC 中控制器的角色，暫時項目中就叫他 ViewModel 吧。
@Published 是 Xcode11 beta5 之後新增的代理屬性，此屬性如果用在 ObservableObject 內，如果屬性發送了變化，會自動觸發 ObservableObject 的 objectWillChanged 的Subject變化，自動刷新頁面。
同時由於 Combine 框架的支持，多個條件聯動變成了一個簡單的事情，在 SOT APP 項目中，就非常適合，比如數據大盤，有將近10幾個數據狀態，任何一個觸發，都會導致數據刷新。
class HomeViewModel: ObservableObject {
@Published var isCorrectionOn = true
@Published var isForce = false
@Published var crashType = CrashType.crash
@Published var pecision = Pecision.fifith
@Published var quota = Quota.count
@Published var currentDate = Date()
@Published var currentVersion = ""
@Published var comDate = Date().lastDay
@Published var comVersion = ""
@Published var refresh = true
@Published var metric: Metric? = nil
@Published var trends: [TrendItem] = []
@Published var summary: Summary? = nil
var api = SOTAPI()
// MARK: - Life Cycle
var cancels = AnyCancellable
init() {
var cancel = $refresh.combineLatest($isForce, $isCorrectionOn)
.combineLatest($crashType, $pecision, $quota)
.combineLatest($currentDate, $currentVersion)
.combineLatest($comVersion, $comDate)
.debounce(for: 0.5, scheduler: RunLoop.main)
.sink {[weak self] (_) in
self?.requestMetric()
self?.requestTrends()
}
cancels.append(cancel)
cancel = $refresh.sink{[weak self] (_) in
self?.requestSummary()
}
cancels.append(cancel)
}
func requestMetric() {}
func requestTrends() {}
func requestSummary() {}
}
Work with UIKit
由於 SwiftUI 是一個封閉的系統，有時候一些控件還不夠豐富，爲了滿足開發所用，還需要和一些已有的 UIKit的 UIView 混合編程，一方面可以減少遷移的負擔，一方面可以增加 SwiftUI 的能力。
在 SOT 項目中，由於日期選擇是一個專業的庫，這裏採用了第三方庫，就涉及到於 UIKit 交互， SwiftUI 提供了一套非常簡單清晰的標準，可以用在多個平臺上交互，並提供一致的表現力。
需要注意的是 UIViewRepresentable 的遵守者，是一個 View 容器，此容器會被創建多次，如果內部有數據源需要通知，需要創建相應的 Coordinator 將當前的容器當做 View 傳遞進去，由於 View 是結構體。
此時創建的是一個拷貝副本，所以 Coordinator 修改的部分，最好只是 ObservableObject Binding
struct CalendarView : UIViewRepresentable {
@Environment(\.presentationMode) var presentationMode
@Binding var date: Date
init(date: Binding<Date>) {
self._date = date
}
func makeUIView(context: UIViewRepresentableContext<CalendarView>) -> UIView {
let view = UIView(frame: UIScreen.main.bounds)
view.backgroundColor = .backgroundTheme
let height: CGFloat = 300.0
let width = view.frame.size.width
let frame = CGRect(x: 0.0, y: 0.0, width: width, height: height)
let calendar = FSCalendar(frame: frame)
calendar.locale = Locale.init(identifier: "ZH-CN")
calendar.delegate = context.coordinator
context.coordinator.fsCalendar = calendar
calendar.backgroundColor = UIColor.white
view.addSubview(calendar)
return view
}
func makeCoordinator() -> CalendarView.Coordinator {
Coordinator(self)
}
func updateUIView(_ uiView: UIView, context: UIViewRepresentableContext<CalendarView>) {
log.debug("Date")
context.coordinator.fsCalendar?.select(date)
}
func dismiss() {
presentationMode.wrappedValue.dismiss()
}
class Coordinator: NSObject, FSCalendarDelegate {
var control: CalendarView
var date: Date
var fsCalendar: FSCalendar?
init(_ control: CalendarView) {
self.control = control
self.date = control.date
}
func calendar(_ calendar: FSCalendar, didSelect date: Date, at monthPosition: FSCalendarMonthPosition) {
self.control.date = date
}
}
}
架構
Combine
在此項目中使用了最基本的 Combine 操作，由於項目一期主要是爲了探索 SwiftUI ，所以並未對架構模式做精細的設計，可以觀察到，ViewModel，內部還是有訂閱，發送網絡請求，最後同步數據的操作，這種編碼方式，還是典型的命令式編程風格，此部分會在項目二期逐漸探索中修改爲響應式風格。
Redux/Flux
SwiftUI 是一個單向數據流框架，在此之前，大前端已經有 React， Flutter ， Reactive Native，等比較流行的框架。在這些單向數據流得框架下，Redux 作爲一種比較流行的狀態管理的架構風格，已經經過多方面的驗證，SwiftUI 對於Redux也是比較適用的。
Redux 的基本思想核步驟是：
- 整個頁面甚至 APP 是一個巨大的狀態機，有一個狀態存儲 Store ，在某個時刻處於某種狀態。
- 狀態在頁面表達中是一個簡單的樹型結構，在 SwiftUI，對應的 就是 View Tree。
- View 操作不能直接修改狀態，只能通過發送 Action, 間接改變 Store。
- Reducer 通過 Action 加上 oldState 獲取 newSatete。簡單來說就是 State = f(action+oldState)。
附上一份 阮一峯的Redux入門教程的示例圖：
這套風格在前端大型項目中已經了驗證，可以比較清晰的表達用戶事件交互和狀態管理。
目前由於 SwiftUI 中 ViewCtonroller的消失，加上方便的 ObserableObject 和 EmviromentObject 。
SOT 項目一期暫未採用，在二期項目中會探索合適的架構設計。
項目總結
此項目在短短的 10 個工作日內就能完成，不得不說 SwiftUI 的開發效率真的驚人，雖然目前還有一些 Bug ，但是相信在未來，SwiftUI 會是 Apple 平臺 UI 佈局的解決辦法，關於 SwiftUI 如何在淘系落地業務，還在持續探索中。
目前此項目已在集團內部開源。
本文轉載自公衆號淘系技術（ID：AlibabaMTT）。
原文鏈接：