代碼手寫UI

這種方法經(jīng)常被學(xué)院派的極客或者依賴多人合作的大型項(xiàng)目大規(guī)模使用。Geek們喜歡用代碼構(gòu)建UI，是因?yàn)榇a是鍵盤敲出來(lái)的，這樣可以做到不開IB，手不離開鍵盤就完成工作，可以專注于編碼環(huán)境，看起來(lái)很cool很高效，而且不到運(yùn)行時(shí)大家都不知道會(huì)是什么樣子，也顯出了程序員這一職業(yè)的高大上及神秘氣息（這個(gè)真的不是在黑..想想大家一起在設(shè)計(jì)師背后指點(diǎn)江山的場(chǎng)景吧）。大型多人合作項(xiàng)目使用代碼構(gòu)建UI，主要是看中純代碼在版本管理時(shí)的優(yōu)勢(shì)，檢查追蹤改動(dòng)以及進(jìn)行代碼合并相對(duì)容易一些。

另外，代碼UI可以說(shuō)具有最好的代碼重用性。如果你的目的是寫一些可以高度重用的控件提供給其他開發(fā)者使用，那毫無(wú)疑問最好的選擇應(yīng)該是使用代碼來(lái)完成UIView的子類。這樣進(jìn)一步的修改和其他開發(fā)者在使用時(shí)，都會(huì)方便不少。使用代碼也是最為強(qiáng)大的，會(huì)有xib或者StoryBoard做不了的事情，但是使用代碼最終一定能夠完成所要的需求。

但是代碼手寫UI的劣勢(shì)同時(shí)也是最明顯的，主要就是一個(gè)字：慢。首先相比可視化的IB來(lái)說(shuō)，完成一個(gè)并不太復(fù)雜的界面，你可能需要寫上數(shù)百行的UI代碼。不論是初始化一個(gè)Label，還是設(shè)定一個(gè)frame或者添加一個(gè)target-action，都需要寫代碼，這不僅在前期極為浪費(fèi)時(shí)間，在之后維護(hù)時(shí)代碼定位和尋找也會(huì)很痛苦。其次，因?yàn)槟銦o(wú)法直觀地看到你能得到的結(jié)果，所以你很可能需要不斷地Cmd+R/Cmd+.來(lái)修改各個(gè)視圖的位置大小。即使你用上了Reveal或者RestartLessOften之類的工具，也還是無(wú)法特別方便地完成需要的布局。另外加上如果需要利用AutoLayout來(lái)進(jìn)行尺寸適配的話，使用代碼進(jìn)行約束就更加頭疼了。很多時(shí)候一個(gè)無(wú)法滿足的約束的問題就夠來(lái)回運(yùn)行修改調(diào)試很長(zhǎng)時(shí)間了。

Xibs

相對(duì)于代碼，使用IB和xib文件來(lái)組織UI，可以省下大量代碼和時(shí)間，從而得到更快的開發(fā)速度。如果你曾經(jīng)受到過微軟家Visual Basic或者其他Visual系的可視化界面的荼毒與殘害，因此懷疑Interface Builder的純正血統(tǒng)和工作能力，建議可以看看這些資料以糾正三觀：Jean-Marie Hullot的Interface Builder神話以及西裝革履的青澀喬幫主在NeXT時(shí)親手用IB構(gòu)建應(yīng)用（需要FQ）。另外，不妨打開你的Mac上的Application文件夾中或者iPhone上Apple家的各種應(yīng)用。你會(huì)驚奇地發(fā)現(xiàn)，IB遠(yuǎn)比你看到的要強(qiáng)大：小至計(jì)算器取色器這類小工具，大至iWork三件套，Aperture或Final Cut這樣的專業(yè)級(jí)應(yīng)用，無(wú)一不是使用IB來(lái)完成UI制作的。

其實(shí)IB和xib是從iOS SDK初次面世開始就是捆綁在開發(fā)者工具套裝內(nèi)的內(nèi)容了，而到了Xcode 4之后更被直接集成到了Xcode中成為了IDE的一部分。xib設(shè)計(jì)的一大目的其實(shí)是為了良好的MVC：一般來(lái)說(shuō)，單個(gè)的xib文件對(duì)應(yīng)一個(gè)ViewController，而對(duì)于一些自定義的view，往往也會(huì)使用單個(gè)xib并從main bundle進(jìn)行加載的方式來(lái)載入。IB幫助完成view的創(chuàng)建，布局和與file owner的關(guān)系映射等一些列工作。對(duì)于初學(xué)者來(lái)說(shuō)，牢記xib的文件都是view的內(nèi)容，有助于建立起較好的MVC的概念，從而在開發(fā)中避免或少走彎路。

