在開發(fā)一個(gè) iOS 應(yīng)用之前，我們一定會(huì)問這樣一個(gè)問題：我應(yīng)該用哪種方式搭建界面呢，代碼手寫，Xib 還是 Storyboard。當(dāng)我們手握好幾個(gè)工具的時(shí)候，很容易犯選擇困難癥。即使是一個(gè)合作默契的團(tuán)隊(duì)，成員們也難免有不同的偏好，難以形成一致的結(jié)論。所以我們有必要去探索每個(gè)工具的優(yōu)缺點(diǎn)和各自最適合的場景，以期得出一些最佳實(shí)踐，提高開發(fā)效率和應(yīng)用質(zhì)量。

代碼手寫

有一類程序員特別喜歡用代碼控制一切。他們覺得既然 Xibs 和 Storyboards 能做和不能做的都能通過代碼手寫完成，那為什么還要多依賴一個(gè)工具呢。直接代碼手寫不是更專注更高效嗎。還好我不屬于這類狂熱分子，所以我能更客觀地看待。

優(yōu)點(diǎn)

• 開發(fā)者能更好的理解背后發(fā)生了什么，也擁有更多的控制權(quán)，所以 Xibs 和 Storyboard 完不成的通過代碼一定能完成。
• 多人合作時(shí)在版本控制上的優(yōu)勢，即使發(fā)生了合并沖突，因?yàn)槭羌兇a，所以更易于手動(dòng)解決。也便于追蹤改動(dòng)。
• 有很好的重用性。有時(shí)候需要封裝一些控件在項(xiàng)目里多處使用或提供給其它開發(fā)者使用，用代碼手寫是最好的方式，同時(shí)也便于后續(xù)的修改。

缺點(diǎn)

• 速度慢，效率低。代碼手寫意味著所有的初始化設(shè)置都需要自己寫，勢必花費(fèi)更多時(shí)間。另外由于無法可視化地為 UI 元素布局，在開發(fā)過程中也會(huì)浪費(fèi)很多時(shí)間在調(diào)試上。
• 增加了維護(hù)難度。也許過了一段時(shí)間再看所寫的代碼或是新來的成員要讀代碼，都有可能被那些詭異的數(shù)字給弄懵的。

Xibs

在我剛開始學(xué)習(xí) iOS 開發(fā)的時(shí)候，還好有 Xib 可以選擇。通過拖拽就能將各種控件擺放在正確的位置，在觸摸板上點(diǎn)點(diǎn)就能設(shè)置各種屬性，這種可視化的方式無疑讓我很有興趣繼續(xù)學(xué)習(xí)去。但和代碼手寫一樣，各有優(yōu)缺點(diǎn)。

優(yōu)點(diǎn)

• 可視化，包括添加控件和設(shè)置屬性，配置 IBOutlet 和 IBAction，支持 Autolayout，支持 Size classes。因此能夠快速搭建界面，減少代碼，省下大量開發(fā)和調(diào)試的時(shí)間。也使得 ViewController 可以更少地關(guān)注搭建 UI 的事。
• 重用性。通常是一個(gè) Xib 文件對(duì)應(yīng)一個(gè) ViewController，如果多個(gè) ViewController 用到相同的元素組合，那我們就可以把這部分提出來放到專門的 Xib 文件里，用一個(gè)自定義的 View 去管理它們。比如會(huì)被重用的自定義的 TableViewCell 也會(huì)這么處理。

缺點(diǎn)

• 多人協(xié)作時(shí)版本控制上的劣勢，合并沖突時(shí)不易處理。雖然在 Xcode5 之后 Apple 優(yōu)化了 xib 文件的格式，變得更易讀易追蹤，但還是不如純代碼那么容易處理。
• 無法完成一些更復(fù)雜的，動(dòng)態(tài)的布局。通常需要在 xib 中先設(shè)置好 Autolayout 約束，再在代碼中做一些動(dòng)態(tài)的處理。
• Xib 中屬性設(shè)置可以被覆蓋，導(dǎo)致在后期維護(hù)中面對(duì)一些詭異的界面問題時(shí)卻無法快速的找出原因。這點(diǎn)需要我們在開發(fā)過程中約定好盡量不要在代碼中修改屬性。

Storyboards

