iphone - Storyboard与在代码中做

Question

我在一家公司工作，我们有几个 iOS 开发人员，我们使用 GIT 一起在同一个项目中工作。我们从不在开发过程中使用 Storyboard或 .xib 文件，因为几乎不可能正确合并它们。

随着 iOS7 的推出，我思考了 Storyboard 与“以旧方式”对所有 UI 进行编码(不使用 Interface Builder)之间的根本区别。

这里有人会这样做吗？最重要的是，有什么是您可以在 Storyboard 中完成而在 XCode 5 中的代码中无法完成的吗？

Answer 1

我要把你的问题分成两部分:NIB 和 Storyboard。

就 NIB 而言，源代码控制问题可能会很痛苦但可以管理，主要是因为通常每个 View Controller 都有一个 NIB 文件。你可以想象这样一种情况，你有两个开发人员在你的 NIB 支持的应用程序的两个不同部分工作，没有任何合并问题。 Storyboard不同，因为您只有一个文件来描述应用程序的大部分(如果不是全部)用户界面。显然，那里出现冲突问题的可能性要大得多。

如果使用得当，NIB 可以非常有用并且可以节省时间。举个例子:iPad 上的 iPhoto 应用程序有一个非常复杂的用户界面。该 UI 的绝大部分都是以编程方式布局的。 但是，该应用程序还使用 NIB 加载图形元素，然后在代码中进行布局。这就是画笔面板的工作原理——所有画笔都是在 NIB 中创建的。这意味着 Apple 不必拥有许多相同的图像/ ImageView 分配/初始化代码片段。所有创建都可以在 NIB 中进行(这在 iPhoto UI 的 WWDC 2012 session 中进行了一些详细讨论 - 这非常值得追踪)。

所以 NIB - 有时很好，可以为您节省很多时间，虽然存在合并问题，但在许多情况下它们可以很容易地管理和处理。

然后我们来到 Storyboard。 Storyboard很有趣。一方面，它们对于直接使用该平台的应用程序和开发人员非常有用。我刚刚将一个基于 UINavigationController 的应用程序从 NIB 转换为 Storyboard，并发现节省了大量时间(特别是围绕表格 View ，因为使用 Storyboard您可以利用原型(prototype)单元格)。

但是，如果您正在与多个开发人员一起处理大型项目，我不认为 Storyboard有那么大的好处。正如您所说，合并冲突存在重大问题，并且与 NIB 不同，解决这些冲突并不容易，因为单个 Storyboard 文件控制所有您的应用程序 UI。

这是我的建议(请随意忽略我!)- 如果您目前正在开发应用程序并完全在代码中进行布局/UI，请考虑 NIB 是否可以节省您的时间。它们很可能不适合 - 它们并不适合所有人 - 但至少值得考虑。您可能会惊讶于有多少大型应用程序实际上使用了 NIB(正如我提到的 iPhoto，还有 Apple 提供的许多内置应用程序，以及大型团队提供的许多流行的第三方应用程序)。我可能不会考虑 Storyboard，除非您是开发导航相当简单的应用程序的唯一开发人员。这并不是要以任何方式简化 Storyboard - 我喜欢使用它们 - 只是它们不太适合协作。

有人发表了这条评论来回复你的问题 - 我想讨论一下:

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

这在技术上是正确的，但实际上 Storyboard/NIB 中的某些内容比代码容易得多。一个很好的例子是自动布局。虽然您当然可以完全在代码中管理您的自动布局约束，但严酷的现实是 ASCII 自动布局表示比您在 IB 中获得的视觉表示更难处理。这在 XCode 5 上尤其是是真的，它对 IB 中的自动布局进行了大量改进(我不能详细说明它，因为它仍在 NDA 下，但 Apple 公开谈论了一些关于 changes here ) .