功能差异，UINavigationController vs Only Storyboard Segue

Posted 2023-03-22

【中文标题】功能差异，UINavigationController vs Only Storyboard Segue

【英文标题】：Functional difference, UINavigationController vs Only Storyboard Segue

【发布时间】：2015-03-31 01:19:28

【问题描述】：

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

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

实施UINavigationController 的优点是什么？

【问题讨论】：

这个标题和前提（将UINavigationController 与故事板segue 进行比较）对我来说毫无意义......

所以我正在开发一个应用程序，我已经将故事板与所有 VC 相结合，我从未使用过 UINavigationController....我想知道我是否错过了重要的概念通过不学习 UINavigationController。

我认为你使用的是 segue 这个词，而你应该使用模态这个词。如果您在没有导航控制器的情况下使用 segues，那么您正在执行模态 segues（而不是使用导航控制器所拥有的 push segues）。对于使用模式与推送的原因，您的理解基本上是正确的。一般来说，模态呈现的控制器应该用于中断应用程序的一般流程，您需要从用户那里获取一些信息。

但是在情节提要中，当创建“segue”时，“present modalally”和“show (e.g. push)”都是选择？

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

【讨论】：

好的，所以我有两个“主要”VC，每个都有很多事情要做，而较小的“popover-like”VC 则从这两个中传播开来......而且我只是想通过 Segue我的应用程序可能会占用大量资源，因为让一个主 VC 在后台运行并保存数据，而第二个主 VC 在顶部运行。

既然你不明白将导航控制器与segue进行比较是没有意义的，我建议你直接写代码，看看它是否会导致你怀疑可能的问题，当它出现时，将其带回并发布带有实际问题的实际代码。到那时，希望你能有更好的理解。

我理解这一理念，但我更愿意从一开始就将学习重点放在正确的概念上，而不是仅仅为了以后学习正确的技术而学习低于标准的解决方法。并且由于您声明，“您可以使用带有或不使用 segue 的导航控制器。您可以使用带或不带导航控制器的 segue。”比较它们似乎并不完全荒谬。它们是展示 VC 的两种不同方式，各有利弊。我很感激这些信息。

感谢您的回复。我想我只是不明白只有带有初始 VC 的故事板 segues 与带有根 VC 的 UINavigationalController 之间的功能差异

我认为这是一个有效的问题。也许这是某些人的想法，但我可以理解@Dustin 对他的查询的含义。这个问题帮助我找到了我的实际问题，我只是用错误的词来思考它:)