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

Question

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

我可以说，当您通过动态UI元素推送视图控制器时（例如地图引脚），使用storyboard segues并不是那么干净。

Answer 1

我广泛使用了XIB并使用Storyboard完成了两个项目。我的经验是：

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

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

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

Answer 2

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

有一个类似于What is the difference between a .xib file and a .storyboard?的问题。

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

优点：

• 如果有任何代码，您可以模拟应用程序的流程而不需要写很多。
• 更容易看到屏幕与应用程序流程之间的转换。
• 如果需要，还可以使用.xibs与故事板。

CONS：

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

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

Answer 3

我只会说明 4个简单的原因为什么应该使用故事板，尤其是在您必须在产品所有者，产品经理团队中工作的高效环境中用户体验设计师等

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

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

Answer 4

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

在我看来，故事板是一件好事。这是真的，很难找到你的应用程序在运行时大量崩溃的原因，但经过一段时间和经验你会发现它总是与某些IBOutlet缺失有关，你很容易就能解决它。

唯一真正的问题是在故事板的版本控制下团队工作，在开发的早期阶段，它可能是一个真正的混乱。但是在第一阶段之后，完全更改故事板的UI更新非常罕见，并且在大多数情况下，最终会在xml的最后部分出现冲突，这些冲突通常在重新打开故事板时自动固定。 。在我们的团队工作中，我们倾向于处理这个问题，而不是使用大量视图代码的重型视图控制器。

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

我还认为，大多数不喜欢故事板的人并没有完全尝试理解自定义手动segue的强大功能，您可以完全自定义（在单个文件中）从一种方式转换到另一种方式（通过一些技巧）甚至可以通过更新它的视图内容来重用以前加载的视图控制器，而不是完全重新加载整个事物。 最后你可以真正做到与代码相同的事情，但我认为你对故事板有更好的分离，但我同意在许多事情上他们缺乏功能（字体，图像作为颜色背景，ecc ... ）。

Answer 5

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

Δ好处：

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

√支持所有iOS版本。无需担心＆lt; iOS 5。

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

√随着您知道始终有效的代码，您总是会更新。

√*适用于任何（新）设备启动 - 无需更改代码。

√一切都取决于你。在某个地方你想改变一些东西 - 不需要看故事板或xib。只需在特定课程中搜索它。

√最后但不是列表 - 你永远不会忘记，如何以编程方式管理所有内容。这是最好的事情，因为你知道一个控件比任何人都深。

_{我从未发现过使用SB或XIB的问题，因为我很擅长这个。}

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

<子> P.S。如果你还没有做过这件事 - 你可能会遇到困难（或者可能觉得无聊）但是一旦你熟悉了它 - 它真的是你的糖果。

Answer 6

如果您想关注故事板性能，请观看WWDC 2015 Session 407

构建时间

  

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

     

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

     

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

运行时间

  

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

     

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

     

当您实例化初始视图控制器时，它将加载笔尖   对于那个初始视图控制器，但同样，没有视图层次结构   已经加载，直到有人真正要求它。

Answer 7

我一直致力于一个规模相当大的项目（在故事板上说明了20个场景），并且遇到了很多限制，不得不反复去文档和谷歌搜索做事。

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

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

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

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

Answer 8

如果要在多个视图控制器中重用某些UI，则应使用XIB