功能差异,UINavigationController vs Only Storyboard Segue

Question

因此,UIKit框架参考描述UINavigationController了向用户呈现数据和视图的有效方式.但我很好奇使用UINavigationControllerVS SegueOnly 之间的性能和可管理性差异.

必须有某些情况,一个比另一个更适合.我对编码完全不UINavigationController熟悉,但我本能想到的更多是为了呈现VC,每个VC都有很多,并且用户在每个VC上花费的时间相同,或者需要多个VC同时运行和保存数据.这Segue对于Uni-directionalally VC进展或短期使用的低数据VC演示更为重要.这些假设是否正确？

实施a的PROS有UINavigationController哪些？

Answer 1

这是一个苹果对套筒扳手的比较.导航控制器与segue甚至都不是一种选择.他们没有扮演同样的角色.您可以在使用或不使用segue的情况下使用导航控制器.您可以使用带或不带导航控制器的segue.

A UINavigationController是特定类型的视图控制器.具体而言,它被设计用于控制视图控制器的导航堆栈.当用户向前移动您的应用程序时,您将其他视图控制器添加到此导航堆栈(通过segue或通过视图控制器上可用的其他方法呈现其他视图控制器).同时,导航控制器允许您从堆栈"弹出"控制器,然后我们返回到前一个视图控制器.

当我们将a UINavigationController与事物进行比较时,我们应该将它与诸如UITabBarController或者UISplitViewController或之类的东西进行比较UIPageViewController.这些是其他类型的视图控制器,用于控制用户浏览应用程序的方式.

Segues作为从一个视图控制器到另一个视图控制器的手段而存在.但是我刚才列出的各种控制器作为控制控制器之间导航关系的手段而存在.

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

也许一些图片可能会使区别更清晰？

图表A.

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

图表B

这里我们有一个导航控制器,后面是两个视图控制器.导航控制器(最左侧)和第一个视图控制器(中间)之间的线不是 segue.但是,它确实定义了导航控制器和视图控制器之间的关系.它将视图控制器定义为导航控制器的根视图控制器.每当我们提供此导航控制器时,它将依次将此视图控制器作为其导航堆栈上的第一个控制器.然而,第一视图控制器(中间)和第二视图控制器(最右侧)之间的线是 segue.它与展览A的segue相同(除了展览A可能是不同类型的segue).这个segue定义了第一个和第二个视图控制器之间的关系,并为我们提供了从第一个到第二个的方法.

图表C

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

segue 只不过是在故事板上定义两个视图控制器之间的导航关系的一种方式.如果你没有使用故事板,你根本就不会使用segues,但你仍然可以让你的应用程序以完全相同的方式导航(这可以通过编程方式实现,无需故事板和没有segues - 我不要认为它影响表演或其他方式).

是否使用导航控制器是另一个问题,也是一个完全独立的问题.无论是否使用导航控制器,您都不会在同一个球场中与您是否使用segue进行远距离操作.使用导航控制器也不是性能问题.使用导航控制器的开销非常小.它的大部分开销可能来自它添加的UI内容......但是如果你想要那些UI的东西,无论你是否有导航控制器,你都会有这个开销.

重要的是,是否使用segues不是性能问题 - 这只是一个问题,即您是否使用故事板设计应用程序.同样重要的是,使用导航控制器不是性能问题 - 这是一个关于您希望应用程序导航的外观和感觉的问题."导航控制器是否适合您的应用？" 在确定是否使用导航控制器时,您必须回答这个问题.