开始之前：请确保你的系统版本为macOS 10.15及以上版本且已经安装了Xcode 11。这种组合使您可以在Xcode内部预览SwiftUI设计，这比一直推送到模拟器的速度要快得多。
什么是SwiftUI？
SwiftUI是一个用户界面工具包，可让我们以声明的方式设计应用程序。这是一种奇特的方式，我们告诉SwiftUI我们希望UI的展示效果和工作方式，它知道如何在用户与之交互时实现这一点。
与命令式UI相比，声明式UI最好理解，这是iOS开发人员在iOS 13之前所做的。在命令式用户界面中，我们可以使用户在单击按钮时调用一个函数，并在函数内部读取一个值。并显示标签-我们会根据正在发生的事情定期修改用户界面的外观和工作方式。
命令式UI会引起各种问题，其中大多数问题都围绕state发生，这是另一个花哨的术语，意为“我们存储在代码中的值”。我们需要跟踪代码处于什么状态，并确保我们的用户界面正确反映了该状态。
如果我们的一个屏幕具有一个会影响UI的布尔值属性，则我们有两种状态：布尔值可以打开或关闭。如果我们有两个布尔值A和B，则现在有四个状态：
- A关闭，B关闭
- A打开，B关闭
- A关闭，B打开
- A打开，B打开
如果我们有三个布尔值呢？五个呢？或者多个整数，字符串，日期等等？好吧，那么我们要复杂得多。
如果你曾经使用过一个应用程序，无论您尝试多少次来告诉它自己已经读过该死的东西，但它仍说你有一条未读的消息。这是一个状态问题–是命令式UI引起的问题。
相比之下，声明性UI可以让我们立即告知iOS应用程序的所有可能状态。我们可能会说，如果已登录，则显示欢迎消息，但如果已注销，则显示登录按钮。我们不需要编写代码来手动在这两个状态之间移动–这是难看的命令式工作方式！
相反，当状态更改时，我们让SwiftUI在用户界面布局之间移动。我们已经根据用户登录或注销告诉了它要显示的内容，因此当我们更改身份验证状态时，SwiftUI可以代表我们更新UI。
这就是声明性的含义：我们不是要手动显示和隐藏SwiftUI组件，而是要告诉它要遵循的所有规则，而让SwiftUI确保这些规则得到强制执行。
但是SwiftUI不仅止于此：它还充当跨平台的用户界面层，可跨iOS，macOS，tvOS甚至watchOS运行。这意味着您现在可以学习一种语言和一种布局框架，然后将代码部署到任何地方。
SwiftUI vs Interface Builder和storyboards
全面更新了Xcode 11.2
每个经验丰富的iOS开发人员都熟悉Interface Builder和Storyboard，甚至XIB也是如此。他们可能不喜欢它们，但至少对它们熟悉。如果您以前没有使用过这些，你应该跳过这一步。
还在这里？这意味着您以前使用过IB，并且可能会对SwiftUI的不同感到好奇。
那么，让我问您一个问题：您是否曾经手动编辑storyboard或XIB？
可能没有。好吧，除了这一次之外，大体上答案是否定的——storyboards和XIBs包含大量不易阅读或编辑的XML。
更糟糕的是，storyboard有一个习惯是随着时间的推移越来越大。当然，它们可能从很小的地方开始，但是随后您又添加了另一个视图控制器和另一个视图控制器，然后突然您意识到在一个文件中有十个屏幕的数据，你所做的任何源代码管理更改都会突然变得非常痛苦。
但是，尽管单点故障并不好，当有人打开带有storyboard修改的拉取请求时，基本上不可能看到有什么变化，storyboards和XIBs还有一个更大的问题。
您会看到，Interface Builder对我们的Swift代码不太了解，而我们的Swift代码对Interface Builder也不太了解。结果，我们最终得到了许多不安全的功能：我们使用Ctrl从IB拖动到我们的代码中，将某物连接到一个动作，但是如果删除该动作，代码仍然可以编译——IB真的不介意它呼叫的代码是否已经不存在。
类似地，当我们从storyboard或表格视图单元中创建视图控制器时，我们使用字符串来标识代码中的重要对象——一个如此普遍的系统，它甚至拥有自己的名称：“字符串类型的API”。即使这样，我们也需要使用类型转换，因为Swift不能知道它返回的表视图单元实际上是一个MooncakeTableViewCell。
存在这些问题是因为IB和Swift是很独立的东西。这并不是一个很大的惊喜——Interface Builder不仅可以追溯到最初MacOSX出现之前，而且它也是围绕着Objective-C的工作方式而设计的。
SwiftUI在过去的基础上取得了重大突破。这是一个仅限Swift的框架，不是因为苹果公司认为Objective-C是时候死了，而是因为它让SwiftUI充分利用了Swift的所有功能——值类型，隐式返回类型，协议扩展等等。
不管怎样，我们将很快了解SwiftUI的工作原理。目前，您至少需要知道的是，SwiftUI修复了人们使用旧的Swift + Interface Builder方法所遇到的许多问题：
- 我们不必再争论基于程序或storyboard的设计，因为SwiftUI同时为我们提供了这两种设计。
- 在提交用户界面工作时，我们不再需要担心创建源代码控制问题，因为代码比storyboard的XML更易于阅读和管理。
- 我们不再需要为字符串类型的API担心太多了——虽然仍然有一些，但数量大大减少了。
- 我们不再需要担心不存在的调用函数，因为我们的用户界面已由Swift编译器检查。
因此，我希望您会同意，迁移到SwiftUI可以带来很多好处！
关于SwiftUI的常见问题
学习哪个：SwiftUI或UIKit？
在我问过的所有SwiftUI问题中，有一个比其他任何问题都多：“我正在学习Swift：我应该学习SwiftUI还是我也需要学习UIKit？”
人们似乎想听到的答案是“忘记旧的UIKit了，您应该专注于SwiftUI！”然而，一个简单的事实是，绝大多数人都不会从该建议中获得成功，这值得解释为什么一点细节。
在开始详细介绍之前，我想澄清一件事：SwiftUI是一个了不起的用户界面框架，并且绝对会100％成为Apple平台上应用程序开发的未来。但是，如果您想今天（或在未来一到两年左右的任何时间）构建出色的应用程序，那么您也100％绝对需要UIKit的知识，特别是如果您打算使应用程序开发成为您的职业。
好的，顺便说一句，在忽略UIKit的同时关注SwiftUI的问题归结为三点：
API覆盖范围有限。
限制采用。
支持有限。
让我们分解一下……
API覆盖范围有限
无论您是想在公司工作还是在业余时间开发业余爱好应用程序，SwiftUI的一个缺点是它目前没有与UIKit一样广泛的API覆盖范围。
例如，如果要在网格中显示项目，可以UICollectionView在UIKit中使用，但是SwiftUI没有等效项。或者，如果您想让用户输入多行文本，可以UITextView在UIKit中使用，但是SwiftUI也没有等效项。
这并不是苹果公司的懒惰，而是故意的：他们不是先发布所有API的包装器，而是在以后进行更改，而是采取更为谨慎的方法并逐步添加API。（我希望！）这应该减少我们将来看到的重大更改的数量，因为它使Apple的工程师有更多的时间来细化他们打算交付的API子集。
很多时候，您会找到解决方法，但是老实说，当您知道某个特定的东西在UIKit中是微不足道的，但是在SwiftUI中不是不可能的时候，这很累。有时甚至很简单：如何更改表上的分隔符插入？或如何将文本框添加到警报中？这些是UIKit中的单行代码，但在SwiftUI中不可用。
随着时间的流逝，我完全希望看到SwiftUI会增加更多功能，使其与UIKit达到同等水平，但是现在我们还有很长的路要走。
限制采用
SwiftUI仅在WWDC2019上宣布，并且可在iOS 13设备或更高版本中使用。这立即意味着：
迄今为止，几乎所有编写的应用程序都使用UIKit。
任何需要支持iOS n-1或n-2的应用程序（例如iOS 12和iOS 11）甚至都无法开始使用SwiftUI一年或更长时间。
这意味着，如果您打算在未来三年内找到一份iOS开发人员的工作，则UIKit经验实际上是必不可少的，因为这是现有代码库所使用的。实际上，我完全希望UIKit在四年后仍将是主导的UI平台。我想没有人-甚至没有苹果！–希望iOS社区能够以任何快速的步伐迁移到SwiftUI。在UIKit应用程序中有大量的代码，大量的时间和大量的资金，并且它拥有漫长而幸福的生活。
有些人试图在采用Swift和采用SwiftUI之间划清界限，这没有帮助。采用Swift的速度很快，因为它可以在Apple支持的每个框架（UIKit，SpriteKit等）中工作，并且还已经支持iOS n-1，因此许多公司可以立即切换到它。
再一次，我想重申，SwiftUI绝对将成为Apple平台开发的未来，但是要在UIKit级别获得采用将需要很长时间。
同时，SwiftUI是个人应用程序，爱好应用程序，原型应用程序或一般实验的理想选择。如果您有幸加入专门使用SwiftUI的公司，请尽情享受吧！
有限的支持
UIKit已有十多年的历史了，这意味着a）几乎您可能遇到的每个问题都已经被他人解决，并且b）那里有许多提供扩展和自定义功能的库。
尽管有些学习者可能会想到高级开发人员会掌握大量UIKit，但简单的事实是，我们所有人都使用Google，Stack Overflow，利用Swift进行黑客入侵等工具来找到问题的解决方案。当您绝望时，这可能实际上是将错误消息粘贴到网站中，但是无论您如何获得答案，它都可以节省大量在线查找错误消息的时间。
SwiftUI仅凭借显着更新而已，可用的解决方案却少得多。实际上，寻找从未有人尝试过的东西很普遍–实际上，您是第一人。这可能会很有趣，但是如果您有一个实际要交付的实际项目，那也可能会令人沮丧。
所以……您是说我不应该学习SwiftUI吗？
没有！SwiftUI非常有趣，您可以用它来构建奇妙的东西。本书的其余全部内容旨在帮助您尽快高效地开始使用SwiftUI –如果我不认为SwiftUI很棒，我不会写它。
我要说的是，SwiftUI的存在并没有以某种方式使UIKit过时：如果您打算在未来三年内获得iOS开发工作，那么知道如何使用UIKit将会是一项坚定的要求或一个强大的要求。奖金。
因此，直接回答这个问题：是的，应该忙于学习SwiftUI，因为这是在苹果平台上进行应用程序开发的未来，但是您仍然需要学习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不是一个多平台框架，而是一个用于在多个平台上创建应用程序的框架。
听起来可能是一样的，但是有一个重要的区别：Apple并不是说您可以在每个平台上使用相同的SwiftUI代码，因为有些事情是不可能的–无法在Mac上使用Apple Watch的数字王冠例如，并且类似地在watchOS应用上具有选项卡栏也将无法工作。
SwiftUI会取代UIKit吗？
不会。SwiftUI的许多部分都直接建立在现有UIKit组件之上，例如UITableView。当然，许多其他部分则没有，它们是SwiftUI而非UIKit呈现的新控件。
但是重点不是UIKit涉及的程度。相反，关键是我们不在乎。SwiftUI或多或少完全掩盖了UIKit的行为，因此，如果您为SwiftUI编写应用程序，并且Apple在两年内用唱的大象代替了UIKit，那么您不必在乎–只要Apple使大象具有相同的方法和属性即可该UIKit暴露于SwiftUI，您的代码不变。
SwiftUI是否使用自动布局？
尽管Auto Layout肯定会在幕后用于某些事情，但作为SwiftUI设计师并没有暴露给我们。取而代之的是，它使用了灵活的盒式布局系统，这对于来自Web的开发人员来说将是熟悉的。
SwiftUI快吗？
SwiftUI是令人讶异的快-在所有我的测试中，到目前为止，似乎超越的UIKit。与做到这一点的团队交谈后，我开始明白为什么：首先，他们积极地扁平化图层层次结构，这样系统就不必做更多的绘制了，但是第二步，很多操作完全绕过了Core Animation，直接去了Metal进行了额外的处理。速度。
所以，是的：SwiftUI的速度非常快，而且所有这些都无需我们做任何额外的工作。
为什么看不到我的代码预览？
使用SwiftUI时，能够同时查看视图代码和视图预览（外观）非常有帮助。如果您可以看到代码而不是预览，则可能是您尚未升级到macOS 10.15；必须进行预览才能正常工作。
代码与预览的匹配程度如何？
对预览进行任何更改时，它也会更新生成的代码。同样，如果更改代码，它也会更新用户界面。因此，代码和预览是相同的，并且始终保持同步。
为什么我的颜色看起来有点偏？
SwiftUI为我们提供了标准的系统颜色，例如红色，蓝色和绿色，但是这些并不是您习惯于使用的纯红色，蓝色和绿色UIColor。取而代之的是，这些是可以自动适应明暗模式的新样式颜色，这意味着根据您的系统外观，它们看起来会更亮或更暗。
UIKit死了吗？
没有！苹果在本周的WWDC上播出了大量的新UIKit功能。如果Apple仍在WWDC上谈论UIKit的新功能，那您就很安全-没有使他们惊讶地淘汰它的风险。
您可以混合使用SwiftUI和UIKit的视图吗？
是! 您可以将一个嵌入另一个，效果很好。
网友评论