关于UI构建的思考：Storyboards、XIBs与纯代码

相信大部分iOS开发者都提过这样一个问题：应当如何构建应用界面？
对于这个问题衍生出两大阵营：一方热衷于使用Interface Builder构建界面；另一方选择使用纯代码(custom code)来实现界面布局。
本文的目的就是总结各种方法的优劣，帮助开发者做出更好地选择。

在iOS中创建用户界面通常有三种方法:

1. Storyboards——可视化工具，用于布局多个应用程序视图和它们之间的转换关系(segue)。
2. XIB(或NIBs)——每个XIB文件对应一个单独的视图，可以在Interface Builder中进行布局，使其可以直观展示。(以前是.nib，现在是. XIB)。
3. 自定义代码(custom code)——不使用可视化工具，通过编程方式处理所有的位置、动画、页面创建等。

Storyboards

Storyboards在最初添加到iOS UI开发工具包的时候被认为是未来的趋势，将会取代XIB与纯代码，Storyboards确实作用巨大，但它并无法适应所有的UI开发情况，XIB与纯代码依然有其优势所在。

Storyboards非常适合初学者上手使用，可以方便的看到整个设计，容易修改。但伴随着应用程序的增长，Storyboards难免出现庞大，加载缓慢，修改也十分麻烦的问题。Storyboards最后很可能变成下面这样：

令人抓狂的Storyboards

应用程序应该根据逻辑单元(stories)进行划分，不应当把所有不相关的逻辑单元混合到一起。例如，用户列表及其相关功能(添加、点评等)可以组成一个逻辑单元。这样就可以得到一个条理清晰的Storyboards：

逻辑清楚的Storyboards

何时使用Storyboards

• 当我们想在不构建应用就看到流程时，Storyboards是很好的选择。
• 当我们使用静态表视图(static table views)或多个单元格模板，也可以选择Storyboards。
• 如果我们希望减少代码量，可以选择Storyboards，这可以节省大量页面分配、初始化代码。(Storyboards中这些可以自动完成)

Storyboards的优点

Storyboards的最大优势是可视化，一眼就能看出页面关系、操作流程。另外一个优点是快速原型化，可以快速模拟应用程序的设计、导航(navigation)、转换(transitions)。
另外使用Storyboards或XIB创建UI可以方便的使用自动布局。

Storyboards的缺点

第一个缺点是可重用性。Storyboards难以完成复制或移动图形元素，此时往往需要移动所有的依赖项(dependencies)。如果多位开发者共同在同一项目下工作，Storyboards经常会出现合并冲突，而Storyboards生成的是一个难以阅读的巨大的XML文件，会使冲突变得难以解决。
Storyboards中的视图控制器需要使用segues进行数据传递，所以容易导致带有许多if/else语句的大型prepareForSegue()方法。

有些人在使用Storyboards时也会遇到Xcode的bug。比如，出现不一致错误，必须频繁刷新DerivedData。

XIBs

一种古老的UI开发方式，但不代表它是过时且不好用的。只包含一个特定视图元素(view，table cell等)，每个视图都有自己的.xib文件。 XIB的有点：组件独立，更容易开发、测试和调试。

何时使用XIBs?

可以用于模态视图(modal views)、登录/注册、可重用视图(如模板、表格单元格等)。对于具有动态内容的复杂视图，应当避免使用XIBs。

XIB的优点

主要优势之一是可重用性。换句话说，“一次实现，随处可用”。可以在多个类中使用相同的布局以节省开发时间。

另一个优点是像Storyboards一样，Interface Builder可以让你看到你在做什么、方便的使用自动布局。

XIB的缺点

像Storyboards，与同一XIB上的其他同事一起编辑可能会产生很多冲突；此外，高度动态的视图很难使用XIB实现；另一个缺点是调试比较麻烦，例如，如果忘记在Interface Builder中建立连接、删除了内容、添加了错误的内容，等等，在XIB中不容易方便的调试。

在使用XIBs时需要注意的一件事是:它们是惰性加载的(lazily loaded)。因此直真正使用到它们时才会加载使用内存。延迟加载过程会带来延迟，可能导致负面影响。

纯代码(Custom code)

有时故事板/ xib和接口生成器是不够的。当我们使用代码来创建一个UI时，我们可以理解它背后的含义。在开始阶段，我们需要知道任何可以用故事板和xib实现的UI也可以用原始代码实现。这是最后的选择和救援。它有很多优点，但也有一些不可忽视的缺点。
某些时候Storyboards/XIBs这些Interface Builder的方式并不能满足我们的需求。使用代码创建UI可以更好地理解编码细节。任何使用Storyboards/XIBs实现的UI都可以使用纯代码实现，是我们编写UI的终极方式。同时它也具有各种各样的优点缺点。

何时使用纯代码?

创建动态布局时，或布局必须可定制还包含一些特殊效果(阴影、边框、圆角等)时，我们需要使用这种方法。纯代码可能会是唯一的解决办法。

纯代码的优点

第一个优点是性能，Storyboards/XIBs需要转换成代码。纯代码会跳过这一步，构建时间更短。可以对布局有更多的控制，自定义元素。例如，如果想在应用当中更改颜色、字体大小/样式，纯代码可以方便的随时随地改动，错误发生时，调试也更容易。另一个优点是可重用性——如果一个应用使用一组在整个应用中样式相同的元素，可以在一个地方创建它们，然后在整个应用中进行使用。例如，文本字段、按钮、标签等。同时，如果使用纯代码，解决合并冲突也会容易得多，在一个大项目的工作团队中工作时，这是一个很大的优势。
纯代码几乎可以称之为创建UI的完美解决方案，但它也有些不容忽视的弊端。

纯代码的缺点

1. 查看原型变得困难，不如Interface Builder来的方便，每次查看都需要经过编译/运行这样一个周期，调试会有一些不方便。
2. 布局添加不直观且复杂。如下添加一个约束：

[NSLayoutConstraint constraintWithItem:self.button1 attribute: NSLayoutAttributeRight relatedBy: NSLayoutRelationEqual toItem: self.button2 attribute: NSLayoutAttributedLeft multiplier:1.0 constant: -12.0];

3. 代码理解更加耗时，如果接收到的是一个新项目，需要花费更多的时间来理解其中的逻辑才能对其加以修改。

总结

每种方法都有其优缺点，熟悉它们并在项目中一起使用它们，可以帮助我们节省时间，构建更加优秀的应用程序，Storyboards/XIBs提供了直观的UI构建体验，纯代码则让我们操控UI的可能性更多。根据需求，选择合适的方法，让你的代码编写更加畅快，应用程序更加令人心动！
有什么问题大家可以在评论区留言，相互探讨解决问题！