在 iOS 编程中使用情节串连板而不是 xib 文件有什么好处？

使用情节串连图板和 xib 文件之间的 主要分歧是什么。

具体来说, 使用故事板的 优点或缺点是什么？

不幸的是，尽管我做了很多研究，但是我在故事板上找到的只是一些简单的教程，告诉你如何建立一个故事板，而不是具体的信息来解释它们是什么。

37717 次浏览
小开

几个月前在 LiDG 会议上有一份 关于故事板的演讲很精彩。

就我个人而言，我认为这是开发新应用程序的好方法。这里有一些差距，特别是对于非常复杂的应用程序，但是优点多于缺点。

小开
最佳答案

故事板是:

  • 所有场景的容器(视图控制器、导航控制器、 TabBar 控制器等)
  • 管理这些场景之间的连接和转换(这些场景称为 Segues)
  • 这是一种管理不同控制器之间通信的好方法
  • 情节串连图板可以让您全面了解您的应用程序的流程，这些流程是您永远无法从各个漂浮的提示符文件中获得的。
  • 当你有几个控制器，每个控制器都有自己的笔尖文件时，所有的“杂乱”就会减少。

我已经使用情节串连板一段时间了，唯一的缺点是你不能针对 iOS4或以下版本。情节串连板只能在运行 iOS5或更高版本的设备上使用。除此之外，好处很多，缺点是不存在的国际海事组织。

我看过的最好的教程是 Ray Wenderlich 的

此外，如果你是苹果开发者计划的成员，看看去年的 WWDC 会议上的故事板(iTunesU) ，这是令人敬畏的。

另一个伟大的(也在 iTunesU 上)是最新的斯坦福 iOS 应用程序编程课程。

小开

情节串连图板基本上是一个设备，使您的工作作为一个开发人员更容易。它被编译成一系列的 nib 文件，因此性能相当，但是作为一个开发人员，能够快速浏览整个应用程序流程是很棒的。

我开始在新项目中使用情节串连图板，前提是我能说服客户接受 iOS5作为最低版本。这纯粹是因为我喜欢这样做，而且完成同样的任务花费的时间更少。

小开

小心，如果你使用情节串连板你的应用程序不向后兼容旧的操作系统安装。

小开

故事板不仅有好的一面，也有坏的一面——只是因为你要求输入:

  • 在团队中使用 SBs 并不容易，因为只有一个参与者可以同时使用 SBs (因为它是一个文件)。

- 以下情况不正确: 如果你需要做的事情 SB 没有提供，这是不太容易得到 SB 与编程创建的视图(好吧，这是可能的)

经验法则似乎是: 你期望你的项目变得越复杂，你最好不要选择 SB。

编辑: SB 的另一个缺点是: 解决 XCode 关于 SB 的所有恼人的 bug。例如，由于一些不一致的地方，不得不频繁地刷新掉“派生数据”文件夹。有时故事板文件或指向它们的链接会损坏。然后你可能会有乐趣去寻找问题。看一下这个“ href =”https://stackoverflow. com/questions/7781483/ios5-storyboard-error-storyboard-are- ぃ  -on-ios-4-3-and-pre”> 帖子，你就会明白了

编辑2(2013年3月) : 与此同时，情节串连图板和 Xcode 工作得更好，文档和最佳实践得到了广泛传播。我认为大多数项目都可以推荐使用故事板，即使仍然有一些小故障。

编辑3(2013年9月) : 现在有了新的 Xcode 5格式，与 SB 一起工作的团队可能会变得更好，因为 现在合并 SB 代码更容易了。似乎变得可能了

另一个编辑: 好吧，如果你有一个小时的时间，坐下来，放松和 听这些家伙讨论这个话题(雷温德利希 & Co)

编辑2016.1: 作为一个故事板的拥护者，在过去的几个月里我遇到了很多麻烦，所以我决定尽可能的放弃故事板。原因是苹果增加了一些愚蠢的功能，但是并不关心缺陷和漏洞。具有大量自动布局约束的性能非常差(在设计时) ，而且容易出错。 例如: 即使不那么复杂的情节串连图板在用 Xcode 打开一个项目之后也会进入“脏模式”(参见 git state)。 提示: 作为一个初学者，你会喜欢情节串连图板，因为你可以快速地构建原型，并且不需要大量代码就可以让事情运行起来。当你输入一个居间态，你会在你的项目中添加更多的 GUI 代码。现在，您开始在代码和 SB 之间来回切换——事情开始变得更糟。迟早您会倾向于用代码来完成大部分 GUI 工作，因为结果比拥有多个源代码更容易预测。

