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

When to use Storyboard and when to use XIBs

提问by Affian

Are there any guidelines on when to use storyboards in an iOS project and when to use XIBs? what are the pros and cons of each and what situations do they each suit?

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

Near as I can tell it's not that clean to use storyboard segues when you have view controllers being pushed by dynamic UI elements (Like map pins).

据我所知，当您的视图控制器由动态 UI 元素（如地图图钉）推送时，使用故事板 segue 并不是那么干净。

采纳答案by henning77

I have used XIBs extensively and completed two projects using Storyboards. My learnings are:

我广泛使用了 XIB，并使用 Storyboards 完成了两个项目。我的学习是：

• Storyboards are nice for apps with a small to medium number of screens and relatively straightforward navigation between views.
• If you have lots of views and lots of cross-navigation between them the Storyboard view gets confusing and too much work to keep clean.
• For a large project with multiple developers I would not use Storyboards because you have a single file for your UI and cannot easily work in parallel.
• It might be worth for large apps to split up into multiple storyboard files but I have not tried that. This answershows how to do segues between storyboards.
• You still need XIBs: In both of my Storyboard projects I had to use XIBs for custom table cells.

• 故事板非常适合具有中小屏幕数量和视图之间相对简单导航的应用程序。
• 如果你有很多视图并且它们之间有很多交叉导航，那么故事板视图就会变得混乱，并且需要做太多的工作来保持干净。
• 对于有多个开发人员的大型项目，我不会使用 Storyboards，因为您的 UI 有一个文件，并且无法轻松并行工作。
• 将大型应用程序拆分为多个故事板文件可能是值得的，但我还没有尝试过。这个答案显示了如何在故事板之间进行转场。
• 您仍然需要 XIB：在我的两个 Storyboard 项目中，我都必须将 XIB 用于自定义表格单元格。

I think Storyboards are a step in the right direction for UI implementation and hope Apple will extend them in future iOS versions. They need to resolve the "single file" issue though, otherwise they won't be attractive for larger projects.

我认为 Storyboards 是 UI 实现朝着正确方向迈出的一步，希望 Apple 在未来的 iOS 版本中扩展它们。不过，它们需要解决“单个文件”问题，否则它们对大型项目没有吸引力。

If I start a small size app and can afford iOS5 only compatibility, I would use Storyboards. For all other cases I stick to XIBs.

如果我开始一个小尺寸的应用程序并且只能兼容 iOS5，我会使用 Storyboards。对于所有其他情况，我坚持使用 XIB。

回答by Johannes Fahrenkrug

Update 1/12/2016: It's 2016 and I still prefer laying out my UIs in code and not in Storyboards. That being said, Storyboards have come a long way. I have removed all the points from this post that simply do not apply anymore in 2016.

2016 年 1 月 12 日更新：现在是 2016 年，我仍然更喜欢在代码中而不是在故事板中布置我的 UI。话虽如此，故事板已经走过了漫长的道路。我已经从这篇文章中删除了所有在 2016 年不再适用的要点。

Update 4/24/2015: Interestingly Apple doesn't even use Storyboards in their recently open-sourced ResearchKit as Peter Steinberger has noticed(under the subheading "Interface Builder").

2015 年 4 月 24 日更新：有趣的是，正如Peter Steinberger 所注意到的（在副标题“Interface Builder”下），Apple 甚至没有在他们最近开源的 ResearchKit 中使用 Storyboard 。

Update 6/10/2014: As expected, Apple keeps improving Storyboards and Xcode. Some of the points that applied to iOS 7 and below don't apply to iOS 8 anymore (and are now marked as such). So while Storyboards inherently still have flaws, I revise my advice from don't useto selectively use where it makes sense.

2014 年 6 月 10日更新：正如预期的那样，Apple 不断改进 Storyboards 和 Xcode。一些适用于 iOS 7 及更低版本的要点不再适用于 iOS 8（现在被标记为这样）。因此，虽然 Storyboard 本质上仍然存在缺陷，但我修改了我的建议，从不要使用到有选择地使用有意义的地方。

