4

我知道这个话题很热门，并且有很多讨论，但是我们仍然在我们的应用程序中使用 xibs，即使最低部署目标是 iOS5（很快将切换到 iOS6）。我们已经查看并阅读了很多关于故事板的内容，似乎 Apple 正在将这种方法作为一种首选方式来处理 UI 内容，但是我们看不到使用这种“玩具”工具的任何真正好处。故事板对于相对较小的开发者项目应用程序来说可能很方便，但是在大型的多个开发项目中并没有真正的好处，因为合并 git/svn 故事板冲突是一件令人头疼的事情，所以故事板必须分成模块，甚至可能只包含一个屏幕，因此在这种情况下它变得与 Xib 方法非常相似。此外，中型和大型应用程序的导航序列有点复杂。

到目前为止，我只看到了一个好处——屏幕可视化和导航在一个地方。是的，我们在使用 Xibs 时没有这样的导航流程，但是，您可以使用任何 UML 建模工具（例如，Astah 社区免费版工具）为此绘制 UML 屏幕导航计划图（就像我们一样），就是这样. 所有的 UI 都可以方便地分解为 Xib，从代码中加载和添加它们非常简单直接。即使我们开始开发相对较小的应用程序，它也可能（并且会）在以后变大，因此在开始时使用灵活的 Xibs 会阻止您以后使用其他解决方法。

所以，这些是我的想法和观察，我想听听那些用故事板开发大型应用程序的开发人员的其他意见，以及他们看到的专业人士。我最担心的是 Apple 会否决 Xibs，因为我们正在启动一个可能会持续 2 年或更长时间的新大项目，因此即使使用方便且首选的 UI 方式，使用在不久的将来会弃用的方法也会让人不舒服东西。

4

2 回答 2

5

Without insider knowledge this question is pretty much impossible to answer definitively.

In general, using the technologies that Apple promote is probably the safest. But not always -- people were burned by 64-bit Carbon and garbage collection.

Having said that, I don't see XIBs going away any time soon. They're too well used on both iOS and the Mac that Apple couldn't get rid of them in a short period even if they wanted to.

于 2013-09-30T08:36:30.803 回答
2

看起来 Apple 想要使用故事板，而您对它的优缺点是完全正确的。

虽然我不太喜欢 xib/storyboards 的整个想法。一方面是 git 冲突，另一方面是从 xib/storyboard 创建视图要慢得多（而且组织性较差），如果您要自己编写所有代码。出于这个原因，在我工作的地方设计的大多数专业应用程序甚至都没有 xib/storyboard，每个 UI 元素都是编码的。

于 2013-09-30T08:39:11.650 回答