何时使用Storyboard以及何时使用XIB

Question

是否有关于何时在iOS项目中使用故事板以及何时使用XIB的指南？每个人的优缺点是什么,他们各自适合什么情况？

当你有动态UI元素推动视图控制器(如地图引脚)时,我可以告诉它使用故事板segues并不是那么干净.

Answer 1

2016年1月12日更新:这是2016年,我仍然更喜欢在代码中而不是在故事板中布置我的UI.话虽如此,故事板已经走过了漫长的道路.我已经删除了这篇帖子中的所有要点,这些点在2016年根本不再适用.

2015年4月24日更新:有趣的是,Apple在他们最近开源的ResearchKit中甚至没有像Peter Steinberger所注意到的那样使用Storyboard (在"Interface Builder"小标题下).

2014年10月10日更新:正如预期的那样,Apple不断改进Storyboard和Xcode.适用于iOS 7及更低版本的一些要点不再适用于iOS 8(现在标记为此类).因此,虽然故事板本质上仍然有瑕疵,我修改从我建议不要使用,以有选择地使用它是有道理的.

即使现在iOS 9已经出局,我也会建议 反对在决定是否使用Storyboard时要小心.这是我的理由:

• 故事板在运行时失败,而不是在编译时失败:你有一个segue名称的拼写错误或在故事板中连接错误？它会在运行时爆炸.您使用故事板中不再存在的自定义UIViewController子类？它会在运行时爆炸.如果你在代码中做这些事情,你会在编译期间尽早发现它们.更新:我的新工具StoryboardLint主要解决了这个问题.

• 故事板快速混乱:随着项目的增长,故事板越来越难以导航.此外,如果多个视图控制器有多个segll到多个其他视图控制器,你的故事板很快就会开始看起来像一碗意大利面,你会发现自己放大和缩小并滚动到处寻找你正在寻找的视图控制器为了找出什么segue点在哪里.更新:这个问题可以主要通过区分你的故事板为多个故事板来解决,如在本文中通过Pilky和本文由罗伯特·布朗.

• 故事板使在一个团队努力工作:因为你通常只为您的项目一个巨大的故事板文件,有多个开发人员定期进行更改一个文件可有头痛:变更需要合并和冲突解决.当发生冲突时,很难说出如何解决它:Xcode生成故事板XML文件,并没有真正设计的目标是人类必须阅读,更不用说编辑它了.

• 故事板使代码审查变得困难或几乎不可能:同行代码审查对您的团队来说是一件好事.但是,当您对故事板进行更改时,几乎不可能使用其他开发人员查看这些更改.所有你能搞定的是一个巨大的XML文件的差异.解读真正改变的东西,如果这些改变是正确的,或者如果他们破坏了某些东西,那真的很难.

• 故事板阻碍了代码重用:在我的iOS项目中,我通常会创建一个类,其中包含我在整个应用程序中使用的所有颜色和字体,边距和插图,以使其具有一致的外观和感觉:如果必须的话,这是一个单行更改调整整个应用程序的任何值.如果在故事板中设置了这些值,则复制它们,并且需要在要更改它们时查找每个事件.你很想念一个机会很高,因为在故事板里没有搜索和替换.

• 故事板需要不断的上下文切换:我发现自己在代码中的工作和导航速度比在故事板中快得多.当您的应用程序使用故事板时,您不断切换上下文:"哦,我想点击此表视图单元格来加载不同的视图控制器.我现在必须打开故事板,找到正确的视图控制器,创建一个新的segue到另一个视图控制器(我也必须找到),给segue一个名字,记住那个名字(我不能在故事板中使用常量或变量),切换回代码并希望我不输入错误的名字这对我的prepareForSegue方法来说是个塞浦路.我希望我能在这里输入那3行代码!" 不,这不好玩.在代码和故事板之间(以及键盘和鼠标之间)的切换会变得很快,并且会降低速度.

• 故事板难以重构:当您重构代码时,您必须确保它仍然与故事板所期望的相匹配.当您在故事板中移动内容时,只会在运行时发现它是否仍然适用于您的代码.我觉得好像必须保持两个世界同步.它感觉很脆弱,并且在我的拙见中不鼓励改变.

