美文网首页
代码手写UI,xib和StoryBoard间的博弈

代码手写UI,xib和StoryBoard间的博弈

作者: 哈布福禄克 | 来源:发表于2019-10-31 11:27 被阅读0次

        随着iOS开发发展至今,可以说在UI制作上大家逐渐分化为了三种主要流派:

    ①使用代码手写UI及布局;

    ②使用单个xib文件组织viewController或者view;

    ③使用StoryBoard来通过单个或很少的几个文件构建全部UI。

        ★首先需要知道的是三种方式各有优劣,所以也各有自己最适用的场合,而不会有完全的孰优孰劣。

    一、代码手写UI

    1、优点:

        这种方法经常被学院派的极客或者依赖多人合作的大型项目大规模使用。其主要是看中纯代码在版本管理时的优势,检查追踪改动以及进行代码合并相对容易一些。

        另外,代码UI可以说具有最好的代码重用性。如果你的目的是写一些可以高度重用的控件提供给其他开发者使用,那毫无疑问最好的选择应该是使用代码来完成UIView的子类。(xib或者StoryBoard做不了重用)

    2、缺点:

        代码手写UI的劣势同时也是最明显的,主要就是一个字:慢。首先相比可视化的IB来说,完成一个并不太复杂的界面,你可能需要写上数百行的UI代码。这不仅在前期极为浪费时间,在之后维护时代码定位和寻找也会很痛苦。

        其次,因为你无法直观地看到你能得到的结果,所以你很可能需要不断地Cmd+R/Cmd+.来修改各个视图的位置大小。即使你用上了Reveal或者RestartLessOften之类的工具,也还是无法特别方便地完成需要的布局。

        另外加上如果需要利用AutoLayout来进行尺寸适配的话,使用代码进行约束就更加头疼了。很多时候一个无法满足的约束的问题就够来回运行修改调试很长时间了。

    二、Xibs

    1、优点:

        相对于代码,使用IB和xib文件来组织UI,可以省下大量代码和时间,从而得到更快的开发速度。

        xib设计的一大目的其实是为了良好的MVC:一般来说,单个的xib文件对应一个ViewController,而对于一些自定义的view,往往也会使用单个xib并从main bundle进行加载的方式来载入。IB(Interface Builder)帮助完成view的创建,布局和与file owner的关系映射等一些列工作。对于初学者来说,牢记xib的文件都是view的内容,有助于建立起较好的MVC的概念,从而在开发中避免或少走弯路。

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

    2、缺点:

        在使用xib时,辅以部分代码来补充和完成功能几乎是不可避免的。这就导致在xib中的设置往往并非最终设置,在代码中你将有机会覆盖你在xib文件中进行的UI设计。在不同的地方对同一个属性进行设置,这在之后的维护中将会是噩梦般的存在。

        关于这点在开发时应该予以高度重视,如果选择xib,那么要尽量将xib的工作和代码的工作隔离开来:能够使用xib完成的内容就统一使用xib来做,而不要说三个Label其中两个在xib设置了字体而另一个却在代码中完成。尽量仅保持必要的、较少的IBOutlet和IBAction会是一个好方法。

    三、StoryBoard

    1、优点:

        iOS5之后Apple提供了一种全新的方式来制作UI,那就是StoryBoard。简单理解来说,可以把StoryBoard看做是一组viewController对应的xib,以及它们之间的转换方式的集合。

        在StoryBoard中不仅可以看到每个ViewController的布局样式,也可以明确地知道各个ViewController之间的转换关系。相对于单个的xib,其代码需求更少,也由于集合了各个xib,使得对于界面的理解和修改的速度也得到了更大提升。减少代码量就是减少bug量,这也是程序开发中的真理之一。    

    2、缺点:

    StoryBoard面临的多人协作开发易起冲突问题。在Xcode 7 引入SB Reference的时候,就已经成为假命题了。通过合理地划分功能模块和每个开发者负责的部分,我们可以完全避免SB 的修改冲突。

        StoryBoard的另外的挑战来源于ViewController的重用和自定义的view的处理。对于前者,在正确封装接口以及良好设计的基础上,其实StoryBoard的VC重用与代码的VC重用是没有本质区别的,在StoryBoard中添加封装良好需要重用的Scene即可解决。而对于后者,因为StoryBoard中已经不允许有单个view的存在,因此很多时候我们还是需要借助于单个的xib来自定义UI。这一点可以说是由于StoryBoard的设计思路所造成的,StoryBoard更强调的是一种层次结构,是在全局的视角上来组织UI设计和迁移。而对于单个的view,更多的会注重于重用和定制,而与整个项目的流程没有太大关系。相信抓住这一要点,就能很好地了解什么时候使用xib,什么时候使用StoryBoard。

    四、我的观点和选择

        对于初学者来说,我并不建议上手就直接使用代码来进行UI制作和布局,因为冗长的UI代码确实非常乏味无趣。尽快看到成品,至少尽快看到原型,是保持兴趣,继续深入和从事职业的有效动力。所以如果有可能有条件,在老鸟的指导下选择StoryBoard来进行快速构建(或者如果是单个人开发的话,可以不用考虑多个StoryBoard协作,就更容易),会是入门的好选择。而最新的教程和文档已经开始逐渐偏向StoryBoard,关于StoryBoard的问题在SO上关注度也会更高,这样在入门时会有更多的资料可以进行参考。

        这并不是说不需要关心代码UI或者xib,因为使用StoryBoard的时候在只能使用代码以及自定义单个view时,还是不可避免地需要接触它们的。这里想给的一点建议就是,虽然你不依赖代码来进行UI制作,但是了解并掌握如何使用纯代码来从头构建UI还是非常必要的:包括从新建Window开始,到初始化ViewController,添加必要的view,设定它们的property,以及添加和处理它们的各种响应及responser链等内容。现在iOS开发入门非常容易,Xcode和xib/StoryBoard帮助开发者隐藏了太多的细节,但是很多时候如果你不明白underhood到底是些什么,为什么这些xib/StoryBoard会这样运作的话,经常会出现卡在一些很可笑的和初级的bug上找不着北,这其实会是对时间的巨大浪费,很不值得。

    五、想什么呢,已经完事了!!

        This is over ❤ ! !

    相关文章

      网友评论

          本文标题:代码手写UI,xib和StoryBoard间的博弈

          本文链接:https://www.haomeiwen.com/subject/vvbzvctx.html