iphone – 故事板与在代码中完成它

就NIB而言,源代码控制问题可能很痛苦但可管理,主要是因为您通常每个视图控制器都有一个NIB文件.你可以想象一种情况,你有两个开发人员在NIB驱动的应用程序的两个不同部分工作,没有任何合并问题.故事板是不同的,因为您只有一个文件描述了应用程序的大多数(如果不是全部)UI.显然,那里存在更大的冲突问题.

如果使用正确,NIB可以非常有用并且可以节省时间.这是一个例子：iPad上的iPhoto App具有非常复杂的UI.用户界面的绝大部分是以编程方式布局的.但是,该应用程序还使用NIB加载图形元素,然后在代码中进行布局.这是刷子面板的工作方式 – 所有刷子都是在NIB中创建的.这意味着Apple不必拥有数十个相同的图像/图像视图alloc / init代码片段.所有创建都可以在NIB中进行(在iPhoto UI上的WWDC 2012会话中对此进行了详细讨论 – 非常值得追踪).

因此,NIB(有时候很好)可以为您节省大量时间,虽然存在合并问题,但在许多情况下,它们可以轻松管理和处理.

然后我们来到故事板.故事板很有趣.一方面,它们对于直接应用程序和平台新手开发人员非常有用且有用.我刚刚将基于UINavigationController的应用程序从NIB转换为故事板,并发现了一些显着的时间节省(特别是在表视图之外,因为使用故事板可以利用原型单元).

但是,如果您正在与几个开发人员一起开展大型项目,我不相信故事板是有益的.正如你所说,存在合并冲突的大问题,与NIB不同,解决它们并不容易,因为单个故事板文件控制着你的所有应用UI.

这就是我建议的内容(并且可以随意忽略我！) – 如果您正在开发应用程序并完全使用代码完成布局/ UI,请考虑NIB是否可以节省您的时间.他们可能不会 – 他们不适合所有人 – 但至少值得考虑是值得的.您可能会惊讶于有多少大型应用程序实际使用NIB(iPhoto,正如我所提到的,还有Apple提供的许多内置应用程序,以及大型团队提供的许多流行的第三方应用程序).我可能不会考虑故事板,除非你是一个单独的开发人员在一个具有相当简单导航的应用程序上工作.这不是以任何方式做故事板 – 我喜欢使用它们 – 它只是它们不适合合作.

有人发表了这条评论以回答你的问题 – 我想讨论一下：

There is nothing you can do in storyboard and can’t do in code. Objects,gesture recognizers,segues,even constraints – are all available for you to build programmatically

这在技术上是正确的,但实际上故事板/ NIB中的东西比代码容易得多.一个很好的例子是自动布局.虽然您完全可以在代码中管理自动布局约束,但严酷的现实是,ASCII自动布局表示比您在IB中获得的可视化表示更难处理.在XCode 5上尤其如此,其中IB中的自动布局有了很大的改进(我不能详细说明它仍然在NDA下,但Apple公开谈论changes here).