StoryBoard--看上去很美

介绍

StoryBoard 是苹果在 2011 年的 WWDC Session 309《Introducing Interface Builder Storyboarding》中介绍的 Interface Builder 的新功能。其基本想法是将原本的 xib 进行升级，引入一个容器用于管理多个 xib 文件，并且这个容器可以通过拖拽设置 xib 之间的界面跳转。而这个容器就是被苹果称做的 StoryBoard。下图是一个 Storyboard 的截图。

优点

总体上来说，Storyboard 有以下好处：

你可以从 storyboard 中很方便地梳理出所有 View Controller 的界面间的调用关系。这一点对于新加入项目组的开发同事来说，比较友好。
使用 Storyboard 可以使用 Table View Controller 的 Static Cell 功能。对于开发一些 Cell 不多，但每个 Cell 都不一样的列表类设置界面会比较方便。
通过实现 - (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender 方法，每个 View Controller 的跳转逻辑都聚集在一处，这方便我们统一管理界面跳转和传递数据。
Storyboard 可以方便将一些常用功能模块化和复用。例如 WWDC2011 年介绍 Storyboard 的视频就将微博分享功能模块化成一个单独的 Storyboard。我在开发 App 时，也将例如通过第三方注册登录模块做成一个单独的 Storyboard，便于以后复用。

缺点

我在新项目使用 Storyboard 时，却发现它只是看上去很美，真正用起来，却有很多问题，我发现的问题有：

首先它和 xib 一样，对版本管理是灾难。因为是它实际上的多个 xib 的集合，所以更容易让多人编辑产生冲突。苹果对 storyboard 的设计也不好，基本上你只要打开，什么都不做，这个文件就会被更改，所以冲突几乎是不可避免的—除非你不打开，实在不小心打开看了，需要在提交前回退成服务器上的版本。
Storyboard 提供的 Static cell 特性只适合于 UITableViewController 的子类。我很多时候的用法是一个 TableView 嵌套在另一个 UIView 中，static cell 就不能用了。
segue 的概念对于开发来说并不省事，如果是用程序内部 trigger 一个 segue，那么需要在另一个回调的地方设置 dest view controller 的参数信息。

总结

我仔细比较权衡了一下优缺点，最主要的问题是我的版本管理在多人协作开发时将陷入灾难，而这是完全不能接受的。而最主要的好处就是，你可以在一个类似白板的地方 “一揽众山小 “一样了解所有界面之间的切换关系，但这个有那么重要吗？我自已其实很清楚跳转逻辑，这个只是对新同事了解项目代码时有帮助，那我花一点时间直接给他讲讲画画不就搞定的吗？为了这点好处而让版本管理无法使用，是完全不能接受的。

所以最终我决定放弃使用 StoryBoard 了，这个 “看上去很美” 的功能有着不可接受的缺陷。现在看来，它仅适用于做一些 Demo 的开发。苹果一直没有处理好这类可视化界面设计功能的版本管理，象 xib 文件，虽然是 xml 格式的，但如果多人编辑了，合并起来也会很麻烦。所以业界好多同行都不用 xib, 直接用纯代码来写界面，虽然稍慢一点儿，但是工程很干净，也基本没有了多人协作的版本冲突问题。

2013-10-6 更新

苹果在 WWDC2013 之后发布了 Xcode5，storyboard 和 xib 的内部实现进行了大量修改，使得其格式更加简单和易读，最终的效果是在版本冲突时，合并冲突变得可能。所以，现在我对于 storyboard 和 xib 不再象以前那么排斥了。