很多人在问我关于 SwiftUI 的问题,我也已经尽力去问其他知道得更多的人,并试图找到合适的明确答案。
所以,现在开始...
这个问题已经被问过很多次了,所以我在本书中专门加了一章,以便能更详细地回答这个大问题:你应该学习 SwiftUI,UIKit,还是两者都学?
SwiftUI 可以在 iOS 13、macOS 10.15、tvOS 13 和 watchOS 6,以及这些平台的后续版本上运行。这意味着,如果你从事开发的应用必须支持 iOS N-1 甚至 N-2 ——即当前版本和之前的一两个版本--那么你能提供的功能就会受到限制。
然而,重要的是你不要把 SwiftUI 想成是一个类似于 Java 的 Swing 或 React Native 的多平台框架。官方的说法似乎是,SwiftUI 不是一个多平台框架,而是一个在多平台上创建应用程序的框架。
这听起来可能是一样的,但有一个重要的区别。苹果并不是说你可以在每个平台上使用相同的 SwiftUI 代码,因为有些事情是不可能的--例如,没有办法在 Mac 上使用苹果手表的数字表冠。
SwiftUI 的许多部分直接建立在现有的 UIKit 组件之上,例如 UITableView。当然,还有许多其他部分不是--它们是由 SwiftUI 而非 UIKit 渲染的新控件。
但问题的关键不在于 UIKit 在多大程度上参与其中。相反,重点是我们并不关心。SwiftUI 或多或少地完全掩盖了 UIKit 的行为,所以如果你为 SwiftUI 编写应用程序,而即使苹果在两年内用一只会唱歌的大象取代了 UIKit,你也不必在意--只要苹果让大象兼容 UIKit 暴露给 SwiftUI 的相同方法和属性,你的代码就不会改变。
虽然 Auto Layout 肯定被用于幕后的一些事情,但它并没有暴露给我们这些 SwiftUI 开发者。相反,它使用了一个灵活的盒式布局系统,这对来自 web 端的开发者来说是很熟悉的。
SwiftUI 的速度快得惊人--在我迄今为止的所有测试中,它似乎都超过了 UIKit。在与制作它的团队交谈后,我开始明白了其中的原因:首先,他们积极地扁平化了他们的层级结构,所以系统执行了更少的绘制,但其次,许多操作可以完全绕过 Core Animation,直接进入 Metal 以获得额外的速度。
所以,是的:SwiftUI 的速度快得惊人,而且我们不需要做任何额外的工作。
在使用 SwiftUI 时,能够同时看到视图的代码和视图的预览--它的外观--是非常有用的。 如果你能看到代码而不是预览,那么你有可能需要进入编辑器菜单并确保 Canvas 已启用。
当你对预览做任何改变时,它也会更新生成的代码。同样地,如果你改变了代码,它也会更新用户界面。因此,代码和预览是相同的,并始终保持同步。
SwiftUI 给我们提供了标准的系统颜色,如红色、蓝色和绿色,但这些并不是你可能习惯的 UIColor 的纯红色、蓝色和绿色。相反,这些是自动适应明暗模式的新风格颜色,这意味着它们会根据你的系统外观看起来更亮或更暗。
不!苹果在 WWDC19 和 WWDC20 都推出了大量的新功能。如果苹果仍然在 WWDC 上谈论 UIKit 的新功能,那么你就相当安全了--他们不会有出其不意地退役的风险。
可以!你可以把一个嵌入到另一个里面,而且效果很好。