相信大部分iOS开发者都提过这样一个问题:应当如何构建应用界面?
对于这个问题衍生出两大阵营:一方热衷于使用Interface Builder
构建界面;另一方选择使用纯代码(custom code
)来实现界面布局。
本文的目的就是总结各种方法的优劣,帮助开发者做出更好地选择。
在iOS中创建用户界面通常有三种方法:
- Storyboards——可视化工具,用于布局多个应用程序视图和它们之间的转换关系(segue)。
- XIB(或NIBs)——每个XIB文件对应一个单独的视图,可以在
Interface Builder
中进行布局,使其可以直观展示。(以前是.nib
,现在是. XIB
)。 - 自定义代码(
custom code
)——不使用可视化工具,通过编程方式处理所有的位置、动画、页面创建等。
Storyboards
Storyboards在最初添加到iOS UI开发工具包的时候被认为是未来的趋势,将会取代XIB与纯代码,Storyboards确实作用巨大,但它并无法适应所有的UI开发情况,XIB与纯代码依然有其优势所在。
Storyboards非常适合初学者上手使用,可以方便的看到整个设计,容易修改。但伴随着应用程序的增长,Storyboards难免出现庞大,加载缓慢,修改也十分麻烦的问题。Storyboards最后很可能变成下面这样:
应用程序应该根据逻辑单元(stories
)进行划分,不应当把所有不相关的逻辑单元混合到一起。例如,用户列表及其相关功能(添加、点评等)可以组成一个逻辑单元。这样就可以得到一个条理清晰的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的完美解决方案,但它也有些不容忽视的弊端。
纯代码的缺点
- 查看原型变得困难,不如
Interface Builder
来的方便,每次查看都需要经过编译/运行这样一个周期,调试会有一些不方便。 - 布局添加不直观且复杂。如下添加一个约束:
[NSLayoutConstraint constraintWithItem:self.button1 attribute: NSLayoutAttributeRight relatedBy: NSLayoutRelationEqual toItem: self.button2 attribute: NSLayoutAttributedLeft multiplier:1.0 constant: -12.0];
- 代码理解更加耗时,如果接收到的是一个新项目,需要花费更多的时间来理解其中的逻辑才能对其加以修改。
总结
每种方法都有其优缺点,熟悉它们并在项目中一起使用它们,可以帮助我们节省时间,构建更加优秀的应用程序,Storyboards/XIBs提供了直观的UI构建体验,纯代码则让我们操控UI的可能性更多。根据需求,选择合适的方法,让你的代码编写更加畅快,应用程序更加令人心动!
有什么问题大家可以在评论区留言,相互探讨解决问题!