Apple 從 Xcode5 開始將 Storyboard 作為新建項(xiàng)目的默認(rèn)配置，可見它強(qiáng)力推廣 Storyboard 的決心。Storyboard 顧名思義，重點(diǎn)在于將多個(gè)場景關(guān)聯(lián)起來展示一個(gè)連貫的故事。在 Xcode 里，可以看成把一組 ViewController 對(duì)應(yīng)的 Xib 文件放到一個(gè)文件中，并配置好它們之間的轉(zhuǎn)場方式。所以 Storyboard 和 Xib 的優(yōu)缺點(diǎn)會(huì)有重合。

優(yōu)點(diǎn)

• 可視化，除了前面 Xib 那段中提到的快速搭建界面意外，Storyboard 還增加了各個(gè) ViewController 之間的轉(zhuǎn)場關(guān)系，使得開發(fā)者尤其是新加入的開發(fā)者能更容易更清晰的整理整個(gè)應(yīng)用的流程和交互?；谶@一點(diǎn)我們甚至還可以不寫代碼直接拿來做簡單的原型設(shè)計(jì)。
• 支持在 TableView 中直接添加 Cell，包括動(dòng)態(tài)和靜態(tài)兩種類型。當(dāng)一個(gè) TableView 有很多不同樣式的 Cell， 或者是固定的 Section 和 Cell 的時(shí)候，這個(gè)特性會(huì)提供很大的便利。

缺點(diǎn)

• 文件大，加載慢。一般情況下很容易會(huì)把所有的 ViewController 放在同一個(gè) Storyboard 里，導(dǎo)致文件很大，打開的時(shí)候需要加載幾十秒。可嘗試拆分 Storyboard 緩解這個(gè)癥狀。
• 多人協(xié)作時(shí)容易產(chǎn)生合并沖突。一方面多個(gè)成員可能對(duì)同一個(gè) Storyboard 進(jìn)行修改，另一個(gè)方面 Xcode 在打開文件的時(shí)候可能會(huì)根據(jù)版本自動(dòng)做一些修改，這些都給合并代碼制造了麻煩?？赏ㄟ^拆分 Storyboard 達(dá)到每個(gè)成員只負(fù)責(zé)其中一個(gè)
• 不能單獨(dú)存在自定義的 View。因?yàn)?Storyboard 更強(qiáng)調(diào) ViewController 之間的關(guān)系，也就是整體的流程，所以不允許單個(gè) View 的存在。這也是 Xib 文件該跳出承擔(dān)責(zé)任的時(shí)候了。
• 觸發(fā) Segue 和數(shù)據(jù)傳遞的分裂。有時(shí)候我們需要在 ViewController 之間傳遞數(shù)據(jù)，但是如果用常規(guī)的 Storyboard 的流程的話需要先通過 performSegueWithIdentifier:sender: 觸發(fā)然后再在 prepareForSegue:sender: 方法中獲得目標(biāo) ViewController 再對(duì)其屬性進(jìn)行賦值。使得本應(yīng)該連貫的過程被分裂了。

總結(jié)

在了解了每種方式的優(yōu)缺點(diǎn)后，我們才可以根據(jù)不同的應(yīng)用場景選擇更合適的方法。在這個(gè)問題中，這幾個(gè)選項(xiàng)不是排他的，而是可以相互合作來提升開發(fā)效率和應(yīng)用質(zhì)量。

總體來說可以根據(jù)應(yīng)用的規(guī)模來決策：

• 小型：請(qǐng)毫不猶豫地使用 Storyboard 吧?？梢暬?，速度快。把所有界面都放在一起，讓人有一種君臨天下的感覺。
• 中型：主體用 Storyboard，一些需要重用的 View 用單獨(dú)的 Xib，比如 TableViewCell。
• 大型：將應(yīng)用分成不同的模塊，每一個(gè)模塊用一個(gè)單獨(dú)的 Storyboard。比如基于 UITabBarViewController 的應(yīng)用可以按照 Tab 來分成若干個(gè) Storyboard。Apple 還在 iOS 9 引入了 Storyboard references 幫助開發(fā)者重構(gòu)以獲得更好的模塊化。

另外，代碼手寫的方法也不是沒有用用武之地，那些布局復(fù)雜，動(dòng)態(tài)性高的 View 更適合通過代碼來搭建。

最后再說一句，隨著現(xiàn)代 IDE 的發(fā)展，越來越多的底層實(shí)現(xiàn)細(xì)節(jié)被隱藏起來，但作為開發(fā)者，我們還是有必要去探索背后的真理，才能更從容地面對(duì)各種意料之外的問題。