開始之前：請確保你的系統(tǒng)版本為macOS 10.15及以上版本且已經(jīng)安裝了Xcode 11。這種組合使您可以在Xcode內(nèi)部預覽SwiftUI設計，這比一直推送到模擬器的速度要快得多。
什么是SwiftUI？
SwiftUI是一個用戶界面工具包，可讓我們以聲明的方式設計應用程序。這是一種奇特的方式，我們告訴SwiftUI我們希望UI的展示效果和工作方式，它知道如何在用戶與之交互時實現(xiàn)這一點。
與命令式UI相比，聲明式UI最好理解，這是iOS開發(fā)人員在iOS 13之前所做的。在命令式用戶界面中，我們可以使用戶在單擊按鈕時調(diào)用一個函數(shù)，并在函數(shù)內(nèi)部讀取一個值。并顯示標簽-我們會根據(jù)正在發(fā)生的事情定期修改用戶界面的外觀和工作方式。
命令式UI會引起各種問題，其中大多數(shù)問題都圍繞state發(fā)生，這是另一個花哨的術語，意為“我們存儲在代碼中的值”。我們需要跟蹤代碼處于什么狀態(tài)，并確保我們的用戶界面正確反映了該狀態(tài)。
如果我們的一個屏幕具有一個會影響UI的布爾值屬性，則我們有兩種狀態(tài)：布爾值可以打開或關閉。如果我們有兩個布爾值A和B，則現(xiàn)在有四個狀態(tài)：
- A關閉，B關閉
- A打開，B關閉
- A關閉，B打開
- A打開，B打開
如果我們有三個布爾值呢？五個呢？或者多個整數(shù)，字符串，日期等等？好吧，那么我們要復雜得多。
如果你曾經(jīng)使用過一個應用程序，無論您嘗試多少次來告訴它自己已經(jīng)讀過該死的東西，但它仍說你有一條未讀的消息。這是一個狀態(tài)問題–是命令式UI引起的問題。
相比之下，聲明性UI可以讓我們立即告知iOS應用程序的所有可能狀態(tài)。我們可能會說，如果已登錄，則顯示歡迎消息，但如果已注銷，則顯示登錄按鈕。我們不需要編寫代碼來手動在這兩個狀態(tài)之間移動–這是難看的命令式工作方式！
相反，當狀態(tài)更改時，我們讓SwiftUI在用戶界面布局之間移動。我們已經(jīng)根據(jù)用戶登錄或注銷告訴了它要顯示的內(nèi)容，因此當我們更改身份驗證狀態(tài)時，SwiftUI可以代表我們更新UI。
這就是聲明性的含義：我們不是要手動顯示和隱藏SwiftUI組件，而是要告訴它要遵循的所有規(guī)則，而讓SwiftUI確保這些規(guī)則得到強制執(zhí)行。
但是SwiftUI不僅止于此：它還充當跨平臺的用戶界面層，可跨iOS，macOS，tvOS甚至watchOS運行。這意味著您現(xiàn)在可以學習一種語言和一種布局框架，然后將代碼部署到任何地方。
SwiftUI vs Interface Builder和storyboards
全面更新了Xcode 11.2
每個經(jīng)驗豐富的iOS開發(fā)人員都熟悉Interface Builder和Storyboard，甚至XIB也是如此。他們可能不喜歡它們，但至少對它們熟悉。如果您以前沒有使用過這些，你應該跳過這一步。
還在這里？這意味著您以前使用過IB，并且可能會對SwiftUI的不同感到好奇。
那么，讓我問您一個問題：您是否曾經(jīng)手動編輯storyboard或XIB？
可能沒有。好吧，除了這一次之外，大體上答案是否定的——storyboards和XIBs包含大量不易閱讀或編輯的XML。
更糟糕的是，storyboard有一個習慣是隨著時間的推移越來越大。當然，它們可能從很小的地方開始，但是隨后您又添加了另一個視圖控制器和另一個視圖控制器，然后突然您意識到在一個文件中有十個屏幕的數(shù)據(jù)，你所做的任何源代碼管理更改都會突然變得非常痛苦。
但是，盡管單點故障并不好，當有人打開帶有storyboard修改的拉取請求時，基本上不可能看到有什么變化，storyboards和XIBs還有一個更大的問題。
您會看到，Interface Builder對我們的Swift代碼不太了解，而我們的Swift代碼對Interface Builder也不太了解。結果，我們最終得到了許多不安全的功能：我們使用Ctrl從IB拖動到我們的代碼中，將某物連接到一個動作，但是如果刪除該動作，代碼仍然可以編譯——IB真的不介意它呼叫的代碼是否已經(jīng)不存在。
類似地，當我們從storyboard或表格視圖單元中創(chuàng)建視圖控制器時，我們使用字符串來標識代碼中的重要對象——一個如此普遍的系統(tǒng)，它甚至擁有自己的名稱：“字符串類型的API”。即使這樣，我們也需要使用類型轉(zhuǎn)換，因為Swift不能知道它返回的表視圖單元實際上是一個MooncakeTableViewCell。
存在這些問題是因為IB和Swift是很獨立的東西。這并不是一個很大的驚喜——Interface Builder不僅可以追溯到最初MacOSX出現(xiàn)之前，而且它也是圍繞著Objective-C的工作方式而設計的。
SwiftUI在過去的基礎上取得了重大突破。這是一個僅限Swift的框架，不是因為蘋果公司認為Objective-C是時候死了，而是因為它讓SwiftUI充分利用了Swift的所有功能——值類型，隱式返回類型，協(xié)議擴展等等。
不管怎樣，我們將很快了解SwiftUI的工作原理。目前，您至少需要知道的是，SwiftUI修復了人們使用舊的Swift + Interface Builder方法所遇到的許多問題：
- 我們不必再爭論基于程序或storyboard的設計，因為SwiftUI同時為我們提供了這兩種設計。
- 在提交用戶界面工作時，我們不再需要擔心創(chuàng)建源代碼控制問題，因為代碼比storyboard的XML更易于閱讀和管理。
- 我們不再需要為字符串類型的API擔心太多了——雖然仍然有一些，但數(shù)量大大減少了。
- 我們不再需要擔心不存在的調(diào)用函數(shù)，因為我們的用戶界面已由Swift編譯器檢查。
因此，我希望您會同意，遷移到SwiftUI可以帶來很多好處！
關于SwiftUI的常見問題
學習哪個：SwiftUI或UIKit？
在我問過的所有SwiftUI問題中，有一個比其他任何問題都多：“我正在學習Swift：我應該學習SwiftUI還是我也需要學習UIKit？”
人們似乎想聽到的答案是“忘記舊的UIKit了，您應該專注于SwiftUI！”然而，一個簡單的事實是，絕大多數(shù)人都不會從該建議中獲得成功，這值得解釋為什么一點細節(jié)。
在開始詳細介紹之前，我想澄清一件事：SwiftUI是一個了不起的用戶界面框架，并且絕對會100％成為Apple平臺上應用程序開發(fā)的未來。但是，如果您想今天（或在未來一到兩年左右的任何時間）構建出色的應用程序，那么您也100％絕對需要UIKit的知識，特別是如果您打算使應用程序開發(fā)成為您的職業(yè)。
好的，順便說一句，在忽略UIKit的同時關注SwiftUI的問題歸結為三點：
API覆蓋范圍有限。
限制采用。
支持有限。
讓我們分解一下……
API覆蓋范圍有限
無論您是想在公司工作還是在業(yè)余時間開發(fā)業(yè)余愛好應用程序，SwiftUI的一個缺點是它目前沒有與UIKit一樣廣泛的API覆蓋范圍。
例如，如果要在網(wǎng)格中顯示項目，可以UICollectionView在UIKit中使用，但是SwiftUI沒有等效項。或者，如果您想讓用戶輸入多行文本，可以UITextView在UIKit中使用，但是SwiftUI也沒有等效項。
這并不是蘋果公司的懶惰，而是故意的：他們不是先發(fā)布所有API的包裝器，而是在以后進行更改，而是采取更為謹慎的方法并逐步添加API。（我希望！）這應該減少我們將來看到的重大更改的數(shù)量，因為它使Apple的工程師有更多的時間來細化他們打算交付的API子集。
很多時候，您會找到解決方法，但是老實說，當您知道某個特定的東西在UIKit中是微不足道的，但是在SwiftUI中不是不可能的時候，這很累。有時甚至很簡單：如何更改表上的分隔符插入？或如何將文本框添加到警報中？這些是UIKit中的單行代碼，但在SwiftUI中不可用。
隨著時間的流逝，我完全希望看到SwiftUI會增加更多功能，使其與UIKit達到同等水平，但是現(xiàn)在我們還有很長的路要走。
限制采用
SwiftUI僅在WWDC2019上宣布，并且可在iOS 13設備或更高版本中使用。這立即意味著：
迄今為止，幾乎所有編寫的應用程序都使用UIKit。
任何需要支持iOS n-1或n-2的應用程序（例如iOS 12和iOS 11）甚至都無法開始使用SwiftUI一年或更長時間。
這意味著，如果您打算在未來三年內(nèi)找到一份iOS開發(fā)人員的工作，則UIKit經(jīng)驗實際上是必不可少的，因為這是現(xiàn)有代碼庫所使用的。實際上，我完全希望UIKit在四年后仍將是主導的UI平臺。我想沒有人-甚至沒有蘋果！–希望iOS社區(qū)能夠以任何快速的步伐遷移到SwiftUI。在UIKit應用程序中有大量的代碼，大量的時間和大量的資金，并且它擁有漫長而幸福的生活。
有些人試圖在采用Swift和采用SwiftUI之間劃清界限，這沒有幫助。采用Swift的速度很快，因為它可以在Apple支持的每個框架（UIKit，SpriteKit等）中工作，并且還已經(jīng)支持iOS n-1，因此許多公司可以立即切換到它。
再一次，我想重申，SwiftUI絕對將成為Apple平臺開發(fā)的未來，但是要在UIKit級別獲得采用將需要很長時間。
同時，SwiftUI是個人應用程序，愛好應用程序，原型應用程序或一般實驗的理想選擇。如果您有幸加入專門使用SwiftUI的公司，請盡情享受吧！
有限的支持
UIKit已有十多年的歷史了，這意味著a）幾乎您可能遇到的每個問題都已經(jīng)被他人解決，并且b）那里有許多提供擴展和自定義功能的庫。
盡管有些學習者可能會想到高級開發(fā)人員會掌握大量UIKit，但簡單的事實是，我們所有人都使用Google，Stack Overflow，利用Swift進行黑客入侵等工具來找到問題的解決方案。當您絕望時，這可能實際上是將錯誤消息粘貼到網(wǎng)站中，但是無論您如何獲得答案，它都可以節(jié)省大量在線查找錯誤消息的時間。
SwiftUI僅憑借顯著更新而已，可用的解決方案卻少得多。實際上，尋找從未有人嘗試過的東西很普遍–實際上，您是第一人。這可能會很有趣，但是如果您有一個實際要交付的實際項目，那也可能會令人沮喪。
所以……您是說我不應該學習SwiftUI嗎？
沒有！SwiftUI非常有趣，您可以用它來構建奇妙的東西。本書的其余全部內(nèi)容旨在幫助您盡快高效地開始使用SwiftUI –如果我不認為SwiftUI很棒，我不會寫它。
我要說的是，SwiftUI的存在并沒有以某種方式使UIKit過時：如果您打算在未來三年內(nèi)獲得iOS開發(fā)工作，那么知道如何使用UIKit將會是一項堅定的要求或一個強大的要求。獎金。
因此，直接回答這個問題：是的，應該忙于學習SwiftUI，因為這是在蘋果平臺上進行應用程序開發(fā)的未來，但是您仍然需要學習UIKit，因為這些技能在未來幾年中將非常有用。
隨著時間的流逝，隨著SwiftUI的實力，采用和支持的增長，以及隨著SwiftUI的增長，UIKit將開始縮小，上面列出的所有三個問題都將得到減少。但是，至少目前至少確實需要兩者。
SwiftUI可以在哪里使用？
SwiftUI在iOS 13，macOS 10.15，tvOS 13和watchOS 6或這些平臺的任何更高版本上運行。這意味著，如果您使用的應用程序必須支持iOS N-1甚至N-2（即當前版本和該版本之前的一兩個版本），那么您甚至需要一兩年的時間才能考慮遷移到SwiftUI 。
但是，重要的是不要將SwiftUI視為類似于Java的Swing或React Native的多平臺框架。官方說法似乎是，SwiftUI不是一個多平臺框架，而是一個用于在多個平臺上創(chuàng)建應用程序的框架。
聽起來可能是一樣的，但是有一個重要的區(qū)別：Apple并不是說您可以在每個平臺上使用相同的SwiftUI代碼，因為有些事情是不可能的–無法在Mac上使用Apple Watch的數(shù)字王冠例如，并且類似地在watchOS應用上具有選項卡欄也將無法工作。
SwiftUI會取代UIKit嗎？
不會。SwiftUI的許多部分都直接建立在現(xiàn)有UIKit組件之上，例如UITableView。當然，許多其他部分則沒有，它們是SwiftUI而非UIKit呈現(xiàn)的新控件。
但是重點不是UIKit涉及的程度。相反，關鍵是我們不在乎。SwiftUI或多或少完全掩蓋了UIKit的行為，因此，如果您為SwiftUI編寫應用程序，并且Apple在兩年內(nèi)用唱的大象代替了UIKit，那么您不必在乎–只要Apple使大象具有相同的方法和屬性即可該UIKit暴露于SwiftUI，您的代碼不變。
SwiftUI是否使用自動布局？
盡管Auto Layout肯定會在幕后用于某些事情，但作為SwiftUI設計師并沒有暴露給我們。取而代之的是，它使用了靈活的盒式布局系統(tǒng)，這對于來自Web的開發(fā)人員來說將是熟悉的。
SwiftUI快嗎？
SwiftUI是令人訝異的快-在所有我的測試中，到目前為止，似乎超越的UIKit。與做到這一點的團隊交談后，我開始明白為什么：首先，他們積極地扁平化圖層層次結構，這樣系統(tǒng)就不必做更多的繪制了，但是第二步，很多操作完全繞過了Core Animation，直接去了Metal進行了額外的處理。速度。
所以，是的：SwiftUI的速度非常快，而且所有這些都無需我們做任何額外的工作。
為什么看不到我的代碼預覽？
使用SwiftUI時，能夠同時查看視圖代碼和視圖預覽（外觀）非常有幫助。如果您可以看到代碼而不是預覽，則可能是您尚未升級到macOS 10.15；必須進行預覽才能正常工作。
代碼與預覽的匹配程度如何？
對預覽進行任何更改時，它也會更新生成的代碼。同樣，如果更改代碼，它也會更新用戶界面。因此，代碼和預覽是相同的，并且始終保持同步。
為什么我的顏色看起來有點偏？
SwiftUI為我們提供了標準的系統(tǒng)顏色，例如紅色，藍色和綠色，但是這些并不是您習慣于使用的純紅色，藍色和綠色UIColor。取而代之的是，這些是可以自動適應明暗模式的新樣式顏色，這意味著根據(jù)您的系統(tǒng)外觀，它們看起來會更亮或更暗。
UIKit死了嗎？
沒有！蘋果在本周的WWDC上播出了大量的新UIKit功能。如果Apple仍在WWDC上談論UIKit的新功能，那您就很安全-沒有使他們驚訝地淘汰它的風險。
您可以混合使用SwiftUI和UIKit的視圖嗎？
是!?您可以將一個嵌入另一個，效果很好。