小开

您对自动布局的态度也可能影响您是否想要使用情节串连图板。使用可以启用或禁用自动布局的 xibs 在每个。Xib 的基础上，允许在您的应用程序混合，而情节串连板应用您的选择，以所有的意见，他们包含。

小开

你可以在一秒钟内看到大图片，但是如果有很多 NIB 文件，你就看不到大图片了。 更容易维护您的程序。更容易理解其他程序... ... 以及其他程序。

小开

情节串连图板还有一些好处:

  • 情节串连板对表格视图有更好的支持，这就是您可以使用的 “动态”和“原型”单元。
  • 使用故事板实例化视图控制器更容易 InstantiateViewControllerWithIdentifer: ]
  • 情节串连板支持视图控制器容器，因此可以以图形方式布局子视图控制器。

缺点是:

  • 当情节串连图板包含大量视图控制器时，它们在 XCode 中呈现的速度很慢

  • 故事板中的一个视图控制器不能启用自动布局。

小开

优点:

1)设计界面很不错

2)你可以使用 StoryBoard Segues 以一种很酷的方式来识别导航/模态关系。

3)如果你的应用支持多种设备，这是一个组织不同视图的好方法。

4)原型是另一个额外的优势。

5) Prototype UITableViewCell 可以节省时间，也可以减少代码量。

6)你可以通过 StoryBoard 在一个地方看到应用程序的所有屏幕。

7)你可以很容易地看到他们之间的关系

8)如果你正在编写别人的代码，你可以更好地理解应用程序的流程。

9)你可以通过应用故事板中的视网膜形状因子来设置 iPhone 4和 iPhone 5的用户界面，而不需要一次又一次地运行应用程序。

10)客户可以在开始开发之前看到应用程序的原型，这里的情节串连图板可以帮助你很多。

缺点:

1)它只能在 iOS5 + 中使用

2)故事板接龙是一种死板的，你可以多次使用 preadreForSegue。

4)和 IB 一样，对其他显示引擎和工具包不太友好。

4)很难分享单个视图或视图集的设计——你必须发送全部或全部。

5)对于情节串连板，你需要一个大屏幕，特别是 iPad。

6)从其他应用程序复制视图到故事板的困难。

7)当多个开发人员通过使用 git 仓库在同一个项目上工作时，情节串连板中的问题

从一些资源中复制

小开

在 iOS7之前，故事板有点整洁，但不是必须的。他们解决了多少问题，就引进了多少问题。IOS7倾向于故事板。

对于 iOS8和 iOS9，这不再是一个问题: 使用故事板

情节串连板的主要缺点是，您完全依赖于 XCode，并且最终可能会花费数小时来处理 XCode 错误。但是 XCode 已经变得更好了，而且故事板的优势现在已经多得不容忽视了。表格视图单元格原型，大小类，自动布局支持等等。

小贴士:

  • 将每个 Storyboard 视为视图控制器的容器 不要把它想成是你们整个婚礼的宏伟布局 申请。
  • 你可能需要不止一个故事板
  • Segue 实际上只对最琐碎的用例有用——它们对此非常有用。但在现实世界的应用程序中，许多转换将从代码内部发生。 没关系。
  • 编写以编程方式实例化视图控制器的类别 所以你要做的就是让 Create () ，其中该方法处理所有 细节(拉故事板，拉视图控制器出故事板 等)。
小开

摘要

尼布斯/。Xib 文件和 Storyboard 都是 Interface Builder 文件，用于在 Xcode 中为 iOS 和 Mac 应用程序可视化地创建用户界面(我将使用 iOS 术语来描述类，因为这个问题被标记为 iOS，但它也适用于 Mac 编程)。

差异

笔尖应该与单个 UIView一起使用。它们也可以通过设置 File’s Owner 的类到 UIViewController的任何子类并连接视图出口(在 Xcode 的最右边窗格中使用 Connections spector 拖动连接)来连接到 UIViewController子类。

情节串连板旨在包含1个或多个 UIViewController的用户界面。您可以在一个故事板中构建您的整个用户界面，或者将其分成更小的部分。

