在iOS编程中使用Storyboard而不是xib文件有什么好处？
使用Storyboard和xib文件的主要区别是什么？
具体来说，使用Storyboard有哪些优缺点 ？
不幸的是，尽pipe做了相当多的研究，但在Storyboard上能find的只是一个简单的教程，告诉你如何设置一个Storyboard，而不是具体的信息来解释它们是什么。
故事板是：
- 所有场景的容器（视图控制器，导航控制器，TabBar控制器等）
- 这些场景之间的连接和转换pipe理器（这些被称为Segues）
- 一个很好的方法来pipe理不同的控制器如何互相交谈
- 故事板让你全面了解你的应用程序的stream程，你永远不会从浮动的单独的笔尖文件中获得。
- 当你有几个控制器，每个都有它自己的nib文件时，发生所有“混乱”的减速器。
我一直在使用Storyboards，唯一的缺点是你不能瞄准iOS 4或更低版本。 故事板仅适用于运行iOS 5或更高版本的设备。 除此之外，好处是很多，缺点是IMO不存在。
我见过的最好的教程是Ray Wenderlich的
另外，如果你是苹果开发者计划的成员，去看看去年的故事板（iTunesU）上的WWDC会议，这是真棒。
另一个伟大的（也在iTunesU上）是最新的斯坦福大学iOS应用程序编程课程。
故事板不仅有正面，也有缺点 – 只是因为你要求input：
- 与团队中的SB一起工作并不容易，因为只有一个参与者可以同时在SB上工作（因为它是一个文件）。
– 以下是不正确的： – 如果你需要做SB没有提供的东西，那么把SB与编程创build的视图混合起来并不是一件容易的事（但是，尽pipe这是可能的）
经验法则似乎是：你期望你的项目越复杂，你最好不要去SB。
编辑：SB的另一个缺点：解决所有关于SB的XCode的烦人的错误。 比如不得不频繁刷新DerivedData文件夹，因为有一些不一致的地方。 有时故事板文件或链接到他们被损坏。 那么你可能会喜欢寻找这个问题。 看看这个线程得到的想法
编辑2（2013年3月）：故事板和Xcode工作得更好，文档和最佳实践广泛传播。 我认为与故事板的合作可以被推荐用于大多数的项目，即使还有一些小故障。
编辑3（2013年9月）：现在与新的Xcode 5格式与SB团队工作可能会变得更好，因为它似乎变得可以合并SB代码更容易了。
另一个编辑：好吧，如果你有一个小时的时间，坐下来，放松， 听听这些讨论这个话题的家伙（Ray Wenderlich＆Co）
编辑2016.1：经过很长一段时间的故事板的倡导者之后，我在过去的几个月里有这么多的麻烦，我决定尽可能地放弃故事板。 原因是苹果增加了像愚蠢的function，但不关心错误和缺陷。 具有大量自动布局约束的性能非常糟糕（而devise时间），并且容易出错的性能变得非常大。 例如：更简单的故事板在Xcode中打开一个项目后，往往会进入“脏模式”（请参阅git状态）。 提示：作为一个初学者，你会喜欢故事板，因为你可以快速原型，让事情运行没有太多的代码。 当你进入一个中间状态，你会添加更多的GUI代码到你的项目。 现在你开始在代码和SB之间来回切换，事情开始变得更糟。 迟早你会倾向于在代码中执行大部分GUI工作，因为结果比有多个源更容易预测。
概要
Nibs / .xib文件和Storyboard都是Interface Builder文件，用于在Xcode中为iOS和Mac应用程序直观地创build用户界面（我将使用iOS术语作为此类问题标记为iOS的术语，但也适用于Mac编程） 。
差异
笔尖旨在与单个UIView一起使用。 通过设置File的Owner类到UIViewController任何子类并连接视图sockets（使用Xcode的最右侧窗格中的Connections Inspector进行连接），它们也可以连接到UIViewController子类。
故事板旨在包含一个或多个UIViewController的用户界面。 您可以在单个故事板中构build整个用户界面，也可以将其分成较小的部分。
优点
应始终使用故事板，以支持.xib文件/ Nib（视图控制器）。 故事板有更多的function，并由苹果积极开发。
每个支持Nibs的论点都依赖于他们单独使用的事实，而故事板包含许多场景。 您可以像使用Nib一样轻松地为每个UIViewController使用单个故事板（请参阅下面的代码示例）。 请继续阅读以获得详细的解释和代码示例。
详细
为什么Storboard优于Nibs？
答案基本上归结为苹果鼓励使用Storyboard并将更多的开发工作付诸于其中。
- 故事板具有Nibs缺乏的缩放function。 严重的是，你不能放大缩小在笔记本电脑大屏幕devise时吸吮。
- 笔尖缺less如下关键function：
-
UITableView原型和dynamic单元（ 更多信息 ） - 顶部布局指南属性（请参阅评论）
- 有可能更多，请编辑或评论，如果你有什么要添加到这个列表
-
- 你不需要搞乱设置文件所有者的类。
反对故事板的基本观点是，将所有的视图控制器放在一个地方会导致合并冲突，缓慢的Xcode，缓慢的构build时间，并成为维护对象的普遍痛苦。 因此，一般的build议是为每个UIViewController使用一个Nib。
但是…您可以为每个UIViewController创build故事板。 一个普遍的习惯（至less对我来说）是将所有的UIViewController初始化隐藏在类方法中（因为没有其他类需要知道控制器的Nib / Storyboard所在文件的名称）。 让我们比较一下可能用来创build这种方法的相关代码片段。 一行代码是两者之间的全部区别。
Objective-C的
故事板
+ (ViewController *)create { UIStoryboard *storyboard = [UIStoryboard storyboardWithName:@"ViewController" bundle:nil]; return [storyboard instantiateInitialViewController]; }
笔尖
+ (ViewController *)create { return [super initWithNibName:@"ViewController" bundle:nil]; }
用法
- (void)showMyViewController { ViewController *vc = [ViewController create]; [self presentViewController:vc animated:YES completion:nil]; }
迅速
故事板
static func create() -> ViewController { let storyboard = UIStoryboard(name: "ViewController", bundle: NSBundle.mainBundle()) return storyboard.instantiateInitialViewController() as! ViewController }
笔尖
static func create() -> ViewController { return ViewController(nibName: "ViewController", bundle: nil) }
用法
func showMyViewController() { let vc = ViewController.create() self.presentViewController(vc, animated: true, completion: nil) }
参数
我会解决所有关于尼布斯的常见论点。 正如我前面提到的，主要是支持单个文件，而不是作为故事板上的Nibs的参数
- 团队和合并
参数：如果您正在与多人进行更改的团队一起工作，则拥有大量视图控制器的故事板会导致合并冲突
回应：单个故事板不会导致比单个Nib更多的合并冲突
- 复杂
参数：非常复杂的应用程序在故事板中有很多场景，导致一个巨大的故事板需要永久加载，并且由于其尺寸而难以理解。
回应：这是一个很好的观点，但是您可以轻松地将Storyboard分解成更小的部分。 故事板参考看起来像一个很棒的function，可以用来将故事板链接在一起，但它们只能在Xcode 7 / iOS 9+中使用。 此外，仍然不是select故事板上的单个Nibs的原因。
- 可重用性
参数：为每个UIViewController子类创build一个Nib让您重用代码，所以您不必为故事板中的每个场景设置所有约束和出口。
回应：同样，不是select个别故事板上的个别Nibs的理由。
在几个月前的LiDG会议上，有关Storyboard的一个很好的演示 。
就个人而言，我会说这是一个新的应用程序的方式。 有一些差距，尤其是对于非常复杂的应用程序，但亲们主要是大于缺点。
故事板的更多优点：
- 故事板对桌面视图有更好的支持。 那就是你可以使用“dynamic”和“原型”单元。
- 使用故事板实例化视图控制器更容易。 你可以做这样的事情：[se lf.storyboard instantiateViewControllerWithIdentifer：]
- 故事板支持视图控制器容器，所以你可以让子视图控制器以graphics方式布局。
缺点是：
-
当XCode包含大量视图控制器时，故事板渲染缓慢
-
故事板中的一个视图控制器不能启用Autolayout。
要小心，如果您使用Storyboard，则您的应用程序不能与旧版OS安装向后兼容。
故事板基本上是一个使您的开发工作更容易的设备。 它被编译成一系列的nib文件，所以性能几乎相当，但作为开发人员能够快速查看整个应用程序stream程，这非常棒。
我开始转向在新项目中使用情节提要，只要我能说服客户接受iOS 5作为最低版本。 这纯粹是因为我喜欢这样做，而且要花更less的时间完成相同的任务。
您对自动布局的态度也可能会影响您是否要使用情节串连图板。 使用xibs，你可以启用或禁用自动布局，每个.xib的基础上，允许你的应用程序混合，而故事板适用于你所select的所有视图，其中包含。
你一秒钟就能看到大局。 有很多的NIB文件，好吧，你看不到大的图片。 更容易维护您的程序。 更容易理解别人的节目…等等。
优点：
1）devise界面非常好
2）您可以使用StoryBoard Segues以冷静的方式识别导航/模式关系。
3）如果你的应用程序支持多种设备，这是组织不同视图的好方法。
4）原型是另一个附加优势。
5）原型UITableViewCell可以节省时间，也可以减less代码量。
6）通过使用StoryBoard，你可以在一个地方看到应用程序的所有屏幕。
7）您可以轻松查看它们之间的关系
8）如果您正在处理某人的代码，您可以更好地了解应用程序的stream程。
9）你可以设置iPhone 4和iPhone 5的用户界面，通过应用故事板的视网膜形状因子，而无需反复运行应用程序。
10）在开始开发之前，客户可以看到应用程序的原型，这里storyboard可以帮助你很多。
缺点：
1）它只适用于iOS 5+
2）StoryBoardSegues是僵硬的，你可以多次使用prepareForSegue。
4）像IB一样，与其他显示引擎和工具包不太友好。
4）很难分享devise的一个单一的观点或意见 – 你必须发送全部或没有。
5）对于故事板，您将需要一个专门用于iPad的大屏幕。
6）从其他应用程序复制到故事板的难度。
7）当多个开发人员使用git仓库在同一个项目上工作时，故事板中的问题
8）故事板没有提到的另一个缺点是
从一些资源复制
在iOS 7之前，故事板是一种整洁，但不是必须的。 他们解决了许多问题。 iOS 7向故事板倾斜平衡。
使用iOS 8和9，这不再是一个问题：使用故事板！
故事板的主要缺点是，你完全依赖于XCode，而最终你可能花费数小时在XCode上运行。 但是，XCode已经变得更好了，故事板的优势现在已经不胜枚举了。 表格视图单元格原型，大小类，自动布局支持等等。
一些技巧：
- 将每个Storyboard视为属于一个视图控制器的容器。 不要把它看作是整个应用程序的macros伟布局。
- 您可能需要多个Storyboard
- Segmentation对于最微不足道的用例实际上是有用的 – 对于这些用例来说非常有用。 但是在现实世界的应用程序中，许多转换将从代码中发生。 这没关系。
- 编写一个类别以编程方式从storyboard（s）实例化视图控制器，所以你所要做的就是让vc = SomeViewController.create（），其中方法处理所有的细节（拉故事板，把视图控制器拉出故事板等）。
