iOS杂谈-我为何不用Interface builder

在互联网上关于Interface Builder的争吵天天都在发生,用和不用你们都有一大堆的理由。最近看了这篇文章,不少地方和做者有共鸣,结合本身的一些经历,就有了你如今所看到的东西,你能够把它当成前者的中文版。程序员

一年前我开始作iOS开发,看的是Stanford的CS 193P。老头子推荐新手用Storyboard来作开发,由于它是可视化的,不太须要了解代码层的东西就能拖出界面,各类配置项能够经过勾选搞定,省去不少代码,至关傻瓜,此外Storyboard也让人对应用程序的活动流程一目了然。我对这种拖拽式的编程方式很不习惯:这不是代码出奇迹的节奏啊!编程

我开始作实际的项目。看了几个开源项目的代码后,我知道旧时代有个xib格式的文件。这货是Interface Builder的产物,如今咱们称他们为NIB。用法和Storyboard差很少,可视化拖拽、配置。Storyboard比较新,业界用的人很少,因而我很纠结,究竟是听老头子的话用新东西,仍是随大流试试单独的NIB?初生牛犊不怕虎,反正没怎么作过iOS开发,就按课上说的来吧,咱们团队用Storyboard拖UI。一个月后,我提议弃用Interface Builder,不用任何NIB(包括Storyboard)。直到如今只要是在我控制范围内,我都没再碰过任何NIB,我更愿意用代码来生成。布局

不用Interface Builder的理由不少,对我来讲主要有一下几点:测试

多人协做

从项目管理的角度来说NIB就不该该被使用。你能保证本身历来不会在合并NIB时出现冲突吗?在一个稍有规模,多开发者的项目里,合并NIB简直就是梦魇。特别是多人共用一个Storyboard时,开发者将花费不少时间和精力去解决冲突,而不是去作比这更有意义的事。ui

固然,若是最终合并结果正确可信,那么不少同窗仍是能够忍受的。然而,合并毕竟是会出问题的,尤为是用Git自动合并。这些问题直到运行时才会出现!倘使测试力度不够,这就是潜在的隐患。此外,咱们知道NIB是人不可读的,也就是说,对它作版本控制几乎没有意义。你无法从diff看出来半点名堂。倘使你使用的不是NIB,而是一行一行的Objective-C代码,那么结果会好不少。翻译

选择显式而非隐式

我喜欢用代码来完成各类东西,这样你打开一个view或者一个view controller,就能看到全部东西。不然,看你代码的这位同窗还得去找相应的NIB。debug

NIB一样也是滋生bug的温床,不少时候你调试了半天才发现,某个bug并非出在本身的代码里,而是在Interface Builder的某个小角落里本身忘记给某个选项打上√。若是全部的组件都由代码生成,那么在调试时就简单得多,你只要专一于和View有关的代码就快好了。选择显式地在代码里写view,可让你对view有强大的控制力。从初始化到布局、绘制你都能插手,在代码里你清楚地知道某个view的各个属性会是多少,而非交由Interface Builder来管理,这样虽然看上去代码行数多了,但它帮你减小了bug数量,节省了debug时间。版本控制

耦合

用Interface Builder去建立可复用的view会是一件很蛋疼的事。首先你须要拖拽出各类各样的组件,而后给每一个组件设置属性,接着你要把outlet链接到要用到的代码块……某一次,你忘记连outlet,而后你的程序就在runtime crash了。看,你又弄出了一堆bug。对于各类零碎的view我更喜欢为他们写类,而后在里面实现各类我想要的东西,在须要用到这些view的时候生成对象就是了。若是我有什么错误,编译器大哥还能帮我检查。调试

使用NIB让我提心吊胆,它让程序变得不那么紧凑。不少须要内聚的东西,被分了出去。从实际的开发体验来说就是东一块,西一块,切来切去我都以为烦。一旦当你定制的view愈来愈多,NIB就增多,而后呵呵。code

布局

我认可本身几乎没在Interface Builder用过各类layout(包括auto-layout)。我不清楚用NIB作layout是否困难。但我知道重写UIViewlayoutSubviews让布局变得很简单。全部子元素的布局只要在这里设置就好了。须要从新布局时,调一下setNeedsLayout就行。不用关心什么Interface Builder里各类layout概念,不用把布局代码分地方写(下降耦合)。只要稍加判断,让同一个view适应iPhone和iPad不是什么难事。给iPad和iPhone分别提供NIB这种事简直不能忍。

本地化

当IB遇到本地化会发生什么呢?我屮艸芔茻!只要涉及本地化的NIB,都要你去投时间和体力作啊。点鼠标啊,设置啊,纯体力活!若是用代码,字符串用NSLocalizedString(@"Localizable String", @"Comment"),而后在资源文件里翻译一下,轻轻松松。

小结

Interface Builder的初衷多是但愿帮助开发者节省写界面的时间和精力。可视化,表现层和数据分离都是很好的思想。但它在目前还不让人满意。它让多人协做变得困难,诱导拙劣的实践,下降可复用性,让你开发变慢……

我若是能不用IB,就不用,做为一名程序员更应该用代码说话。从装逼角度来说,这样才显得高端大气上档次不是吗?

转:http://blog.xianqu.org/2013/06/why-i-dont-use-interface-builder/

相关文章
相关标签/搜索