Even now that iOS 9 is out, I would advise againstto use caution when deciding whether to use Storyboards. Here are my reasons:

即使现在 iOS 9 出来了，我还是建议 反对在决定是否使用 Storyboard 时要谨慎。以下是我的理由：

• Storyboards fail at runtime, not at compile time: You have a typo in a segue name or connected it wrong in your storyboard? It will blow up at runtime. You use a custom UIViewController subclass that doesn't exist anymore in your storyboard? It will blow up at runtime. If you do such things in code, you will catch them early on, during compile time. Update: My new tool StoryboardLintmostly solves this problem.

• Storyboards get confusing fast: As your project grows, your storyboard gets increasingly more difficult to navigate. Also, if multiple view controllers have multiple segues to multiple other view controllers, your storyboard quickly starts to look like a bowl of spaghetti and you'll find yourself zooming in and out and scrolling all over the place to find the view controller you are looking for and to find out what segue points where. Update: This problem can mostly be solved by splitting your Storyboard up into multiple Storyboards, as described in this article by Pilkyand this article by Robert Brown.

• Storyboards make working in a team harder: Because you usually only have one huge storyboard file for your project, having multiple developers regularly making changes to that one file can be a headache: Changes need to be merged and conflicts resolved. When a conflict occurs, it is hard to tell how to resolve it: Xcode generates the storyboard XML file and it was not really designed with the goal in mind that a human would have to read, let alone edit it.

• Storyboards make code reviews hard or nearly impossible: Peer code reviews are a great thing to do on your team. However, when you make changes to a storyboard, it is almost impossible to review these changes with a different developer. All you can pull up is a diff of a huge XML file. Deciphering what really changed and if those changes are correct or if they broke something is really hard.

• Storyboards hinder code reuse: In my iOS projects, I usually create a class that contains all the colors and fonts and margins and insets that I use throughout the app to give it a consistent look and feel: It's a one line change if I have to adjust any of those values for the whole app. If you set such values in the storyboard, you duplicate them and will need to find every single occurrence when you want to change them. Chances are high that you miss one, because there's no search and replace in storyboards.

• Storyboards require constant context switches: I find myself working and navigating much faster in code than in storyboards. When your app uses storyboards, you constantly switch your context: "Oh, I want a tap on this table view cell to load a different view controller. I now have to open up the storyboard, find the right view controller, create a new segue to the other view controller (that I also have to find), give the segue a name, remember that name (I can't use constants or variables in storyboards), switch back to code and hope I don't mistype the name of that segue for my prepareForSegue method. How I wish I could just type those 3 lines of code right here where I am!" No, it's not fun. Switching between code and storyboard (and between keyboard and mouse) gets old fast and slows you down.

• Storyboards are hard to refactor: When you refactor your code, you have to make sure it still matches what your storyboard expects. When you move things around in your storyboard, you will only find out at runtime if it still works with your code. It feels to me as if I have to keep two worlds in sync. It feels brittle and discourages change in my humble opinion.

• Storyboards are less flexible: In code, you can basically do anything you want! With storyboards you are limited to a subset of what you can do in code. Especially when you want to do some advanced things with animations and transitions you will find yourself "fighting the storyboard" to get it to work.

• Storyboards don't let you change the type of special view controllers: You want to change a UITableViewControllerinto a UICollectionViewController? Or into a plain UIViewController? Not possible in a Storyboard. You have to delete the old view controller and create a new one and re-connect all the segues. It's much easier to do such a change in code.

• Storyboards add two extra liabilities to your project: (1) The Storyboard Editor tool that generates the storyboard XML and (2) the runtime component that parses the XML and creates UI and controller objects from it. Both parts can have bugs that you can't fix.

• Storyboards don't allow you to add a subview to a UIImageView: Who knows why.

• Storyboards don't allow you to enable Auto Layout for individual View(-Controller)s: By checking/unchecking the Auto Layout option in a Storyboard, the change is applied to ALL controllers in the Storyboard. (Thanks to Sava Maz?re for this point!)

