问题
So UIKit Framework Reference describes UINavigationController as an efficient way to present data and views to user. But I'm curious as to the performance and manageability differences between using UINavigationController VS SegueOnly.
There must be certain situations that one is better-suited than the other. I am entirely new to coding but instinctually I imagine UINavigationController is more for presenting VC's that each have a lot going on and user spends much time on each VC equally or that multiple VC's need to be running and holding data at same time. And that Segue are more for Uni-directionally VC progression or short-use, low-data VC presentations. Are any of these assumptions correct?
What are the PROS to implementing a UINavigationController?
回答1:
This is an Apples to Socket-wrenches comparison. A navigation controller versus a segue isn't even an option. They don't fill the same role. You can use a navigation controller with or without using segues. You can use segues with or without a navigation controller.
A UINavigationController is a specific type of view controller. Specifically, it is designed for controlling a navigation stack of view controllers. When a user moves forward through your app, you add other view controllers to this navigation stack (either through segues or through other methods available on the view controller to present other view controllers). Meanwhile, the navigation controller allows you to "pop" controllers off the stack and we go backward to the previous view controller.
When we're comparing a UINavigationController to things, we should compare it to things like UITabBarController, or UISplitViewController, or UIPageViewController. These are other types of view controllers that control the way in which a user navigates through our app.
Segues exist as a means to get from one view controller to another. But the various controllers I just listed exist as a means for controlling the navigational relationship between your controllers.
If you are using storyboards for building your app, I highly recommend that you use segues. Whether or not you use a navigation controller is entirely up to the way you want your application navigation to work.
Perhaps some pictures might make the distinction more clear?
Exhibit A
Here we have two view controllers. No navigation controller, nothing. Just two normal controllers. The line with the arrow between the view controllers is the segue. The segue defines a relationship between the view controllers which lets us get from the one on the left to the one on the right.
Exhibit B
Here we have a navigation controller, followed by two view controllers. The line between the navigation controller (far left) and the first view controller (middle) is not a segue. However, it does define a relationship between the navigation controller and the view controller. It defines the view controller as the navigation controller's root view controller. Whenever we present this navigation controller, it will in turn present this view controller as the first controller on its navigation stack. The line between the first view controller (middle) and the second view controller (far right), however, is a segue. It's identical to the segue from exhibit A (except exhibit A is probably a different type of segue). This segue defines a relationship between the first and second view controller and provides us with a means of getting from first to second.
Exhibit C
Here we have a tab bar controller (far left) and four view controllers. We also have a bunch more lines connecting these things. Much line in the navigation controller example, the lines between the tab bar controller and the view controllers are NOT segues, but they do define a relationship between the tab bar controller and the view controllers. These lines assign the view controllers as part of the tab bar controller's viewControllers array, which determines what tabs to display. The lines between the left view controllers and the right view controllers, however, are segues, exactly the same as the first two examples.
A segue is nothing more than a way of defining a navigational relationship between two view controllers on your storyboard. If you weren't using a storyboard, you also wouldn't be using segues at all, but you could still make your app navigate in the exact same manner (this can all be achieved programmatically without the storyboard and without segues--and I don't think it effects performances on way or another).
Whether or not to use a navigation controller is another question and an entirely separate question at that. Whether or not to use a navigation controller isn't even remotely in the same ballpark to whether or not you're using segues. Using a navigation controller also isn't a question of performance. The overhead for using a navigation controller is extraordinarily minor. Most of the overhead for it probably comes from the UI stuff it adds... but if you want that UI stuff, you're going to have that overhead whether or not you have a navigation controller.
Importantly, whether or not to use segues isn't a question of performance--it's merely a question of whether or not you're designing your app using storyboards. And equally importantly, using navigation controllers isn't a question of performance--it's a question of how you want your app's navigation to look and feel. "Is a navigation controller the right look and feel for your app?" is literally the only question you have to answer when deciding whether or not to use a navigation controller.
来源：https://stackoverflow.com/questions/29359037/functional-difference-uinavigationcontroller-vs-only-storyboard-segue