好处

故事板应该总是用来支持。Xib 文件/Nibs (用于视图控制器)。故事板有更多的功能，并积极由苹果公司开发。

支持 Nibs 的每一个论点都依赖于这样一个事实，即它们是单独使用的，而故事板包含许多场景。您可以为每个 UIViewController使用一个故事板，就像使用 Nibs 一样容易(参见下面的代码示例)。请继续阅读详细的解释和代码示例。

细节

为什么冲浪板优于尼布斯？

答案基本上可以归结为苹果公司鼓励使用故事板，并投入更多的开发努力。

  1. 情节串连图板具有 Nibs 所缺乏的缩放能力。说真的，你根本不能在 Nibs 中放大，这对于在小型笔记本电脑上设计大屏幕来说很糟糕。
  2. Nibs 缺少以下关键功能:
  3. 您不需要设置 FilesOwner 类。

反对情节串连板的基本论点是，将所有视图控制器放在一个地方会导致合并冲突、缓慢的 Xcode、缓慢的构建时间以及维护时的普遍痛苦。因此，一般的建议是对每个 UIViewController使用 Nib。

但是... 您可以为每个 UIViewController创建故事板。一个常见的做法(至少对我来说)是在类方法中隐藏所有的 UIViewController 初始化(因为没有其他类需要知道控制器的 Nib/Storyboard 所在的文件的名称)。 让我们比较可能用来创建这种方法的相关代码片段。一行代码就是两者的完全区别。

目标 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 的所有常见参数; 正如我前面提到的，大多数支持单个文件，而不是作为 Nibs 优于情节串连图板的参数

  1. 团队合并

参数: 拥有一个包含大量视图控制器的情节串连板将 如果您所在的团队具有多个 人们做出改变

响应: 一个故事板不会导致比一个 Nib 更多的合并冲突

  1. 复杂性

辩君: 非常复杂的应用程序在故事板中有很多场景，这导致了一个巨大的故事板，需要永远加载，几乎不可理解，因为它的大小。

回应: 这是一个很好的观点，但是你可以很容易地把故事板分成更小的部分。故事板参考资料看起来像是一个很棒的特性，可以用来将故事板链接在一起，但是它们只能在 Xcode 7/iOS 9 + 中使用。此外，仍然没有理由选择个别的 Nibs 而不是情节串连图板。

  1. 可重用性

论据: 为每个 UIViewController子类创建一个 Nib 可以让您重用代码，这样您就不必为故事板中的每个场景设置所有的约束和出口。

回应: 再次强调，没有理由选择单独的 Nibs 而不是单独的情节串连板。

小开

