1.Is SwiftUI fast?
SwiftUI is screamingly fast – in all my tests so far it seems to outpace UIKit. Having spoken to the team who made it I’m starting to get an idea why: first, they aggressively flatten their layer hierarchy so the system has to do less drawing, but second many operations can bypass Core Animation entirely and go straight to Metal for extra speed.
So, yes: SwiftUI is incredibly fast, and all without us having to do any extra work.
译文:
SwiftUI的速度惊人——在我目前的所有测试中，它似乎都超过了UIKit。在与制作团队交谈之后，我开始了解原因：
- 首先，他们积极地扁平化了层层次结构，这样系统就需要更少的绘图;
- 但第二，许多操作可以完全绕过核心动画，直接使用Metal来提高速度。 所以：SwiftUI速度非常快，而且我们不需要做任何额外的工作。
2.Does SwiftUI use Auto Layout?
While Auto Layout is certainly being used for some things behind the scenes, it’s not exposed to us as SwiftUI developers. Instead, it uses a flexible box layout system that will be familiar to developers coming from the web.
译文:
虽然Auto Layout的确被用于一些场景，但作为SwiftUI开发人员，这并不是我们期望的。取而代之的是，它使用了一个灵活的方框布局系统(flexible box layout system )，这对来自web开发人员来说是熟悉的。
3.Is UIKit dead?
No! Apple introduced huge amounts of new functionality at both WWDC19 and WWDC20. If Apple are still doing WWDC talks about new features in UIKit, you’re quite safe – there’s no risk of them retiring it by surprise.
译文:
不苹果在WWDC19和WWDC20上推出了大量新功能。如果苹果仍在进行WWDC关于UIKit新功能的讨论，那么你是相当安全的——他们不会意外地取消它。
4.Can you mix views from SwiftUI and UIKit?
Yes! You can embed one inside the other and it works great.
5.Does SwiftUI replace UIKit?
No. Many parts of SwiftUI directly build on top of existing UIKit components, such as UITableView. Of course, many other parts don’t – they are new controls rendered by SwiftUI and not UIKit.
But the point isn’t to what extent UIKit is involved. Instead, the point is that we don’t care. SwiftUI more or less completely masks UIKit’s behavior, so if you write your app for SwiftUI and Apple replaces UIKit with a singing elephant in two years you don’t have to care – as long as Apple makes the elephant compatible with the same methods and properties that UIKit exposed to SwiftUI, your code doesn’t change.
译文:
不需要。SwiftUI的许多部分直接构建在现有UIKit组件之上，例如UITableView。当然，许多其他部分不是这样的——它们是由SwiftUI呈现的新控件，而不是UIKit。
但关键不在于UIKit的参与程度。相反，关键是我们不在乎。SwiftUI或多或少完全屏蔽了UIKit的行为，因此，如果你使用SwiftUI编写应用程序，苹果在两年内用一直会鼓励SwiftUI替换UIKit，你就不必在意了——直要苹果UIKit向SwiftUI公开的相同方法和属性兼容，你的代码就不会改变。
6.Where can SwiftUI be used?
SwiftUI runs on iOS 13, macOS 10.15, tvOS 13, and watchOS 6, or any future later versions of those platforms. This means if you work on an app that must support iOS N-1 or even N-2 – i.e., the current version and one or two before that – then you will be limited in terms of the features you can offer.
However, it’s important you don’t think of SwiftUI as being a multi-platform framework similar to Java’s Swing or React Native. The official line seems to be that SwiftUI is not a multi-platform framework, but is instead a framework for creating apps on multiple platforms.
That might sound the same, but there’s an important difference: Apple isn’t saying that you can use identical SwiftUI code on every platform, because some things just aren’t possible – there’s no way to use the Apple Watch’s digital crown on a Mac, for example.
译文:
SwiftUI在iOS 13、macOS 10.15、tvOS 13和watchOS 6上运行，或在这些平台的任何未来更高版本上运行。这意味着，如果你使用的应用程序必须支持iOS N-1甚至N-2，即当前版本和之前的一个或两个版本，那么你可以提供的功能将受到限制。
但是，重要的是，不要将SwiftUI视为类似于Java的Swing或React Native的多平台框架。官方说法似乎是，SwiftUI不是一个多平台框架，而是一个在多个平台上创建应用程序的框架。
这听起来可能是一样的，但有一个重要的区别：苹果并不是说你可以在每个平台上使用相同的SwiftUI代码，因为有些事情是不可能的——例如，在Mac电脑上使用Apple Watch的数字皇冠是不可能的。
7.为什么 SwiftUI 不允许一个父节点拥有超过 10 个视图?
是这样的，如果你创建一个 VStack ，里面有两个文本视图，SwiftUI 会静默地创建一个TupleView ，包含这两个文本视图 —— 这是一种特殊的视图，它只包含两个视图在里面。因此，VStack实际上是以包含两个文本视图的TupleView 来回答那个问题。
如果 VStack里有三个文本视图呢? 那么就会是一个包含三个视图的 TupleView，或者 4 个视图，8个视图，甚至 10 个视图 —— 确实有可以追踪 10 个不同类型内容的TupleView 版本：
TupleView<(C0, C1, C2, C3, C4, C5, C6, C7, C8, C9)>
这也是为什么 SwiftUI 不允许一个父节点拥有超过 10 个视图：他们写了可以处理 2 个视图到 10 个视图的 TupleView 版本，但不支持更多了。