xib文件之前一大被詬病的問題是文件內(nèi)容過于復(fù)雜，可讀性很差，即使只是簡(jiǎn)單打開沒有編輯也有可能造成變化而導(dǎo)致合并和提交的苦難。在Xcode 5中Apple大幅簡(jiǎn)化了xib文件的格式，使其變得易讀易維護(hù)。可以說(shuō)現(xiàn)在對(duì)于xib文件在版本管理上其實(shí)和純代碼已經(jīng)沒有太大差異，只要仔細(xì)看過一遍xib的文件內(nèi)容，自然能理解絕大部分，并很好地追蹤并查找過往的修改記錄了。

當(dāng)然xib也不是完美的。最大的問題在于xib中的設(shè)置往往并非最終設(shè)置，在代碼中你將有機(jī)會(huì)覆蓋你在xib文件中進(jìn)行的UI設(shè)計(jì)。在不同的地方對(duì)同一個(gè)屬性進(jìn)行設(shè)置，這在之后的維護(hù)中將會(huì)是噩夢(mèng)般的存在。因?yàn)槠鋵?shí)IB還是有所局限的，它沒有邏輯判斷，也很難在運(yùn)行時(shí)進(jìn)行配置，而反之使用代碼確是無(wú)所不能的。在使用xib時(shí)，輔以部分代碼來(lái)補(bǔ)充和完成功能幾乎是不可避免的。關(guān)于這點(diǎn)在開發(fā)時(shí)應(yīng)該予以高度重視，如果選擇xib，那么要盡量將xib的工作和代碼的工作隔離開來(lái)：能夠使用xib完成的內(nèi)容就統(tǒng)一使用xib來(lái)做，而不要說(shuō)三個(gè)Label其中兩個(gè)在xib設(shè)置了字體而另一個(gè)卻在代碼中完成。盡量?jī)H保持必要的、較少的IBOutlet和IBAction會(huì)是一個(gè)好方法。

StoryBoard

iOS5之后Apple提供了一種全新的方式來(lái)制作UI，那就是StoryBoard。簡(jiǎn)單理解來(lái)說(shuō)，可以把StoryBoard看做是一組viewController對(duì)應(yīng)的xib，以及它們之間的轉(zhuǎn)換方式的集合。在StoryBoard中不僅可以看到每個(gè)ViewController的布局樣式，也可以明確地知道各個(gè)ViewController之間的轉(zhuǎn)換關(guān)系。相對(duì)于單個(gè)的xib，其代碼需求更少，也由于集合了各個(gè)xib，使得對(duì)于界面的理解和修改的速度也得到了更大提升。減少代碼量就是減少bug量，這也是程序開發(fā)中的真理之一。

在Xcode5之后，StoryBoard已經(jīng)成為新建項(xiàng)目的默認(rèn)配置，這也代表了Apple對(duì)開發(fā)者的建議和未來(lái)的方向。WWDC2013的各個(gè)Sample Code中也基本都使用了StoryBoard來(lái)進(jìn)行演示。可以預(yù)見到，之后Apple必定會(huì)在這方面進(jìn)行繼續(xù)強(qiáng)化，而反之純代碼或者單個(gè)xib的方式很可能不會(huì)再得到增強(qiáng)。

如果不考慮iOS版本的支持（其實(shí)說(shuō)實(shí)話現(xiàn)在已經(jīng)很少還見到要從iOS4開始支持的app了吧），現(xiàn)在StoryBoard面臨的最大問題就是多人協(xié)作。因?yàn)樗械腢I都定義在一個(gè)文件中，因此很多開發(fā)者個(gè)人或企業(yè)的技術(shù)負(fù)責(zé)人認(rèn)為StoryBoard是無(wú)法進(jìn)行協(xié)作開發(fā)的，其實(shí)這更多的是一種對(duì)StoryBoard的陌生所造成的誤解。雖然Apple并沒有在WWDC明確提及，但是沒有人規(guī)定整個(gè)項(xiàng)目只能有一個(gè)StoryBoard文件。一種可行的做法是將項(xiàng)目的不同部分分解成若干個(gè)StoryBoard，并安排開發(fā)人員對(duì)自己的部分進(jìn)行負(fù)責(zé)。簡(jiǎn)單舉例比如一個(gè)有4個(gè)tab功能相互獨(dú)立的基于UITabBarViewController的應(yīng)用，完全可以使用4個(gè)StoryBoard來(lái)分別代表4個(gè)tab，并在相互無(wú)干擾的情況下完成開發(fā)。這樣一來(lái)就不會(huì)存在所謂的沖突問題了。StoryBoard的API是如此簡(jiǎn)單，現(xiàn)在的SDK中一共方法數(shù)量一只手就能數(shù)過來(lái)，所以具體方法在這里就不再羅嗦了。

