SwiftUI是什麼?
首次發布於2019年SwiftUI框架值得注意的是，它代表了Swift開發用戶界麵的一種開創性的新方式。而SwiftUI框架可以用來取代Swift現有的框架UIKit框架在很多情況下，將SwiftUI和UIKit視為非此即彼的命題是錯誤的。SwiftUI被設計成可以靈活地嵌入到現有的UIKit項目中，允許開發者使用它來補充UIKit，而不僅僅是取代它。
我的同事、iOS工程師Louis Bur將SwiftUI描述為“一種構建ui的聲明式和反應式方法，允許開發人員簡潔地表達視圖層次結構和用戶交互。”基於此，我將SwiftUI描述為Swift開發的一個真正的diy新前沿。使用SwiftUI，沒有拖放故事板，沒有xib——隻有代碼。此外，SwiftUI還提供了用戶界麵(UI)特性的自動支持，如暗模式和動態類型，以及從左到右/從右到左的布局方向支持，這是開發人員考慮采用它的主要動機。(就我個人而言，在UIKit中建立從右到左的支持是我最不希望發生的事情。)
SwiftUI和UIKIt有什麼區別?
有趣的是，我發現對SwiftUI的研究讓我重新評估了我所知道的所有關於UI開發的知識。UIKit是用命令式範式編寫的，而SwiftUI則采用聲明式開發範式，這一轉變對開發人員來說意義重大。
這些範例之間的一個關鍵區別是它們如何管理狀態:當與Combine框架協同使用時，SwiftUI允許您所編寫的代碼元素彼此通信。真相的來源”變化。本質上，它意味著開發者不需要調用函數來更新狀態以響應變化，就像UIKit那樣。這隻是SwiftUI和UIKit之間明顯的區別之一，它們讓我的生活變得更容易了。
另一個原因是，與UIKit相比，在SwiftUI中實現滾動列表所需的代碼要少得多。作為一個實驗，我構建了兩個相同的視圖，一個在SwiftUI中，另一個在UIKit中，以突出框架之間的差異。
下麵是在UIKit中實現垂直滾動列表的代碼片段:
這段代碼的大部分是由樣板UITableViewDataSource方法組成的，這些方法必須被寫出來每一次當使用UITableView時;實際上這裏的代碼比我在代碼片段中提供的還要多，但你可能已經明白了。
現在，讓我們來看看SwiftUI中等價的代碼片段:
正如你所看到的，SwiftUI可以通過一個簡單的List對象和for循環來實現與那個龐大的UIKit片段完全相同的結果。滾動列表是iOS中許多視圖的基礎，所以能夠在編寫更少的樣板代碼的同時支持滾動列表是一件令人耳目一新的事情。另外，在我的開發過程中，我發現當我進行布局更改時，不需要編譯我的代碼SwiftUI預覽；這個改變已經為我節省了無數的開發時間。
將用戶界麵放在SwiftUI中
SwiftUI的另一個好處?它取代了開發人員在使用Swift時使用任何類型的Storyboard或接口構建器的需求。現在，不要誤解我的意思——故事板在很多情況下都很好。但是，一旦您開始在多個分支中使用多個人員進行開發，那麼隻需進行幾次布局更改，就會發現自己陷入合並衝突的地獄。由於這些潛在的問題，開發人員通常必須以編程方式編寫UI。
然而，使用SwiftUI，創建消息視圖可以相對簡單和精簡。事實上，實現這一點可以像下麵的代碼片段一樣簡單:
因為在SwiftUI發布之前ZStack還不存在，想要構建這種視圖的開發者不得不在沒有任何顯式iOS api的情況下轉向子視圖操作。因此，這意味著很少有開發者願意嚐試創造這類體驗，這使得品牌公司很難在用戶粘性方麵利用它們。但是有了SwiftUI，它們突然變成了一個真正的、可實現的選擇——如果我自己這麼說的話，這是相當令人興奮的。
SwiftUI中的內容卡
UIKit和SwiftUI之間一個我們還沒有觸及的根本區別是它們不同的架構模式。UIKit傳統上植根於模型-視圖-控製器(MVC)原則，而SwiftUI實際上的模式是模型-視圖-視圖模型(MVVM)，當涉及到在iOS中集成內容卡時，這種差異很重要。因為UIKit是基於mvc的，視圖控製器負責抓取內容卡;但是，因為SwiftUI沒有視圖控製器，所以獲取代碼被委托給視圖模型。鑒於此，SwiftUI為開發者提供了一種從Braze iOS SDK中請求和接收內容卡的新技術。下麵是使用SwiftUI處理該過程的一種方法:
在本例中，我們的數據是Content Cards本身，表示為Summary對象數組(如Z-stack截圖所示)。數組被標記為@Published, a屬性包裝，以通知任何偵聽的元素內容卡已加載。
SwiftUI實現的另一種新的屬性包裝器類型是observvedobject，它表示當視圖模型更新時，視圖需要更新。這樣做的目的是，當Content card在摘要數組中加載和設置時，數據可以在視圖中相應地顯示。
有關如何在自定義UI中顯示內容卡的更多信息，請查看我們的內容卡實施指南．
你身邊的應用很快就會出現
在這一點上，你可能會問，是什麼阻止人們從UIKit大量轉移到SwiftUI。有幾個原因——包括快速使用SwiftUI所涉及的工作，可能的舒適度和對uikit的熟悉度——但一個重要因素是iOS版本。
部分原因是SwiftUI相對較新，它要求至少在2019年推出的iOS 13上部署。對於一些品牌來說，這個前提條件可能並不重要，但對於像Braze這樣需要支持更老版本iOS的公司來說，強迫SwiftUI加入現有項目可能最終會成為不必要的負擔，而不是帶來淨收益。然而，值得記住的是，Swift花了幾年時間才流行起來，並成為iOS開發的首選語言，所以如果SwiftUI最終看到類似的采用軌跡，我也不會感到驚訝。
最終的想法
就我個人而言，到目前為止，嚐試SwiftUI是一個令人愉快的挑戰，它讓我重新思考開發人員應該如何構建複雜的用戶界麵。SwiftUI的簡單性和靈活性使它成為在不斷變化的UI開發領域創造性地解決問題的強大工具，也是該領域的開發人員應該密切關注的東西。
為了更多地了解Braze平台的技術方麵，以及它如何影響客戶參與的可能性，查看我們的文檔．
有興趣加入Braze嗎?在我們的職業頁麵查看我們的公開職位．