情节串连图板的问题比好处多得多。下面是它们的问题清单，复制自 Iraycd:

  • 故事板在运行时失败，而不是在编译时 : 您在接续名称中有一个输入错误或者在您的故事板中连接错误？它会在运行时爆炸。你使用一个自定义的 UIViewController 子类，这个子类在你的故事板中不再存在了吗？它会在运行时爆炸。如果在代码中执行这些操作，您将在编译期间及早捕获它们。我的新工具 StoryboardLint主要解决了这个问题。

  • 故事板变得混乱快 : 随着你的项目的增长，你的故事板变得越来越难以导航。此外，如果多个视图控制器与多个其他视图控制器之间有多个接口，那么你的故事板很快就会变得像一碗意大利面条，你会发现自己在放大、缩小、滚动各个地方，以找到你正在寻找的视图控制器，并找出哪个接口指向哪里。< em > 更新 : 如 皮尔基的这篇文章和 本文作者: 罗伯特 · 布朗所述，这个问题通常可以通过将故事板分割成多个故事板来解决。

  • 情节串连板使团队工作更加困难 : 因为你通常只有一个巨大的项目情节串连板文件，让多个开发人员定期对该文件进行更改可能是一件令人头疼的事情: 需要合并更改并解决冲突。当冲突发生时，很难说清楚如何解决它: Xcode 生成故事板 XML 文件，而且在设计时并没有考虑到人类必须阅读的目标，更不用说编辑它了。

  • 情节串连图板使得代码审查变得困难或者几乎不可能 : 对等代码审查是你的团队的一件很棒的事情。但是，当您对故事板进行更改时，几乎不可能与其他开发人员一起检查这些更改。您所能找到的只是一个巨大的 XML 文件的差异。破译真正改变了什么，以及这些改变是否正确，或者它们是否破坏了什么，真的很难。

  • 情节串连图板妨碍代码重用 : 在我的 iOS 项目中，我通常创建一个包含所有颜色、字体、边距和插入的类，我在整个应用程序中使用这些来赋予它一致的外观和感觉: 如果我必须为整个应用程序调整这些值中的任何一个，这只是一行改变。如果您在故事板中设置了这样的值，那么您将复制它们，并且需要在您想要更改它们的时候找到每一个单独的事件。错过一个的几率很高，因为故事板中没有搜索和替换。

  • 情节串连板让你做任何事情两次 : 你是否正在构建一个同时在 iPad 和 iPhone 上运行的通用应用程序？当你使用情节串连板时，你通常会有一个 iPad 版本的情节串连板和一个 iPhone 版本的情节串连板。保持两者同步需要你在两个地方做每一个 UI 或应用程序工作流更改。太好了。< em > 更新 : 在 iOS8和 Xcode 6中，你可以为 iPhone 和 iPad 使用一个单独的故事板。

  • 情节串连图板需要不断的上下文切换 : 我发现自己在代码中工作和导航的速度比在情节串连图板中快得多。当你的应用程序使用情节串连图板时，你不断地切换上下文: “哦，我想点击这个表格视图单元格来加载一个不同的视图控制器。现在我必须打开情节串连板，找到正确的视图控制器，创建一个到其他视图控制器的新接口(我也必须找到它) ，给接口一个名称，记住这个名称(我不能在情节串连板中使用常量或变量) ，切换回代码，并希望我不要把接口的名称错误地输入到我的 prepareForSegue 方法中。我多么希望我可以在这里输入这3行代码!”不，一点都不好玩。在代码和故事板之间切换(以及在键盘和鼠标之间切换)很快就过时了，会减慢你的速度。

  • 故事板很难重构 : 当您重构代码时，您必须确保它仍然符合故事板的期望。当你在情节串连图板中移动东西时，你只有在运行时才能发现它是否仍然适用于你的代码。我觉得我必须让两个世界保持同步。在我看来，它很脆弱，不利于改变。

  • 情节串连图板不可搜索 : 当你使用情节串连图板时，在 Xcode 的项目范围内的搜索并不是真正的项目范围内的搜索。他们不包括在搜索中。因此，当您从代码中删除一个自定义类或者重命名它时，您必须手动浏览故事板或者查看它的原始 XML，以确保它与您的代码更改保持一致。不，先生，我不喜欢。< em > 更新 : 情节串连图板在 Xcode 6中是可搜索的。

  • 情节串连图板没有那么灵活 : 在代码中，你基本上可以做任何你想做的事情！使用情节串连图板，您只能在代码中完成一部分工作。特别是当你想用动画和过渡做一些高级的事情的时候，你会发现自己在“与故事板作斗争”来让它工作。

  • 情节串连图板不允许您更改特殊视图控制器的类型 : 您想将 UITableViewController更改为 UICollectionViewController吗？或者变成一个简单的 UIViewController？在故事板里是不可能的。您必须删除旧的视图控制器并创建一个新的控制器，然后重新连接所有的接口。在代码中进行这样的更改要容易得多。

  • 情节串连图板给你的项目 增加了两个额外的责任: (1)生成情节串连图板 XML 的情节串连图板编辑器工具; (2)解析 XML 并从中创建 UI 和控制器对象的运行时组件。这两个部分都可能存在无法修复的 bug。

  • 情节串连图板不允许你添加一个子视图到 UIImageView : 谁知道为什么。

  • 情节串连图板不允许你为单独的视图(- 控制器)启用自动布局。通过选中/取消选中情节串连图板中的自动布局选项，更改将应用于情节串连图板中的所有控制器。(感谢 Sava Maz!)

  • 故事板具有更高的破坏向后兼容性的风险 : Xcode 有时会改变故事板文件格式，并且不能保证在几年甚至几个月后你能够打开今天创建的故事板文件。(感谢思想在这一点上的进步。请参阅原始评论)

  • 麦当劳 : 用史蒂夫 · 乔布斯对微软的话说: 这是麦当劳(视频)！


提交答案