功能差异，UINavigationController vs Only Storyboard Segue

Question

所以UIKit Framework Reference 将UINavigationController 描述为向用户呈现数据和视图的有效方式。但我很好奇使用UINavigationController VS SegueOnly 之间的性能和可管理性差异。

在某些情况下，其中一种比另一种更适合。我对编码是全新的，但本能地我认为UINavigationController 更适合展示每个都有很多事情的 VC，用户在每个 VC 上花费大量时间，或者多个 VC 需要同时运行和保存数据。而Segue 更适合单向 VC 进展或短期使用、低数据 VC 演示。这些假设是否正确？

实施UINavigationController 的优点是什么？

Answer 1

这是 Apples 与 套筒扳手 的比较。导航控制器与 segue 甚至不是一个选项。他们没有扮演相同的角色。您可以使用带有或不使用 segue 的导航控制器。您可以使用带或不带导航控制器的 segue。

UINavigationController 是一种特定类型的视图控制器。具体来说，它是为控制视图控制器的导航堆栈而设计的。当用户在您的应用程序中前进时，您将其他视图控制器添加到此导航堆栈（通过 segues 或通过视图控制器上可用的其他方法来呈现其他视图控制器）。同时，导航控制器允许您从堆栈中“弹出”控制器，然后我们返回到前一个视图控制器。

当我们将UINavigationController 与事物进行比较时，我们应该将其与诸如UITabBarController、UISplitViewController 或UIPageViewController 之类的事物进行比较。这些是其他类型的视图控制器，它们控制用户在我们的应用中导航的方式。

Segue 的存在是一种从一个视图控制器到另一个视图控制器的方法。但是我刚刚列出的各种控制器是作为控制控制器之间导航关系的一种方式存在的。

如果您使用故事板来构建您的应用程序，我强烈建议您使用 segue。是否使用导航控制器完全取决于您希望应用程序导航的工作方式。

---

也许有些图片可能会使区别更清楚？

展品 A

这里我们有两个视图控制器。没有导航控制器，什么都没有。只有两个普通控制器。视图控制器之间带有箭头的线是segue。 segue 定义了视图控制器之间的关系，它让我们从左边的那个到右边的那个。

展品 B

这里我们有一个导航控制器，然后是两个视图控制器。导航控制器（最左边）和第一个视图控制器（中间）之间的线不是一个segue。但是，它确实定义了导航控制器和视图控制器之间的关系。它将视图控制器定义为导航控制器的 root 视图控制器。每当我们呈现这个导航控制器时，它会依次呈现这个视图控制器作为其导航堆栈上的第一个控制器。然而，第一个视图控制器（中间）和第二个视图控制器（最右边）之间的界线， 是一个segue。它与展览 A 的转场相同（除了展览 A 可能是不同的转场 type）。这个 segue 定义了第一个和第二个视图控制器之间的关系，并为我们提供了一种从第一个到第二个的方法。

展品 C

这里我们有一个标签栏控制器（最左边）和四个视图控制器。我们还有更多的线路连接这些东西。导航控制器示例中的很多行，标签栏控制器和视图控制器之间的线不是segues，但它们确实定义了标签栏控制器和视图控制器之间的关系。这些行将视图控制器分配为选项卡栏控制器的viewControllers 数组的一部分，该数组确定要显示哪些选项卡。然而，左视图控制器和右视图控制器之间的线是连续的，与前两个示例完全相同。

---

转场没什么，只不过是在故事板上定义两个视图控制器之间的导航关系的一种方式。如果你没有使用故事板，你也根本不会使用 segues，但你仍然可以让你的应用程序以完全相同的方式导航（这都可以在没有故事板和没有 segues 的情况下以编程方式实现——而且我不要认为它会影响表演或其他）。

是否使用导航控制器是另一个问题，并且是一个完全独立的问题。是否使用导航控制器与您是否使用 segues 甚至不在同一个球场。使用导航控制器也不是性能问题。使用导航控制器的开销非常小。它的大部分开销可能来自它添加的 UI 内容......但是如果你想要那些 UI 内容，无论你是否有导航控制器，你都会有这些开销。

重要的是，是否使用 segues 不是性能问题，而只是您是否使用故事板设计应用的问题。同样重要的是，使用导航控制器不是性能问题——而是您希望应用程序的导航外观和感觉如何的问题。 “导航控制器是否适合您的应用程序的外观和感觉？”在决定是否使用导航控制器时，实际上是您必须回答的唯一问题。