Interface Builder的一些小技巧

　　最近接触了几个刚入门的iOS学习者，他们之中存在一个普遍和困惑和疑问，就是应该如何制作UI界面。iOS应用是非常重视用户体验的，可以说绝大多数的应用成功与否与交互设计以及UI是否漂亮易用有着非常大的关系。而随着iOS开发发展至今，可以说在UI制作上大家逐渐分化为了三种主要流派：使用代码手写 UI及布局;使用单个xib文件组织viewController或者view;使用StoryBoard来通过单个或很少的几个(关于这点稍后会进行展开)文件构建全部UI。应该使用哪种方式来制作UI已经是iOS开发中亘古不变的争论话题了，或许永远不会有一个统一的结论。但是首先需要知道的是三种方式各有优劣，所以也各有自己最适用的场合，而不会有完全的孰优孰劣。对于初学iOS开发来说，一时间其实是很难判定最适合自己的UI架构方式的。在这篇文章里我希望能够通过自己的经验给出一些意见，以期能帮助入门者来挑选最适合自己应用场景的方案。对于老鸟的话，也不妨对照自己平日的使用习惯和运用场景，看看有没有可以改进或变化的地方。最后，因为我本人现在最习惯和喜欢的是用Interface Builder(之后简称IB)及xib来做UI，所以文末附上了一些IB使用时候的小技巧，算是做个总结。

　　代码手写UI

　　这种方法经常被学院派的极客或者依赖多人合作的大型项目大规模使用。Geek们喜欢用代码构建UI，是因为代码是键盘敲出来的，这样可以做到不开 IB，手不离开键盘就完成工作，可以专注于编码环境，看起来很cool很高效，而且不到运行时大家都不知道会是什么样子，也显出了程序员这一职业的高大上及神秘气息(这个真的不是在黑..想想大家一起在设计师背后指点江山的场景吧)。大型多人合作项目使用代码构建UI，主要是看中纯代码在版本管理时的优势，检查追踪改动以及进行代码合并相对容易一些。

　　另外，代码UI可以说具有最好的代码重用性。如果你的目的是写一些可以高度重用的控件提供给其他开发者使用，那毫无疑问最好的选择应该是使用代码来完成UIView的子类。这样进一步的修改和其他开发者在使用时，都会方便不少。使用代码也是最为强大的，会有xib或者StoryBoard做不了的事情，但是使用代码最终一定能够完成所要的需求。

　　但是代码手写UI的劣势同时也是最明显的，主要就是一个字：慢。首先相比可视化的IB来说，完成一个并不太复杂的界面，你可能需要写上数百行的UI 代码。不论是初始化一个Label，还是设定一个frame或者添加一个target-action，都需要写代码，这不仅在前期极为浪费时间，在之后维护时代码定位和寻找也会很痛苦。其次，因为你无法直观地看到你能得到的结果，所以你很可能需要不断地Cmd+R/Cmd+.来修改各个视图的位置大小。即使你用上了Reveal或者RestartLessOften之类的工具，也还是无法特别方便地完成需要的布局。另外加上如果需要利用AutoLayout来进行尺寸适配的话，使用代码进行约束就更加头疼了。很多时候一个无法满足的约束的问题就够来回运行修改调试很长时间了。

　　Xibs

　　相对于代码，使用IB和xib文件来组织UI，可以省下大量代码和时间，从而得到更快的开发速度。如果你曾经受到过微软家Visual Basic或者其他Visual系的可视化界面的荼毒与残害，因此怀疑Interface Builder的纯正血统和工作能力，建议可以看看这些资料以纠正三观：Jean-Marie Hullot的Interface Builder神话，西装革履的青涩乔帮主在NeXT时亲手用IB构建应用(需要翻墙)。另外，不妨打开你的Mac上的Application文件夹中或者iPhone上Apple家的各种应用。你会惊奇地发现，IB远比你看到的要强大：小至计算器取色器这类小工具，大至iWork三件套，Aperture或Final Cut这样的专业级应用，无一不是使用IB来完成UI制作的。

　　其实IB和xib是从iOS SDK初次面世开始就是捆绑在开发者工具套装内的内容了，而到了Xcode 4之后更被直接集成到了Xcode中成为了IDE的一部分。xib设计的一大目的其实是为了良好的MVC：一般来说，单个的xib文件对应一个 ViewController，而对于一些自定义的view，往往也会使用单个xib并从main bundle进行加载的方式来载入。IB帮助完成view的创建，布局和与file owner的关系映射等一些列工作。对于初学者来说，牢记xib的文件都是view的内容，有助于建立起较好的MVC的概念，从而在开发中避免或少走弯路。

　　xib文件之前一大被诟病的问题是文件内容过于复杂，可读性很差，即使只是简单打开没有编辑也有可能造成变化而导致合并和提交的苦难。在Xcode 5中Apple大幅简化了xib文件的格式，使其变得易读易维护。可以说现在对于xib文件在版本管理上其实和纯代码已经没有太大差异，只要仔细看过一遍 xib的文件内容，自然能理解绝大部分，并很好地追踪并查找过往的修改记录了。

　　当然xib也不是完美的。最大的问题在于xib中的设置往往并非最终设置，在代码中你将有机会覆盖你在xib文件中进行的UI设计。在不同的地方对同一个属性进行设置，这在之后的维护中将会是噩梦般的存在。因为其实IB还是有所局限的，它没有逻辑判断，也很难在运行时进行配置，而反之使用代码确是无所不能的。在使用xib时，辅以部分代码来补充和完成功能几乎是不可避免的。关于这点在开发时应该予以高度重视，如果选择xib，那么要尽量将xib的工作和代码的工作隔离开来：能够使用xib完成的内容就统一使用xib来做，而不要说三个Label其中两个在xib设置了字体而另一个却在代码中完成。尽量仅保持必要的、较少的IBOutlet和IBAction会是一个好方法。

　　StoryBoard

　　iOS5之后Apple提供了一种全新的方式来制作UI，那就是StoryBoard。简单理解来说，可以把StoryBoard看做是一组 viewController对应的xib，以及它们之间的转换方式的集合。在StoryBoard中不仅可以看到每个ViewController的布局样式，也可以明确地知道各个ViewController之间的转换关系。相对于单个的xib，其代码需求更少，也由于集合了各个xib，使得对于界面的理解和修改的速度也得到了更大提升。减少代码量就是减少bug量，这也是程序开发中的真理之一。

　　在Xcode5之后，StoryBoard已经成为新建项目的默认配置，这也代表了Apple对开发者的建议和未来的方向。WWDC2013的各个 Sample Code中也基本都使用了StoryBoard来进行演示。可以预见到，之后Apple必定会在这方面进行继续强化，而反之纯代码或者单个xib的方式很可能不会再得到增强。

原文转自：http://onevcat.com/2013/12/code-vs-xib-vs-storyboard/