• Storyboards have a higher risk of breaking backwards compatibility: Xcode sometimes changes the Storyboard file format and doesn't guarantee in any way that you will be able to open Storyboard files that you create today a few years or even months from now. (Thanks to thoughtadvances for this point. See the original comment)

• Storyboards can make your code more complex: When you create your view controllers in code, you can create custom initmethods, for example initWithCustomer:. That way, you can make the customerinside of your view controller immutable and make sure that this view controller cannot be created without a customerobject. This is not possible when using Storyboards. You will have to wait for the prepareForSegue:sender:method to be called and then you will have to set the customerproperty on your view controller, which means you have to make this property mutable and you will have to allow for the view controller to be created without a customerobject. In my experience this can greatly complicate your code and makes it harder to reason about the flow of your app. Update 9/9/16: Chris Dzombak wrote a great article about this problem.

• It's McDonald's: To say it in Steve Jobs' words about Microsoft: It's McDonald's (video)!

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

• 故事板很快就会变得混乱：随着项目的发展，故事板变得越来越难以导航。此外，如果多个视图控制器与多个其他视图控制器有多个转场，您的故事板很快就会开始看起来像一碗意大利面条，您会发现自己放大和缩小并在整个地方滚动以找到您正在寻找的视图控制器for 并找出 segue 指向何处。更新：这个问题可以主要通过分割你的故事板最多可以解决成多个故事板，如在本文中通过Pilky和本文由罗伯特·布朗。

• 故事板使团队工作变得更加困难：因为您的项目通常只有一个巨大的故事板文件，让多个开发人员定期更改该文件可能会让人头疼：需要合并更改并解决冲突。当发生冲突时，很难说如何解决它：Xcode 生成故事板 XML 文件，它的设计目的并不是让人类必须阅读，更不用说编辑它了。

• 故事板使代码变得困难或几乎不可能：同行代码对您的团队来说是一件很棒的事情。但是，当您对故事板进行更改时，几乎不可能与不同的开发人员一起查看这些更改。您所能找到的只是一个巨大的 XML 文件的差异。破译真正发生了什么变化，以及这些变化是否正确，或者它们是否破坏了某些东西真的很难。

• 故事板阻碍了代码重用：在我的 iOS 项目中，我通常会创建一个类，其中包含我在整个应用程序中使用的所有颜色和字体以及边距和插图，以使其具有一致的外观和感觉：如果必须，这是一行更改调整整个应用程序的任何这些值。如果您在情节提要中设置了此类值，则您将复制它们，并且在您想要更改它们时需要找到每个出现的地方。您错过一个的可能性很高，因为故事板中没有搜索和替换。

• 故事板需要不断的上下文切换：我发现自己在代码中的工作和导航速度比在故事板中快得多。当你的应用程序使用故事板时，你不断地切换你的上下文：“哦，我想点击这个表格视图单元来加载一个不同的视图控制器。我现在必须打开故事板，找到正确的视图控制器，创建一个新的转场到另一个视图控制器（我也必须找到），给 segue 起一个名字，记住这个名字（我不能在故事板中使用常量或变量），切换回代码，希望我不要打错名字“我的prepareForSegue方法的segue。我多么希望我能在这里输入这3行代码！” 不，这不好玩。在代码和故事板之间（以及在键盘和鼠标之间）切换会很快变老并减慢你的速度。

• 故事板很难重构：当你重构你的代码时，你必须确保它仍然符合你的故事板的期望。当您在故事板中移动内容时，您只会在运行时发现它是否仍然适用于您的代码。我觉得好像我必须保持两个世界同步。以我的拙见，它感觉很脆弱，不鼓励改变。

• 故事板不太灵活：在代码中，您基本上可以做任何您想做的事！使用故事板，您仅限于您可以在代码中执行的操作的一个子集。尤其是当你想用动画和过渡做一些高级的事情时，你会发现自己在“与故事板作斗争”以使其工作。

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

• 情节提要为您的项目增加了两个额外的负担：(1) 生成情节提要 XML 的情节提要编辑器工具和 (2) 解析 XML 并从中创建 UI 和控制器对象的运行时组件。这两个部分都可能存在您无法修复的错误。

