Interface Builder的一些小技巧

　　最近接觸了幾個剛入門的iOS學習者，他們之中存在一個普遍和困惑和疑問，就是應該如何制作UI界面。iOS應用是非常重視用戶體驗的，可以說絕大多數的應用成功與否與交互設計以及UI是否漂亮易用有著非常大的關系。而隨著iOS開發發展至今，可以說在UI制作上大家逐漸分化為了三種主要流派：使用代碼手寫 UI及布局;使用單個xib文件組織viewController或者view;使用StoryBoard來通過單個或很少的幾個(關于這點稍后會進行展開)文件構建全部UI。應該使用哪種方式來制作UI已經是iOS開發中亙古不變的爭論話題了，或許永遠不會有一個統一的結論。但是首先需要知道的是三種方式各有優劣，所以也各有自己最適用的場合，而不會有完全的孰優孰劣。對于初學iOS開發來說，一時間其實是很難判定最適合自己的UI架構方式的。在這篇文章里我希望能夠通過自己的經驗給出一些意見，以期能幫助入門者來挑選最適合自己應用場景的方案。對于老鳥的話，也不妨對照自己平日的使用習慣和運用場景，看看有沒有可以改進或變化的地方。最后，因為我本人現在最習慣和喜歡的是用Interface Builder(之后簡稱IB)及xib來做UI，所以文末附上了一些IB使用時候的小技巧，算是做個總結。

　　代碼手寫UI

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

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

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

　　Xibs

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

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

　　xib文件之前一大被詬病的問題是文件內容過于復雜，可讀性很差，即使只是簡單打開沒有編輯也有可能造成變化而導致合并和提交的苦難。在Xcode 5中Apple大幅簡化了xib文件的格式，使其變得易讀易維護?？梢哉f現在對于xib文件在版本管理上其實和純代碼已經沒有太大差異，只要仔細看過一遍 xib的文件內容，自然能理解絕大部分，并很好地追蹤并查找過往的修改記錄了。

　　當然xib也不是完美的。最大的問題在于xib中的設置往往并非最終設置，在代碼中你將有機會覆蓋你在xib文件中進行的UI設計。在不同的地方對同一個屬性進行設置，這在之后的維護中將會是噩夢般的存在。因為其實IB還是有所局限的，它沒有邏輯判斷，也很難在運行時進行配置，而反之使用代碼確是無所不能的。在使用xib時，輔以部分代碼來補充和完成功能幾乎是不可避免的。關于這點在開發時應該予以高度重視，如果選擇xib，那么要盡量將xib的工作和代碼的工作隔離開來：能夠使用xib完成的內容就統一使用xib來做，而不要說三個Label其中兩個在xib設置了字體而另一個卻在代碼中完成。盡量僅保持必要的、較少的IBOutlet和IBAction會是一個好方法。

　　StoryBoard

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

　　在Xcode5之后，StoryBoard已經成為新建項目的默認配置，這也代表了Apple對開發者的建議和未來的方向。WWDC2013的各個 Sample Code中也基本都使用了StoryBoard來進行演示?？梢灶A見到，之后Apple必定會在這方面進行繼續強化，而反之純代碼或者單個xib的方式很可能不會再得到增強。

原文轉自：http://onevcat.com/2013/12/code-vs-xib-vs-storyboard/