在開發(fā)一個 iOS 應(yīng)用之前，我們一定會問這樣一個問題：我應(yīng)該用哪種方式搭建界面呢残腌，代碼手寫烁登，Xib 還是 Storyboard。當我們手握好幾個工具的時候易阳，很容易犯選擇困難癥附较。即使是一個合作默契的團隊潦俺，成員們也難免有不同的偏好拒课，難以形成一致的結(jié)論事示。所以我們有必要去探索每個工具的優(yōu)缺點和各自最適合的場景，以期得出一些最佳實踐肖爵，提高開發(fā)效率和應(yīng)用質(zhì)量卢鹦。
代碼手寫
有一類程序員特別喜歡用代碼控制一切。他們覺得既然 Xibs 和 Storyboards 能做和不能做的都能通過代碼手寫完成劝堪，那為什么還要多依賴一個工具呢。直接代碼手寫不是更專注更高效嗎秒啦。還好我不屬于這類狂熱分子，所以我能更客觀地看待余境。
優(yōu)點
- 開發(fā)者能更好的理解背后發(fā)生了什么驻呐，也擁有更多的控制權(quán)，所以 Xibs 和 Storyboard 完不成的通過代碼一定能完成芳来。
- 多人合作時在版本控制上的優(yōu)勢含末，即使發(fā)生了合并沖突即舌，因為是純代碼，所以更易于手動解決侥涵。也便于追蹤改動宋雏。
- 有很好的重用性。有時候需要封裝一些控件在項目里多處使用或提供給其它開發(fā)者使用嗦明，用代碼手寫是最好的方式，同時也便于后續(xù)的修改娶牌。
缺點
- 速度慢，效率低诗良。代碼手寫意味著所有的初始化設(shè)置都需要自己寫，勢必花費更多時間鉴裹。另外由于無法可視化地為 UI 元素布局，在開發(fā)過程中也會浪費很多時間在調(diào)試上督禽。
- 增加了維護難度。也許過了一段時間再看所寫的代碼或是新來的成員要讀代碼总处，都有可能被那些詭異的數(shù)字給弄懵的。
Xibs
在我剛開始學(xué)習(xí) iOS 開發(fā)的時候鹦马，還好有 Xib 可以選擇。通過拖拽就能將各種控件擺放在正確的位置第岖，在觸摸板上點點就能設(shè)置各種屬性试溯，這種可視化的方式無疑讓我很有興趣繼續(xù)學(xué)習(xí)去蔑滓。但和代碼手寫一樣，各有優(yōu)缺點遇绞。
優(yōu)點
- 可視化键袱，包括添加控件和設(shè)置屬性摹闽，配置 IBOutlet 和 IBAction，支持 Autolayout付鹿，支持 Size classes。因此能夠快速搭建界面俊抵，減少代碼坐梯，省下大量開發(fā)和調(diào)試的時間。也使得 ViewController 可以更少地關(guān)注搭建 UI 的事。
- 重用性偷溺。通常是一個 Xib 文件對應(yīng)一個 ViewController钱贯，如果多個 ViewController 用到相同的元素組合，那我們就可以把這部分提出來放到專門的 Xib 文件里喷舀，用一個自定義的 View 去管理它們。比如會被重用的自定義的 TableViewCell 也會這么處理爸邢。
缺點
- 多人協(xié)作時版本控制上的劣勢拿愧，合并沖突時不易處理。雖然在 Xcode5 之后 Apple 優(yōu)化了 xib 文件的格式浇辜，變得更易讀易追蹤，但還是不如純代碼那么容易處理待诅。
- 無法完成一些更復(fù)雜的熊镣，動態(tài)的布局卑雁。通常需要在 xib 中先設(shè)置好 Autolayout 約束绪囱，再在代碼中做一些動態(tài)的處理。
- Xib 中屬性設(shè)置可以被覆蓋扣甲，導(dǎo)致在后期維護中面對一些詭異的界面問題時卻無法快速的找出原因齿椅。這點需要我們在開發(fā)過程中約定好盡量不要在代碼中修改屬性。
Storyboards
Apple 從 Xcode5 開始將 Storyboard 作為新建項目的默認配置涣脚，可見它強力推廣 Storyboard 的決心。Storyboard 顧名思義，重點在于將多個場景關(guān)聯(lián)起來展示一個連貫的故事。在 Xcode 里射富，可以看成把一組 ViewController 對應(yīng)的 Xib 文件放到一個文件中粥帚，并配置好它們之間的轉(zhuǎn)場方式。所以 Storyboard 和 Xib 的優(yōu)缺點會有重合芒涡。
優(yōu)點
- 可視化，除了前面 Xib 那段中提到的快速搭建界面意外赠群，Storyboard 還增加了各個 ViewController 之間的轉(zhuǎn)場關(guān)系旱幼，使得開發(fā)者尤其是新加入的開發(fā)者能更容易更清晰的整理整個應(yīng)用的流程和交互“芈保基于這一點我們甚至還可以不寫代碼直接拿來做簡單的原型設(shè)計。
- 支持在 TableView 中直接添加 Cell勾笆，包括動態(tài)和靜態(tài)兩種類型桥滨。當一個 TableView 有很多不同樣式的 Cell窝爪， 或者是固定的 Section 和 Cell 的時候该园，這個特性會提供很大的便利。
缺點
- 文件大啃勉，加載慢双妨。一般情況下很容易會把所有的 ViewController 放在同一個 Storyboard 里，導(dǎo)致文件很大刁品，打開的時候需要加載幾十秒∽茨可嘗試拆分 Storyboard 緩解這個癥狀。
- 多人協(xié)作時容易產(chǎn)生合并沖突膏孟。一方面多個成員可能對同一個 Storyboard 進行修改，另一個方面 Xcode 在打開文件的時候可能會根據(jù)版本自動做一些修改弊决，這些都給合并代碼制造了麻煩魁淳。可通過拆分 Storyboard 達到每個成員只負責其中一個
- 不能單獨存在自定義的 View界逛。因為 Storyboard 更強調(diào) ViewController 之間的關(guān)系，也就是整體的流程貌嫡，所以不允許單個 View 的存在该溯。這也是 Xib 文件該跳出承擔責任的時候了。
- 觸發(fā) Segue 和數(shù)據(jù)傳遞的分裂狈茉。有時候我們需要在 ViewController 之間傳遞數(shù)據(jù)，但是如果用常規(guī)的 Storyboard 的流程的話需要先通過
performSegueWithIdentifier:sender:觸發(fā)然后再在prepareForSegue:sender:方法中獲得目標 ViewController 再對其屬性進行賦值蹭秋。使得本應(yīng)該連貫的過程被分裂了堤撵。
總結(jié)
在了解了每種方式的優(yōu)缺點后仁讨，我們才可以根據(jù)不同的應(yīng)用場景選擇更合適的方法实昨。在這個問題中，這幾個選項不是排他的丈挟，而是可以相互合作來提升開發(fā)效率和應(yīng)用質(zhì)量志电。
總體來說可以根據(jù)應(yīng)用的規(guī)模來決策：
- 小型：請毫不猶豫地使用 Storyboard 吧√袅荆可視化孝情，速度快洒嗤。把所有界面都放在一起，讓人有一種君臨天下的感覺。
- 中型：主體用 Storyboard吉挣，一些需要重用的 View 用單獨的 Xib，比如 TableViewCell终吼。
- 大型：將應(yīng)用分成不同的模塊氯哮，每一個模塊用一個單獨的 Storyboard际跪。比如基于
UITabBarViewController的應(yīng)用可以按照 Tab 來分成若干個 Storyboard。Apple 還在 iOS 9 引入了 Storyboard references 幫助開發(fā)者重構(gòu)以獲得更好的模塊化姆打。
另外肠虽，代碼手寫的方法也不是沒有用用武之地，那些布局復(fù)雜闲延，動態(tài)性高的 View 更適合通過代碼來搭建。
最后再說一句垒玲，隨著現(xiàn)代 IDE 的發(fā)展找颓，越來越多的底層實現(xiàn)細節(jié)被隱藏起來，但作為開發(fā)者叮雳，我們還是有必要去探索背后的真理，才能更從容地面對各種意料之外的問題说莫。