• 故事板不允许您向 a 添加子视图UIImageView：谁知道为什么。

• 情节提要不允许您为单个视图（-控制器）启用自动布局：通过选中/取消选中情节提要中的自动布局选项，更改将应用​​于情节提要中的所有控制器。（感谢 Sava Maz?re 在这一点上！）

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

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

• 这是麦当劳：用史蒂夫乔布斯关于微软的话来说：这是麦当劳（视频）！

These are my reasons for why I really don't like working with storyboards. Some of these reasons also apply to XIBs. On the storyboard-based projects that I've worked on, they have cost me much more time than they have saved and they made things more complicated instead of easier.

这些就是我为什么真的不喜欢使用故事板的原因。其中一些原因也适用于 XIB。在我从事的基于故事板的项目中，它们花费我的时间比节省的时间多得多，而且它们使事情变得更加复杂而不是更容易。

When I create my UI and application flow in code, I am much more in control of what is going on, it is easier to debug, it is easier to spot mistakes early on, it is easier to explain my changes to other developers and it is easier to support iPhone and iPad.

当我在代码中创建 UI 和应用程序流时，我可以更好地控制正在发生的事情，更容易调试，更容易及早发现错误，更容易向其他开发人员解释我的更改，并且更容易支持 iPhone 和 iPad。

However, I do agree that laying out all of your UIin code might not be a one-size-fits-all solution for every project. If your iPad UI differs greatly from your iPhone UI in certain places, it might make sense to create a XIB for just those areas.

但是，我同意在代码中布置所有 UI可能不是适用于每个项目的一刀切解决方案。如果你的 iPad UI 在某些地方与你的 iPhone UI 有很大不同，那么为这些区域创建一个 XIB 可能是有意义的。

A lot of the problems outlined above could be fixed by Apple and I hope that that's what they will do.

上面列出的许多问题都可以由 Apple 解决，我希望他们会这样做。

Just my two cents.

只有我的两分钱。

Update: In Xcode 5, Apple took away the option to create a project without a Storyboard. I've written a small script that ports Xcode 4's templates (with Storyboard-opt-out option) to Xcode 5: https://github.com/jfahrenkrug/Xcode4templates

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

回答by Bot

Storyboards were created to help developers visualize their application and the flow of the application. It is alot like having a bunch of xib but in a single file.

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

There is a question similar to this located What is the difference between a .xib file and a .storyboard?.

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

You can also create custom transitions via code that will change dynamically if needed, much like you can with .xibs.

您还可以通过代码创建自定义转换，如果需要，这些代码将动态更改，就像使用 .xibs 一样。

PROS:

优点：

• You can mock up flow of an application without writing much, if any code.
• Much easier to see your transitions between screens and your application flow.
• Can also use .xibs if needed with storyboards.

• 您可以模拟应用程序的流程，而无需编写太多代码（如果有的话）。
• 更容易查看屏幕和应用程序流之间的转换。
• 如果需要故事板，也可以使用 .xibs。

CONS:

缺点：

• Only works with iOS 5+. Does not work with iOS4.
• Can get cluttered easily if you have a very view intensive application.

• 仅适用于 iOS 5+。不适用于 iOS4。
• 如果您有一个视图密集型应用程序，则很容易变得杂乱无章。

There really isn't a right / wrong when to use one or the other, it is just a matter of preference and what iOS versions you are wanting to use.

何时使用一种或另一种确实没有对错之分，这只是偏好和您想要使用的 iOS 版本的问题。

回答by thgc

I will just state 4 simple reasonswhy you shoulduse storyboards, especially in a productive environment where you have to work in a team of product owners, product managers, UX designers, etc.

我将说明为什么你应该使用故事板的4 个简单原因，尤其是在一个生产环境中，你必须在一个由产品所有者、产品经理、UX 设计师等组成的团队中工作。

