关于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];
  1. 代码理解更加耗时,如果接收到的是一个新项目,需要花费更多的时间来理解其中的逻辑才能对其加以修改。

总结

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

你可能感兴趣的:(关于UI构建的思考:Storyboards、XIBs与纯代码)