使用 Storyboard 和 xib 文件有哪些主要区别。
具体来说， 使用 Storyboard 有哪些优点或缺点？
不幸的是，尽管进行了大量研究，但我在 Storyboards 上找到的只是简单的教程，它们向您展示了如何设置 Storyboard，而不是解释它们是什么的具体信息。
【问题讨论】：
标签： ios xcode storyboard interface-builder xib
故事板是：
我使用 Storyboards 已经有一段时间了，唯一的缺点是你不能针对 iOS 4 或更低版本。故事板仅适用于运行 iOS 5 或更高版本的设备。除此之外，好处很多，缺点是不存在 IMO。
我见过最好的教程是Ray Wenderlich's
另外，如果您是 Apple Developer 计划的成员，请查看去年 WWDC 上 Storyboards (iTunesU) 的会议，这太棒了。
另一个很棒的课程（也在 iTunesU 上）是最新的斯坦福 iOS 应用程序编程课程。
【讨论】：
故事板不仅有优点，也有缺点 - 只是因为您要求输入：
-以下不正确： - 如果您需要做 SB 不提供的事情，那么将 SB 与程序化创建的视图混合起来并不容易（不过，这是可能的）
经验法则似乎是：您希望项目变得越复杂，您最好不要选择 SB。
编辑： - SB 的另一个缺点：解决 XCode 有关 SB 的所有烦人错误。例如。由于一些不一致，不得不经常刷新 DerivedData 文件夹。有时情节提要文件或指向它们的链接会损坏。然后，您可能会乐于寻找问题。看看这个thread to get the idea
编辑 2（2013 年 3 月）：同时 Storyboard 和 Xcode 工作得更好，文档和最佳实践得到广泛传播。我认为大多数项目都可以推荐使用故事板，即使仍然存在一些故障。
编辑 3（2013 年 9 月）：现在使用新的 Xcode 5 格式与 SB 团队合作可能会变得更好，因为 merge SB-code much easier now. 似乎成为可能
另一个编辑：好吧，如果你有一个小时的时间，请坐下来，放松一下listen to these guys discussing this topic (Ray Wenderlich & Co)
编辑 2016.1：在担任 Storyboard 倡导者很长时间之后，在过去的几个月里我遇到了很多麻烦，所以我决定尽可能地放弃 Storyboard。这样做的原因是Apple添加了愚蠢的功能，但并不关心错误和缺陷。具有大量自动布局约束的性能非常糟糕（在设计时），并且容易出错的可能性变得很大。 示例：在 Xcode 中打开项目后，即使不太复杂的 Storyboard 也往往会进入“脏模式”（参见 git state）。 提示：作为初学者，您会喜欢 Storyboard，因为您可以快速制作原型并让程序运行而无需大量代码。当您进入中间状态时，您将向项目中添加更多 GUI 代码。现在你开始在代码和 SB 之间来回切换——事情开始变得更糟。迟早你会倾向于在代码中完成大部分 GUI 工作，因为结果比拥有多个来源更可预测。
【讨论】：
Nibs/.xib 文件和 Storyboard 都是 Interface Builder 文件，用于在 Xcode 中直观地为 iOS 和 Mac 应用程序创建用户界面（我将使用 iOS 术语来表示类，因为这个问题被标记为 iOS，但它也适用于Mac 编程）。
笔尖旨在与单个UIView 一起使用。它们还可以连接到UIViewController 子类，方法是将文件所有者的类设置为UIViewController 的任何子类并连接视图出口（使用Xcode 最右侧窗格中的连接检查器拖动以进行连接）。
故事板旨在包含 1 个或多个 UIViewController 的用户界面。您可以在单个故事板中构建整个用户界面，也可以将其分成更小的部分。
应始终使用故事板来支持 .xib 文件/Nib（用于视图控制器）。故事板具有更多功能，并且由 Apple 积极开发。
每个支持 Nib 的论点都依赖于它们单独使用的事实，而情节提要包含许多场景。您可以像使用 Nibs 一样轻松地为每个 UIViewController 使用一个故事板（请参阅下面的代码示例）。继续阅读以获得详细的解释和代码示例。
为什么 Storboards 优于 Nibs？
答案基本上归结为 Apple 鼓励使用 Storyboard 并在其中投入更多的开发精力。
UITableView (more info) 的原型和动态单元格反对故事板的基本论点是，将所有视图控制器放在一个位置会导致合并冲突、Xcode 缓慢、构建时间缓慢以及维护起来很麻烦。因此，一般建议是为每个 UIViewController 使用一个 Nib。
但是...您可以为每个 UIViewController 创建故事板。一种常见的做法（至少对我而言）是在类方法中隐藏所有 UIViewController 初始化（因为没有其他类需要知道控制器的 Nib/Storyboard 所在的文件的名称）。
让我们比较一下可能用于创建这种方法的相关代码 sn-ps。一行代码就是两者之间的全部区别。
故事板
+ (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 的所有常见论点；正如我之前提到的，大多数人支持单个文件，而不是作为 Nibs 而非 Storyboards 的论据
论点：拥有一个包含大量视图控制器的故事板将 如果您正在与多个团队合作，则会导致合并冲突 改变的人
响应：单个故事板不会导致比单个 Nib 更多的合并冲突
论点：非常复杂的应用程序在情节提要中包含大量场景，这导致巨大的情节提要需要永远加载并且由于其大小而几乎无法理解。
响应：这是一个很好的观点，但您可以轻松地将故事板分成更小的部分。 Storyboard References 看起来是一个很棒的功能，可用于将 Storyboard 链接在一起，但它们仅在 Xcode 7/iOS 9+ 中可用。此外，仍然不是选择单个 Nib 而非 Storyboard 的理由。
论点：为每个UIViewController 子类创建一个 Nib 可以让您重用代码，这样您就不必为情节提要中的每个场景设置所有约束和出口。
回应：同样，这不是选择单个 Nib 而非单个 Storyboard 的理由。
【讨论】：
几个月前的 LiDG 会议上有一个nice presentation about Storyboard。
就个人而言，我会说这是使用新应用的方式。存在一些差距，尤其是对于非常复杂的应用程序，但专业人士大多利大于弊。
【讨论】：
故事板的更多好处：
缺点是：
Storyboard 在 XCode 中包含大量视图控制器时渲染速度很慢
无法为情节提要中的一个视图控制器启用自动布局。
【讨论】：
请注意，如果您使用 Storyboard，您的应用无法向后兼容旧版操作系统安装。
【讨论】：
故事板基本上是一种使您作为开发人员的工作更轻松的设备。它被编译成一系列 nib 文件，因此性能几乎相当，但作为开发人员能够快速查看整个应用程序流程的概览非常棒。
我开始过渡到在新项目中使用故事板，前提是我可以说服客户接受 iOS 5 作为最低版本。这纯粹是因为我更喜欢这样做，而且完成相同任务所需的时间更少。
【讨论】：
您对自动布局的态度也可能会影响您是否要使用 Storyboard。使用 xib，您可以在每个 .xib 的基础上启用或禁用自动布局，允许在您的应用程序中进行混合，而 Storyboard 将您的选择应用于它们包含的所有视图。
【讨论】：
您在一秒钟内看到全局。有很多 NIB 文件，好吧，你看不到大局。 更容易维护您的程序。更容易理解其他程序......等等。
【讨论】：
优点：
1) 设计界面很不错
2) 您可以使用 StoryBoard Segues 以一种很酷的方式识别导航/模式关系。
3) 如果您的应用支持多种设备，这是组织不同视图的好方法。
4) 原型设计是另一个额外的优势。
5) 原型 UITableViewCell 可以节省时间，也可以减少代码量。
6) 您可以使用 StoryBoard 在一处查看应用程序的所有屏幕。
7) 可以轻松查看它们之间的关系
8) 如果您正在处理某人的代码，您可以更好地了解应用程序的流程。
9) 您可以通过应用情节提要中的 Retina 外形来设置 iPhone 4 和 iPhone 5 的用户界面，而无需反复运行应用程序。
10) 客户可以在开始开发之前看到应用程序的原型，这里的故事板对您有很大帮助。
缺点：
1) 仅适用于 iOS 5+
2) StoryBoardSegue 有点死板，你可以多次使用 prepareForSegue。
4) 和 IB 一样，对其他显示引擎和工具包不太友好。
4) 难以共享单个视图或一组视图的设计 - 您必须全部发送或不发送任何内容。
5) 对于情节提要，您将需要一个大屏幕，特别是在 iPad 的情况下。
6) 将视图从其他应用程序复制到情节提要时遇到困难。
7) 当多个开发人员使用 git 存储库处理同一个项目时，情节提要中的问题
从一些资源复制
【讨论】：
故事板的问题远多于好处。这是他们的问题列表，复制自iraycd：
Storyboards 在运行时失败，而不是在编译时失败：您的 segue 名称有错字或在您的 Storyboard 中连接错误？它会在运行时爆炸。您使用了故事板中不再存在的自定义 UIViewController 子类？它会在运行时爆炸。如果您在代码中执行此类操作，您将在编译时及早发现它们。 更新：我的新工具StoryboardLint主要解决了这个问题。
故事板很快就会变得混乱：随着项目的增长，您的故事板变得越来越难以导航。此外，如果多个视图控制器对多个其他视图控制器有多个 segue，您的故事板很快就会开始看起来像一碗意大利面，您会发现自己放大和缩小并到处滚动以找到您正在寻找的视图控制器并找出 segue 指向的位置。 更新：如this article by Pilky 和this article by Robert Brown 中所述，此问题主要可以通过将您的故事板拆分为多个故事板来解决。
故事板使团队工作更加困难：因为您的项目通常只有一个巨大的故事板文件，所以让多个开发人员定期更改该文件可能会让人头疼：更改需要合并并解决冲突。当发生冲突时，很难说如何解决它：Xcode 会生成故事板 XML 文件，但它的设计并不是真正考虑到人类必须阅读的目标，更不用说编辑它了。
故事板使代码审查变得困难或几乎不可能：同行代码审查对您的团队来说是一件很棒的事情。但是，当您对情节提要进行更改时，几乎不可能与其他开发人员一起查看这些更改。你所能得到的只是一个巨大的 XML 文件的差异。破译真正改变了什么以及这些改变是正确的还是破坏了某些东西真的很难。
Storyboards 阻碍代码重用：在我的 iOS 项目中，我通常会创建一个类，其中包含我在整个应用程序中使用的所有颜色、字体、边距和插图，以使其保持一致外观和感觉：如果我必须为整个应用程序调整这些值中的任何一个，这是一个单行更改。如果您在情节提要中设置此类值，则会复制它们，并且在您想要更改它们时需要找到每一个匹配项。您错过一个的机会很高，因为情节提要中没有搜索和替换。
Storyboards 让您每件事都做两次：您是否正在构建一个可在 iPad 和 iPhone 上运行的通用应用程序？当您使用故事板时，通常会有一个用于 iPad 版本的故事板和一个用于 iPhone 版本的故事板。保持两者同步需要您在两个地方进行每个 UI 或应用程序工作流更改。耶。 更新：在 iOS 8 和 Xcode 6 中，您可以为 iPhone 和 iPad 使用一个 Storyboard。
故事板需要不断的上下文切换：我发现自己在代码中的工作和导航速度比在故事板中快得多。当您的应用程序使用故事板时，您会不断切换上下文：“哦，我想点击这个表格视图单元以加载不同的视图控制器。我现在必须打开故事板，找到正确的视图控制器，创建一个新的 segue到另一个视图控制器（我也必须找到），给 segue 一个名字，记住这个名字（我不能在故事板中使用常量或变量），切换回代码，希望我不要打错名字我的 prepareForSegue 方法的那个 segue。我多么希望我可以在我所在的地方输入这 3 行代码！不，这不好玩。在代码和情节提要之间（以及键盘和鼠标之间）切换会很快过时并减慢您的速度。
故事板很难重构：重构代码时，您必须确保它仍然符合故事板的预期。当您在情节提要中移动内容时，您只会在运行时发现它是否仍然适用于您的代码。我觉得好像我必须让两个世界保持同步。我的拙见感觉很脆弱，不鼓励改变。
故事板不可搜索：当您使用故事板时，Xcode 中的项目范围搜索并不是真正的项目范围搜索。它们不包括在搜索中。因此，当您从代码中删除自定义类或重命名它时，您将不得不手动浏览情节提要或查看其原始 XML 以确保它与您的代码更改一致。不，先生，我不喜欢它。 更新：故事板可在 Xcode 6 中搜索。
故事板不太灵活：在代码中，您基本上可以做任何您想做的事情！使用情节提要，您仅限于在代码中可以做的事情的一个子集。尤其是当您想用动画和过渡做一些高级的事情时，您会发现自己“与故事板作斗争”以使其发挥作用。
Storyboards 不允许您更改特殊视图控制器的类型：您想将UITableViewController 更改为UICollectionViewController？还是变成普通的UIViewController？在情节提要中不可能。您必须删除旧视图控制器并创建一个新视图控制器并重新连接所有 segue。在代码中进行这样的更改要容易得多。
Storyboards 为您的项目增加了两个额外的责任：(1) Storyboard Editor 工具，用于生成 Storyboard XML，以及 (2) 解析 XML 并创建 UI 和控制器的运行时组件从它的对象。这两个部分都可能存在您无法修复的错误。
故事板不允许您将子视图添加到 UIImageView：谁知道为什么。
Storyboards 不允许您为单个 View(-Controller)s 启用自动布局：通过选中/取消选中 Storyboard 中的 Auto Layout 选项，更改将应用于所有故事板中的控制器。 （感谢 Sava Mazăre 的这一点！）
Storyboard 破坏向后兼容性的风险较高：Xcode 有时会更改 Storyboard 文件格式，并且不保证您可以打开自己创建的 Storyboard 文件几年甚至几个月后的今天。 （感谢thoughtadvances。See the original comment）
这是麦当劳：用史蒂夫乔布斯的话来说微软：It's McDonald's (video)！
【讨论】：
在 iOS 7 之前，情节提要很简洁，但不是必须的。他们引入了尽可能多的问题，因为他们解决了问题。 iOS 7 向 Storyboard 倾斜了平衡。
在 iOS 8 和 9 中，这不再是问题：使用故事板！
情节提要的主要缺点是您完全依赖于 XCode，最终您可能会花费数小时来解决 XCode 错误。但是 XCode 已经变得更好了，Storyboards 的优势现在太多了，不容忽视。表格视图单元格原型、大小类、自动布局支持等。
一些提示：
【讨论】：