• 故事板不够灵活:在代码中,你基本上可以做任何你想做的事情!使用故事板,您只能使用代码中可以执行的操作的子集.特别是当你想用动画和过渡做一些高级的事情时,你会发现自己"在战斗故事板上"才能让它发挥作用.

• 故事板不允许您更改特殊视图控制器的类型:您想要将其更改UITableViewController为UICollectionViewController？还是变成平原UIViewController？故事板中不可能.您必须删除旧视图控制器并创建一个新视图控制器并重新连接所有segues.在代码中进行这样的更改要容易得多.

• 故事板为您的项目增加了两个额外的责任:(1)生成故事板XML的Storyboard Editor工具和(2)解析XML并从中创建UI和控制器对象的运行时组件.这两个部分都可能存在无法修复的错误.

• 故事板不允许您将子视图添加到UIImageView:谁知道原因.

• 故事板不允许您为单个View(-Controller)启用自动布局:通过选中/取消选中Storyboard中的Auto Layout选项,更改将应用​​于Storyboard中的所有控制器.(感谢SavaMazăre这一点!)

• 故事板具有更高的破坏向后兼容性的风险:Xcode有时会更改Storyboard文件格式,并且无法以任何方式保证您可以打开今天几年甚至几个月后创建的Storyboard文件.(感谢关于这一点的思想进展.请参阅原始评论)

• 故事板可以使您的代码更复杂:init例如,在代码中创建视图控制器时,您可以创建自定义方法initWithCustomer:.这样,您可以使customer视图控制器的内部不可变,并确保在没有customer对象的情况下无法创建此视图控制器.使用Storyboard时无法做到这一点.您将不得不等待prepareForSegue:sender:调用该方法,然后您必须customer在视图控制器上设置该属性,这意味着您必须使此属性可变,并且您必须允许在没有customer对象的情况下创建视图控制器.根据我的经验,这可能会使您的代码变得非常复杂,并且使您更难以推断应用程序的流程.2016年9月9日更新:Chris Dzombak写了一篇一篇关于这个问题精彩文章.

• 这是麦当劳:用史蒂夫乔布斯关于微软的话来说:这是麦当劳(视频)!

这些是我为什么不喜欢使用故事板的原因.其中一些原因也适用于XIB.在我所参与的基于故事板的项目中,他们花费的时间远远超过他们保存的时间,而且他们使事情变得更复杂而不是更容易.

当我在代码中创建我的UI和应用程序流时,我更能控制正在发生的事情,它更容易调试,更容易在早期发现错误,更容易向其他开发人员解释我的更改更容易支持iPhone和iPad.

但是,我确实同意在代码中布置所有UI可能不是每个项目都是一个通用的解决方案.如果您的iPad UI在某些地方与iPhone UI有很大不同,那么为这些区域创建XIB可能是有意义的.

上面列出的许多问题可以由Apple修复,我希望这就是他们将要做的.

只是我的两分钱.

更新:在Xcode 5中,Apple取消了创建没有Storyboard的项目的选项.我写了一个小脚本,将Xcode 4的模板(带有Storyboard-opt-out选项)移植到Xcode 5:https://github.com/jfahrenkrug/Xcode4templates

Answer 2

我已广泛使用XIB并使用Storyboard完成了两个项目.我的经验是:

• 故事板非常适合具有少量到中等数量的屏幕以及视图之间相对简单的导航的应用程序.
• 如果你有很多视图和很多交叉导航,那么Storyboard视图会让人感到困惑和太多工作以保持干净.
• 对于具有多个开发人员的大型项目,我不会使用Storyboard,因为您的UI只有一个文件,并且不能轻松并行工作.
• 大型应用程序分成多个故事板文件可能是值得的,但我还没有尝试过.这个答案显示了如何在故事板之间进行分段.
• 你仍然需要XIB:在我的两个Storyboard项目中,我不得不将XIB用于自定义表格单元格.