StoryBoard的另外的挑戰(zhàn)來(lái)源于ViewController的重用和自定義的view的處理。對(duì)于前者，在正確封裝接口以及良好設(shè)計(jì)的基礎(chǔ)上，其實(shí)StoryBoard的VC重用與代碼的VC重用是沒有本質(zhì)區(qū)別的，在StoryBoard中添加封裝良好需要重用的Scene即可解決。而對(duì)于后者，因?yàn)镾toryBoard中已經(jīng)不允許有單個(gè)view的存在，因此很多時(shí)候我們還是需要借助于單個(gè)的xib來(lái)自定義UI。這一點(diǎn)可以說(shuō)是由于StoryBoard的設(shè)計(jì)思路所造成的，StoryBoard更強(qiáng)調(diào)的是一種層次結(jié)構(gòu)，是在全局的視角上來(lái)組織UI設(shè)計(jì)和遷移。而對(duì)于單個(gè)的view，更多的會(huì)注重于重用和定制，而與整個(gè)項(xiàng)目的流程沒有太大關(guān)系。相信抓住這一要點(diǎn)，就能很好地了解什么時(shí)候使用xib，什么時(shí)候使用StoryBoard。

關(guān)于StoryBoard最后要說(shuō)的是，現(xiàn)在會(huì)有一些對(duì)于StoryBoard性能上的擔(dān)憂。因?yàn)橄鄬?duì)于單個(gè)xib來(lái)說(shuō)，StoryBoard文件往往更大，加載速度也相應(yīng)變慢。但是其實(shí)隨著現(xiàn)在設(shè)備的更新?lián)Q代，在iPhone4都難覓的今天，這點(diǎn)性能上的差距幾乎可以忽略了。而再之后的設(shè)備，不論讀取還是解析，只會(huì)越來(lái)越快。所以性能上的問題完全是沒有擔(dān)心的必要的。

我的觀點(diǎn)和選擇

我入門的時(shí)候是使用xib的，因?yàn)槟菚r(shí)候還沒有StoryBoard，而我也不是喜歡代碼的學(xué)院派Geek。到現(xiàn)在，三種方式我都有嘗試過，并分別得到了一些可能還并不是特別深刻體會(huì)。對(duì)于現(xiàn)在的我來(lái)說(shuō)，xib是我的奶酪，也是我在自己的一些項(xiàng)目里一直使用的方式，我可以在極短短時(shí)間內(nèi)用xib架起一套包括自定義要素和良好部件重用性復(fù)雜UI。但是在我嘗試了幾次使用StoryBoard制作demo之后，我已經(jīng)決定在之后的項(xiàng)目轉(zhuǎn)向使用StoryBoard。一方面因?yàn)榇_實(shí)是未來(lái)方向（每次新工程刪StoryBoard很討厭..），現(xiàn)在的StoryBoard專有的preview功能，以及之后AutoLayout的進(jìn)一步改進(jìn)等都很值得期待；另一方面也覺得奶酪放一個(gè)地方太久了會(huì)不好，趁著iOS7的大變革，也更新一下自己的觀念和方式，把奶酪換個(gè)地方擺擺，也許會(huì)對(duì)以后大有裨益。

對(duì)于初心者來(lái)說(shuō)，我并不建議上手就直接使用代碼來(lái)進(jìn)行UI制作和布局，因?yàn)槿唛L(zhǎng)的UI代碼確實(shí)非常乏味無(wú)趣。盡快看到成品，至少盡快看到原型，是保持興趣，繼續(xù)深入和從事職業(yè)的有效動(dòng)力。所以如果有可能有條件，在老鳥的指導(dǎo)下選擇StoryBoard來(lái)進(jìn)行快速構(gòu)建（或者如果是單個(gè)人開發(fā)的話，可以不用考慮多個(gè)StoryBoard協(xié)作，就更容易），會(huì)是入門的好選擇。而最新的教程和文檔已經(jīng)開始逐漸偏向StoryBoard，關(guān)于StoryBoard的問題在SO上關(guān)注度也會(huì)更高，這樣在入門時(shí)會(huì)有更多的資料可以進(jìn)行參考。

