最近接觸了幾個(gè)剛?cè)腴T的iOS學(xué)習(xí)者，他們之中存在一個(gè)普遍和困惑和疑問，就是應(yīng)該如何制作UI界面。iOS應(yīng)用是非常重視用戶體驗(yàn)的，可以說絕大多數(shù)的應(yīng)用成功與否與交互設(shè)計(jì)以及UI是否漂亮易用有著非常大的關(guān)系。而隨著iOS開發(fā)發(fā)展至今，可以說在UI制作上大家逐漸分化為了三種主要流派：使用代碼手寫UI及布局；使用單個(gè)xib文件組織viewController或者view；使用StoryBoard來通過單個(gè)或很少的幾個(gè)（關(guān)于這點(diǎn)稍后會進(jìn)行展開）文件構(gòu)建全部UI。應(yīng)該使用哪種方式來制作UI已經(jīng)是iOS開發(fā)中亙古不變的爭論話題了，或許永遠(yuǎn)不會有一個(gè)統(tǒng)一的結(jié)論。但是首先需要知道的是三種方式各有優(yōu)劣，所以也各有自己最適用的場合，而不會有完全的孰優(yōu)孰劣。對于初學(xué)iOS開發(fā)來說，一時(shí)間其實(shí)是很難判定最適合自己的UI架構(gòu)方式的。在這篇文章里我希望能夠通過自己的經(jīng)驗(yàn)給出一些意見，以期能幫助入門者來挑選最適合自己應(yīng)用場景的方案。對于老鳥的話，也不妨對照自己平日的使用習(xí)慣和運(yùn)用場景，看看有沒有可以改進(jìn)或變化的地方。最后，因?yàn)槲冶救爽F(xiàn)在最習(xí)慣和喜歡的是用Interface Builder(之后簡稱IB)及xib來做UI，所以文末附上了一些IB使用時(shí)候的小技巧，算是做個(gè)總結(jié)。代碼手寫UI這種方法經(jīng)常被學(xué)院派的極客或者依賴多人合作的大型項(xiàng)目大規(guī)模使用。Geek們喜歡用代碼構(gòu)建UI，是因?yàn)榇a是鍵盤敲出來的，這樣可以做到不開IB，手不離開鍵盤就完成工作，可以專注于編碼環(huán)境，看起來很cool很高效，而且不到運(yùn)行時(shí)大家都不知道會是什么樣子，也顯出了程序員這一職業(yè)的高大上及神秘氣息（這個(gè)真的不是在黑..想想大家一起在設(shè)計(jì)師背后指點(diǎn)江山的場景吧）。大型多人合作項(xiàng)目使用代碼構(gòu)建UI，主要是看中純代碼在版本管理時(shí)的優(yōu)勢，檢查追蹤改動(dòng)以及進(jìn)行代碼合并相對容易一些。 另外，代碼UI可以說具有最好的代碼重用性。如果你的目的是寫一些可以高度重用的控件提供給其他開發(fā)者使用，那毫無疑問最好的選擇應(yīng)該是使用代碼來完成UIView的子類。這樣進(jìn)一步的修改和其他開發(fā)者在使用時(shí)，都會方便不少。使用代碼也是最為強(qiáng)大的，會有xib或者StoryBoard做不了的事情，但是使用代碼最終一定能夠完成所要的需求。
但是代碼手寫UI的劣勢同時(shí)也是最明顯的，主要就是一個(gè)字：慢。首先相比可視化的IB來說，完成一個(gè)并不太復(fù)雜的界面，你可能需要寫上數(shù)百行的UI代碼。不論是初始化一個(gè)Label，還是設(shè)定一個(gè)frame或者添加一個(gè)target-action，都需要寫代碼，這不僅在前期極為浪費(fèi)時(shí)間，在之后維護(hù)時(shí)代碼定位和尋找也會很痛苦。其次，因?yàn)槟銦o法直觀地看到你能得到的結(jié)果，所以你很可能需要不斷地 Xibs相對于代碼，使用IB和xib文件來組織UI，可以省下大量代碼和時(shí)間，從而得到更快的開發(fā)速度。如果你曾經(jīng)受到過微軟家Visual Basic或者其他Visual系的可視化界面的荼毒與殘害，因此懷疑Interface Builder的純正血統(tǒng)和工作能力，建議可以看看這些資料以糾正三觀：Jean-Marie Hullot的Interface Builder神話以及西裝革履的青澀喬幫主在NeXT時(shí)親手用IB構(gòu)建應(yīng)用（需要翻墻）。另外，不妨打開你的Mac上的Application文件夾中或者iPhone上Apple家的各種應(yīng)用。你會驚奇地發(fā)現(xiàn)，IB遠(yuǎn)比你看到的要強(qiáng)大：小至計(jì)算器取色器這類小工具，大至iWork三件套，Aperture或Final Cut這樣的專業(yè)級應(yīng)用，無一不是使用IB來完成UI制作的。 其實(shí)IB和xib是從iOS SDK初次面世開始就是捆綁在開發(fā)者工具套裝內(nèi)的內(nèi)容了，而到了Xcode 4之后更被直接集成到了Xcode中成為了IDE的一部分。xib設(shè)計(jì)的一大目的其實(shí)是為了良好的MVC：一般來說，單個(gè)的xib文件對應(yīng)一個(gè)ViewController，而對于一些自定義的view，往往也會使用單個(gè)xib并從main bundle進(jìn)行加載的方式來載入。IB幫助完成view的創(chuàng)建，布局和與file owner的關(guān)系映射等一些列工作。對于初學(xué)者來說，牢記xib的文件都是view的內(nèi)容，有助于建立起較好的MVC的概念，從而在開發(fā)中避免或少走彎路。 xib文件之前一大被詬病的問題是文件內(nèi)容過于復(fù)雜，可讀性很差，即使只是簡單打開沒有編輯也有可能造成變化而導(dǎo)致合并和提交的苦難。在Xcode 5中Apple大幅簡化了xib文件的格式，使其變得易讀易維護(hù)。可以說現(xiàn)在對于xib文件在版本管理上其實(shí)和純代碼已經(jīng)沒有太大差異，只要仔細(xì)看過一遍xib的文件內(nèi)容，自然能理解絕大部分，并很好地追蹤并查找過往的修改記錄了。 當(dāng)然xib也不是完美的。最大的問題在于xib中的設(shè)置往往并非最終設(shè)置，在代碼中你將有機(jī)會覆蓋你在xib文件中進(jìn)行的UI設(shè)計(jì)。在不同的地方對同一個(gè)屬性進(jìn)行設(shè)置，這在之后的維護(hù)中將會是噩夢般的存在。因?yàn)槠鋵?shí)IB還是有所局限的，它沒有邏輯判斷，也很難在運(yùn)行時(shí)進(jìn)行配置，而反之使用代碼確是無所不能的。在使用xib時(shí)，輔以部分代碼來補(bǔ)充和完成功能幾乎是不可避免的。關(guān)于這點(diǎn)在開發(fā)時(shí)應(yīng)該予以高度重視，如果選擇xib，那么要盡量將xib的工作和代碼的工作隔離開來：能夠使用xib完成的內(nèi)容就統(tǒng)一使用xib來做，而不要說三個(gè)Label其中兩個(gè)在xib設(shè)置了字體而另一個(gè)卻在代碼中完成。盡量僅保持必要的、較少的IBOutlet和IBAction會是一個(gè)好方法。 StoryBoardiOS5之后Apple提供了一種全新的方式來制作UI，那就是StoryBoard。簡單理解來說，可以把StoryBoard看做是一組viewController對應(yīng)的xib，以及它們之間的轉(zhuǎn)換方式的集合。在StoryBoard中不僅可以看到每個(gè)ViewController的布局樣式，也可以明確地知道各個(gè)ViewController之間的轉(zhuǎn)換關(guān)系。相對于單個(gè)的xib，其代碼需求更少，也由于集合了各個(gè)xib，使得對于界面的理解和修改的速度也得到了更大提升。減少代碼量就是減少bug量，這也是程序開發(fā)中的真理之一。 在Xcode5之后，StoryBoard已經(jīng)成為新建項(xiàng)目的默認(rèn)配置，這也代表了Apple對開發(fā)者的建議和未來的方向。WWDC2013的各個(gè)Sample Code中也基本都使用了StoryBoard來進(jìn)行演示?？梢灶A(yù)見到，之后Apple必定會在這方面進(jìn)行繼續(xù)強(qiáng)化，而反之純代碼或者單個(gè)xib的方式很可能不會再得到增強(qiáng)。 如果不考慮iOS版本的支持（其實(shí)說實(shí)話現(xiàn)在已經(jīng)很少還見到要從iOS4開始支持的app了吧），現(xiàn)在StoryBoard面臨的最大問題就是多人協(xié)作。因?yàn)樗械腢I都定義在一個(gè)文件中，因此很多開發(fā)者個(gè)人或企業(yè)的技術(shù)負(fù)責(zé)人認(rèn)為StoryBoard是無法進(jìn)行協(xié)作開發(fā)的，其實(shí)這更多的是一種對StoryBoard的陌生所造成的誤解。雖然Apple并沒有在WWDC明確提及，但是沒有人規(guī)定整個(gè)項(xiàng)目只能有一個(gè)StoryBoard文件。一種可行的做法是將項(xiàng)目的不同部分分解成若干個(gè)StoryBoard，并安排開發(fā)人員對自己的部分進(jìn)行負(fù)責(zé)。簡單舉例比如一個(gè)有4個(gè)tab功能相互獨(dú)立的基于UITabBarViewController的應(yīng)用，完全可以使用4個(gè)StoryBoard來分別代表4個(gè)tab，并在相互無干擾的情況下完成開發(fā)。這樣一來就不會存在所謂的沖突問題了。StoryBoard的API是如此簡單，現(xiàn)在的SDK中一共方法數(shù)量一只手就能數(shù)過來，所以具體方法在這里就不再羅嗦了。 StoryBoard的另外的挑戰(zhàn)來源于ViewController的重用和自定義的view的處理。對于前者，在正確封裝接口以及良好設(shè)計(jì)的基礎(chǔ)上，其實(shí)StoryBoard的VC重用與代碼的VC重用是沒有本質(zhì)區(qū)別的，在StoryBoard中添加封裝良好需要重用的Scene即可解決。而對于后者，因?yàn)镾toryBoard中已經(jīng)不允許有單個(gè)view的存在，因此很多時(shí)候我們還是需要借助于單個(gè)的xib來自定義UI。這一點(diǎn)可以說是由于StoryBoard的設(shè)計(jì)思路所造成的，StoryBoard更強(qiáng)調(diào)的是一種層次結(jié)構(gòu)，是在全局的視角上來組織UI設(shè)計(jì)和遷移。而對于單個(gè)的view，更多的會注重于重用和定制，而與整個(gè)項(xiàng)目的流程沒有太大關(guān)系。相信抓住這一要點(diǎn)，就能很好地了解什么時(shí)候使用xib，什么時(shí)候使用StoryBoard。 關(guān)于StoryBoard最后要說的是，現(xiàn)在會有一些對于StoryBoard性能上的擔(dān)憂。因?yàn)橄鄬τ趩蝹€(gè)xib來說，StoryBoard文件往往更大，加載速度也相應(yīng)變慢。但是其實(shí)隨著現(xiàn)在設(shè)備的更新?lián)Q代，在iPhone4都難覓的今天，這點(diǎn)性能上的差距幾乎可以忽略了。而再之后的設(shè)備，不論讀取還是解析，只會越來越快。所以性能上的問題完全是沒有擔(dān)心的必要的。 我的觀點(diǎn)和選擇我入門的時(shí)候是使用xib的，因?yàn)槟菚r(shí)候還沒有StoryBoard，而我也不是喜歡代碼的學(xué)院派Geek。到現(xiàn)在，三種方式我都有嘗試過，并分別得到了一些可能還并不是特別深刻體會。對于現(xiàn)在的我來說，xib是我的奶酪，也是我在自己的一些項(xiàng)目里一直使用的方式，我可以在極短短時(shí)間內(nèi)用xib架起一套包括自定義要素和良好部件重用性復(fù)雜UI。但是在我嘗試了幾次使用StoryBoard制作demo之后，我已經(jīng)決定在之后的項(xiàng)目轉(zhuǎn)向使用StoryBoard。一方面因?yàn)榇_實(shí)是未來方向（每次新工程刪StoryBoard很討厭..），現(xiàn)在的StoryBoard專有的preview功能，以及之后AutoLayout的進(jìn)一步改進(jìn)等都很值得期待；另一方面也覺得奶酪放一個(gè)地方太久了會不好，趁著iOS7的大變革，也更新一下自己的觀念和方式，把奶酪換個(gè)地方擺擺，也許會對以后大有裨益。 對于初心者來說，我并不建議上手就直接使用代碼來進(jìn)行UI制作和布局，因?yàn)槿唛L的UI代碼確實(shí)非常乏味無趣。盡快看到成品，至少盡快看到原型，是保持興趣，繼續(xù)深入和從事職業(yè)的有效動(dòng)力。所以如果有可能有條件，在老鳥的指導(dǎo)下選擇StoryBoard來進(jìn)行快速構(gòu)建（或者如果是單個(gè)人開發(fā)的話，可以不用考慮多個(gè)StoryBoard協(xié)作，就更容易），會是入門的好選擇。而最新的教程和文檔已經(jīng)開始逐漸偏向StoryBoard，關(guān)于StoryBoard的問題在SO上關(guān)注度也會更高，這樣在入門時(shí)會有更多的資料可以進(jìn)行參考。 這并不是說不需要關(guān)心代碼UI或者xib，因?yàn)槭褂肧toryBoard的時(shí)候在只能使用代碼以及自定義單個(gè)view時(shí)，還是不可避免地需要接觸它們的。這里想給的一點(diǎn)建議就是，雖然你不依賴代碼來進(jìn)行UI制作，但是了解并掌握如何使用純代碼來從頭構(gòu)建UI還是非常必要的：包括從新建Window開始，到初始化ViewController，添加必要的view，設(shè)定它們的property，以及添加和處理它們的各種響應(yīng)及responser鏈等內(nèi)容?，F(xiàn)在iOS開發(fā)入門非常容易，Xcode和xib/StoryBoard幫助開發(fā)者隱藏了太多的細(xì)節(jié)，但是很多時(shí)候如果你不明白u(yù)nderhood到底是些什么，為什么這些xib/StoryBoard會這樣運(yùn)作的話，經(jīng)常會出現(xiàn)卡在一些很可笑的和初級的bug上找不著北，這其實(shí)會是對時(shí)間的巨大浪費(fèi)，很不值得。 一些IB小技巧最后分享一些IB使用上的小技巧作為結(jié)束吧。其中很多方法也可以用在StoryBoard上，所以在向我自己之前xib使用者生涯致敬的同時(shí)，也算是一點(diǎn)小的備忘總結(jié)吧。 同時(shí)添加多個(gè)outlet在IB中，選中一個(gè)view并右鍵點(diǎn)擊，將會出現(xiàn)灰色的HUD，可以在其上方便地拖拉或設(shè)定事件和outlet。你可以同時(shí)打開多個(gè)這樣的面板來一次性添加所有outlet。右鍵點(diǎn)擊面板，隨便拖動(dòng)一下面板，然后再打開另一個(gè)。你會發(fā)現(xiàn)前一個(gè)面板也留下來了，這樣你就可以方便地進(jìn)行拖拽設(shè)定了。
當(dāng)然，對于成組和行為類似的IBOutlet，應(yīng)該直接使用IBOutletCollection來進(jìn)行處理會更方便。 可視化坐標(biāo)距離IB最煩人的問題就是對其。用代碼的時(shí)候我們可以明確地指定x,y坐標(biāo)，但是換到IB的時(shí)候我們更多的時(shí)候是靠拖拽UIView來布局。比如需要三個(gè)間隔相同的label，除了用強(qiáng)大的肉眼來估測距離是否相等以外，難道只能乖乖分別選中三個(gè)label，記下它們的坐標(biāo)然后打開計(jì)算器來做加減法么？ 顯然不要那么笨，試試看選中一個(gè)label，然后按住option鍵并將鼠標(biāo)移動(dòng)到其他label上試試？你可以發(fā)現(xiàn)view之間的距離都以很容易理解的方式顯示出來了。不僅是同層次的view，被選中view與其他層次的view之間的距離關(guān)系也可以同樣顯示。
在一組view層次中進(jìn)行選擇
對于一些復(fù)雜的view層級關(guān)系，我們往往直接在IB中選擇會比較困難。比如view相互覆蓋時(shí)，我們很難甚至不能在編輯視圖中選中底層的view。這時(shí)候一般的做法是打開左側(cè)的view層級面板，一層層展開然后選擇自己需要的view。其實(shí)我們也有更簡單的方法：按住
添加輔助線
這么高大上的技巧必須放在最后啊...在左邊的層級列表中雙擊某個(gè)view，然后
|
|
|