我认为Storyboard是朝着UI实施的正确方向迈出的一步,并希望Apple能够在未来的iOS版本中扩展它们.他们需要解决"单个文件"问题,否则它们对大型项目不具吸引力.

如果我启动一个小尺寸的应用程序并且只能兼容iOS5,我会使用Storyboard.对于所有其他情况,我坚持使用XIB.

Answer 3

创建故事板是为了帮助开发人员可视化他们的应用程序和应用程序流.它有点像一堆xib但在一个文件中.

有一个与此类似的问题.xib文件和.storyboard之间有什么区别？.

您还可以通过代码创建自定义转换,代码将根据需要动态更改,就像使用.xibs一样.

优点:

• 如果有任何代码,您可以模拟应用程序的流程而无需编写太多内容.
• 更容易看到屏幕和应用程序流之间的转换.
• 如果需要,也可以使用.xibs与故事板.

缺点:

• 仅适用于iOS 5+.不适用于iOS4.
• 如果您有一个非常密集的应用程序,可能会很容易混乱.

在使用其中一个时,确实没有对错,这只是一个偏好问题以及您想要使用的iOS版本.

Answer 4

我将简单说明为什么要使用故事板的4个简单原因,特别是在生产环境中,您必须在产品所有者,产品经理,UX设计师等团队中工作.

1. Apple在使用Storyboard方面做得非常好.他们鼓励你和他们一起工作.这意味着他们不会通过更新破坏您现有的项目,他们将确保故事板是更新的XCode/iOS版本的未来证明.
2. 即使在创建阶段,产品所有者和管理者在更短的时间内也能看到更明显的结果.您甚至可以将故事板本身用作屏幕流程图并在会议中进行讨论.
3. 即使在应用程序完成后(通常在其生命周期开始的地方) - 将来应用更小的调整也会更快更容易.这些可以很好地同时改变您的布局的多个方面,您可能希望以所见即所得的方式看到它们.另一种方法是手写代码中的UI更改,并在IDE和模拟器之间来回切换以测试它,每次等待编译和构建.
4. 可以教非开发人员在故事板中设置布局,并为开发人员创建必要的钩子(IBOutlets和IBActions).这是一个非常大的优点,因为它让开发人员专注于逻辑,UX设计师以可视方式应用他们的更改,而不必编写任何代码.

我不会写任何CONS,因为约翰内斯已经在他的答案中列出了所有可行的.而且大多数都绝对不可行,尤其是XCode6的主要改进.

Answer 5

我不认为你的问题有正确的答案，这只是个人经历和你觉得更舒服的问题。

在我看来，故事板是一件很棒的事情。确实，很难找出您的应用程序在运行时异常崩溃的原因，但经过一段时间和经验后，您会意识到它总是与某些 IBOutlet 丢失有关，并且您可以轻松修复它。

唯一真正的问题是在使用故事板进行版本控制的团队中工作，在开发的早期阶段可能会很混乱。但是在第一阶段之后，完全改变故事板的 UI 更新是非常罕见的，并且在大多数情况下，您最终会在 xml 的最后部分发生冲突，这些部分是 segue 引用，通常在您重新打开故事板时自动修复自己. 在我们的团队工作中，我们更喜欢处理这个问题，而不是使用大量视图代码的繁重视图控制器。

我已经阅读了很多关于自动布局的评论。使用 XCode5，它得到了真正的改进，甚至对于自动旋转布局也非常好。在某些情况下，您必须在代码中执行某些操作，但是您可以简单地输出需要编辑的约束，然后在代码中执行您需要的操作。甚至动画他们。

我还认为，大多数不喜欢故事板的人并没有完全理解自定义手动转场的力量，在那里您可以完全自定义（在单个文件中）从一种方式过渡到另一种方式的方式以及（使用一些技巧）甚至通过更新它的视图内容而不是完全重新加载整个东西来重用以前加载的视图控制器。最后你真的可以做和代码一样的事情，但我认为你对故事板的关注点有更好的分离，但我同意他们在很多方面缺乏功能（字体、图像作为颜色背景、ecc... ）。