1. Apple has GREATLY improved working with Storyboards.And they encourage you to work with them. Which means they will notbreak your existing projects with updates, they will ensure that storyboards are future proof for newer XCode/iOS versions.
2. More visible resultsin less timefor the product owners and managers, even during the creation phase. You can even use the storyboard itself as a screenflow diagram and discuss it in meetings.
3. Even after an app is done(and that's generally where its life-cycle begins) – in the future it will be faster and easier to apply small adjustments. And these could very well change multiple aspects of your layout at the same time, which you probably want to see in a WYSIWYG manner. The alternative would be hand-writing UI changes in code and switching back and forth between the IDE and the simulator to test it out, each time waiting for compile & build.
4. Non-developers can be taughtto set up layouts in storyboards and create the necessary hooks for the developers (IBOutlets and IBActions). That's a very big plus because it lets the devs focus on the logic and the UX designers apply their changes in a visual manner, without having to write any code at all.

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

I won't write up any CONS, since Johannes has already listed probably all the viable ones in his answer. And most of them are definitely not viable, especially not with XCode6's major improvements.

我不会写任何缺点，因为约翰内斯已经在他的回答中列出了可能所有可行的方案。而且它们中的大多数肯定是不可行的，尤其是在 XCode6 的重大改进下。

回答by Stefano Mondino

I don't think there is a right answer for your question, it's just a matter of personal experience and what you feel more confortable with.

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

In my opinion, Storyboards are a great thing. It's true, it's really hard to find out why your app is misteriously crashing at runtime, but after some time and experience you'll realize it's always related to some IBOutlet missing somewhere and you'll be easily able to fix it.

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

The only real issue is working in team under version control with storyboards, in the early stages of development it could be a real mess. But after that first stage, UI updates that completely changes the storyboard are very rare, and in most cases you end up with conflicts in the very last parts of the xml, which are segue references that usually autofix themselves when you re-open the storyboard. In our team work we prefered to deal with this instead of heavy view-controllers with tons of view code.

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

I've read many comments againts auto-layout. With XCode5 it got really improved, It's really good even for autorotating layouts. In some case you'll have to do something in code, but you can simply outlet the constraint you need to edit and, at that point, do what you need in your code. Even animate them.

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

I also think that most of the people who dislike storyboards didn't fully try to understand the power of a custom manual segue, where you can totally customize (in a single file) the way you transition from a way to another and also (with some tricks) even reuse a previously loaded view controller by just updating it's view contents instead of fully reload the whole thing. At the end you can really do the same things as in code, but I think you have a better separation of concerns with storyboards, but I agree that in many things they lack of features (fonts, image as color background, ecc...).

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

回答by Hemang

I am not using StoryBoard or XIBs in my any of the app.. but creating everything programmatically.

我没有在我的任何应用程序中使用 StoryBoard 或 XIBs ..而是以编程方式创建所有内容。

? Benefits :

? 好处 ：

√ You can create any complex kind of UI or transition animations for UIView's.

√ 您可以为UIView's创建任何复杂类型的 UI 或过渡动画。

√ Support all iOS versions. No need to worry about < iOS 5.

√ 支持所有iOS版本。无需担心 < iOS 5。

√ *Your app would support all iPhone/iPod/iPad devices within your code.

√ *您的应用程序将支持您代码中的所有 iPhone/iPod/iPad 设备。

√ You're always updated as you know the code that'll always work.

√ 你总是在更新，因为你知道代码总是有效的。

√ *Will work on any (new) device launched –?No need to change in code.

√ *适用于任何推出的（新）设备–？无需更改代码。

√ Everything is upto you. At certain place you want to change something – No need to look into storyboard or xib. Just search for it in particular class.

√ 一切由你决定。在某些地方，你想改变的东西 - 没有需要寻找到故事板或XIB。只需在特定类中搜索它。

√ Last but not the list –?You'll never forget that, how to manage everything programmatically. This is the best thing as you know a control very deep then anyone.

√ 最后但不是列表–？你永远不会忘记，如何以编程方式管理一切。这是最好的事情，因为您对控制的了解比任何人都深。

_{I've never find a problem by not using SB or XIBs as I'm good with this.}

_{我从来没有通过不使用 SB 或 XIB 来发现问题，因为我很擅长这个。}

_{* if you've set UIKit's object frames according to screen size.}

_{* 如果你已经根据屏幕尺寸设置了 UIKit 的对象框架。}

_{P.S. If you've still not done this thing –?you may faced difficulty (or may feel boring) but once you get familiar with this –?its really a Candy for you.}

_{PS 如果你还没有做过这件事——你可能会遇到困难（或者可能会觉得无聊）但是一旦你熟悉了——这对你来说真的是糖果。}

回答by onmyway133

If you are about to care about Storyboard performance, watch WWDC 2015 Session 407

如果您想关心 Storyboard 的性能，请观看WWDC 2015 Session 407

Build Time

构建时间

When interface builder is compiling a storyboard it's doing two things first, it's trying to maximize the performance of your application and secondly it's also minimizing the number of nib files created.

If I have a view controller with a view and a bunch of sub views, interface builder, the build time is going to create a nib file for the view controller and create a nib file for the view.

By having separate nib files for both the view controller and the view, this means the view hierarchy can be loaded on demand.

当界面构建器编译故事板时，它首先做两件事，它试图最大限度地提高应用程序的性能，其次它也最大限度地减少创建的 nib 文件的数量。

如果我有一个带有视图和一堆子视图、界面构建器的视图控制器，构建时间将为视图控制器创建一个 nib 文件并为视图创建一个 nib 文件。

通过为视图控制器和视图使用单独的 nib 文件，这意味着可以按需加载视图层次结构。

Run Time

运行

When you allocate a storyboard instance using UI storyboard, API, initially all you are allocating memory for is the UI storyboard instance itself.

No view controllers no views yet.

When you instantiate your initial view controller it will load the nib for that initial view controller but, again, no view hierarchy has been loaded yet until someone actually asks for it.

当您使用 UI 故事板 API 分配故事板实例时，最初您分配的所有内存都是 UI 故事板实例本身。

没有视图控制器还没有视图。

当您实例化初始视图控制器时，它将加载该初始视图控制器的笔尖，但同样，在有人实际要求之前，还没有加载任何视图层次结构。

回答by Krishna Vedula

I have been working on a reasonably sized project (>20 scenes in storyboard parlance), and have come across many limitations and have to repeatedly go to documentation and google searches for doing things.

我一直在一个合理的规模项目（>在故事板上的说法20个场景），以及所遇到的许多限制，并要反复去文档和谷歌搜索做的事情。

1. The UI is all in one file. Even if you create multiple storyboards, you still have many scenes/screens in each storyboard. This is a problem in medium-large teams.

2. Secondly, they do not play well with custom Container Controllers which embed other container controllers etc. We're using MFSlideMenu in a Tabbed application and the scene has a table. This is almost impossible to do with a storyboard. Having spent days, I've resorted to doing the XIB way where there is complete control.

3. The IDE does not allow to select controls in zoomed-out state. So, in a large project, the zoom-out is mostly to get a high level view and nothing more.

1. 用户界面全部在一个文件中。即使您创建了多个故事板，每个故事板中仍然有许多场景/屏幕。这是中大型团队的问题。

2. 其次，它们不能很好地与嵌入其他容器控制器等的自定义容器控制器配合使用。我们在 Tabbed 应用程序中使用 MFSlideMenu，场景中有一个表。这对于故事板几乎是不可能的。花了几天时间，我已经采取了完全控制的 XIB 方式。

3. IDE 不允许选择处于缩小状态的控件。因此，在大型项目中，缩小主要是为了获得更高层次的视图，仅此而已。

I would use storyboards for smaller applications with small team sizes and use XIB approach for medium-large teams/projects.

对于团队规模较小的小型应用程序，我会使用故事板，而对于中大型团队/项目，我会使用 XIB 方法。

回答by Bibin Jaimon

If you want to reuse some UI in multiple view controllers then you should use XIBs

如果你想在多个视图控制器中重用一些 UI 那么你应该使用 XIB