這并不是說(shuō)不需要關(guān)心代碼UI或者xib，因?yàn)槭褂肧toryBoard的時(shí)候在只能使用代碼以及自定義單個(gè)view時(shí)，還是不可避免地需要接觸它們的。這里想給的一點(diǎn)建議就是，雖然你不依賴代碼來(lái)進(jìn)行UI制作，但是了解并掌握如何使用純代碼來(lái)從頭構(gòu)建UI還是非常必要的：包括從新建Window開始，到初始化ViewController，添加必要的view，設(shè)定它們的property，以及添加和處理它們的各種響應(yīng)及responser鏈等內(nèi)容。現(xiàn)在iOS開發(fā)入門非常容易，Xcode和xib/StoryBoard幫助開發(fā)者隱藏了太多的細(xì)節(jié)，但是很多時(shí)候如果你不明白u(yù)nderhood到底是些什么，為什么這些xib/StoryBoard會(huì)這樣運(yùn)作的話，經(jīng)常會(huì)出現(xiàn)卡在一些很可笑的和初級(jí)的bug上找不著北，這其實(shí)會(huì)是對(duì)時(shí)間的巨大浪費(fèi)，很不值得。

一些IB小技巧

最后分享一些IB使用上的小技巧作為結(jié)束吧。其中很多方法也可以用在StoryBoard上，所以在向我自己之前xib使用者生涯致敬的同時(shí)，也算是一點(diǎn)小的備忘總結(jié)吧。

同時(shí)添加多個(gè)outlet

在IB中，選中一個(gè)view并右鍵點(diǎn)擊，將會(huì)出現(xiàn)灰色的HUD，可以在其上方便地拖拉或設(shè)定事件和outlet。你可以同時(shí)打開多個(gè)這樣的面板來(lái)一次性添加所有outlet。右鍵點(diǎn)擊面板，隨便拖動(dòng)一下面板，然后再打開另一個(gè)。你會(huì)發(fā)現(xiàn)前一個(gè)面板也留下來(lái)了，這樣你就可以方便地進(jìn)行拖拽設(shè)定了。

當(dāng)然，對(duì)于成組和行為類似的IBOutlet，應(yīng)該直接使用IBOutletCollection來(lái)進(jìn)行處理會(huì)更方便。

可視化坐標(biāo)距離

IB最煩人的問題就是對(duì)其。用代碼的時(shí)候我們可以明確地指定x,y坐標(biāo)，但是換到IB的時(shí)候我們更多的時(shí)候是靠拖拽UIView來(lái)布局。比如需要三個(gè)間隔相同的label，除了用強(qiáng)大的肉眼來(lái)估測(cè)距離是否相等以外，難道只能乖乖分別選中三個(gè)label，記下它們的坐標(biāo)然后打開計(jì)算器來(lái)做加減法么？

顯然不要那么笨，試試看選中一個(gè)label，然后按住option鍵并將鼠標(biāo)移動(dòng)到其他label上試試？你可以發(fā)現(xiàn)view之間的距離都以很容易理解的方式顯示出來(lái)了。不僅是同層次的view，被選中view與其他層次的view之間的距離關(guān)系也可以同樣顯示。

在一組view層次中進(jìn)行選擇

對(duì)于一些復(fù)雜的view層級(jí)關(guān)系，我們往往直接在IB中選擇會(huì)比較困難。比如view相互覆蓋時(shí)，我們很難甚至不能在編輯視圖中選中底層的view。這時(shí)候一般的做法是打開左側(cè)的view層級(jí)面板，一層層展開然后選擇自己需要的view。其實(shí)我們也有更簡(jiǎn)單的方法：按住Cmd和Shift，然后在需要選擇的view上方按右鍵，就可以列出在點(diǎn)擊位置上所有的view的列表。藉此就可以方便快速地選中想要的view了。

添加輔助線

這么高大上的技巧必須放在最后啊...在左邊的層級(jí)列表中雙擊某個(gè)view，然后Cmd+_或者Cmd+|即可在選中的view上添加一條水平或者垂直中心的輔助線。當(dāng)然這個(gè)輔助線是可以隨意移動(dòng)的。如果干過設(shè)計(jì)的同學(xué)肯定明白這個(gè)的意義了，在之后的對(duì)其和設(shè)計(jì)變更的時(shí)候都有重要的參考價(jià)值。

?

轉(zhuǎn)自：http://onevcat.com/2013/12/code-vs-xib-vs-storyboard/

轉(zhuǎn)載于:https://www.cnblogs.com/W-Kr/p/5191477.html

總結(jié)

以上是生活随笔為你收集整理的关于代码手写UI，xib和StoryBoard的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。