從 iOS 5 的時代 Apple 推出 Storyboard (以下簡稱 SB) 后，關于使用這種方式構建 UI 的爭論就在 Cocoa 開發者社區里一直發生著。我在 2013 年寫過一篇關于代碼手寫 UI，xib 和 SB 之間的取舍的文章。在四五年后的今天，SB 得到了多次進化，大家也積攢了很多關于使用 SB 進行開發的經驗，我們不妨再回頭看看當初的憂慮，并結合 SB 開發的現狀，來提取一些現階段被認為比較好的實踐。
這篇文章緣起為對使用 SB 的方式一文 (及其英文原文) 的回應，我對其中部分意見有一些不同的看法。不過正如原文作者在后一段所說，你應該選擇適合自己的使用方式。所以我的意見或者說所謂的「好的實踐」，也只是從我自己的觀點出發所得到的結論。本文將首先對原文提出的幾個論點逐個分析，然后介紹一些我自己在日常使用 SB 時的經驗和方式。
反正關于 Storyboard 或者 Interface Builder 已經吵了那么多年了，也不在乎多這么一篇-。-
原文中有一個非常激進的觀點，那就是：
每個 SB 里只放一個 UIViewController
我無法贊同這個觀點。如果在 iOS 3 或者 4 時代有 xib 使用經驗的開發者會知道，這基本就是將 SB 倒退到 xib 的用法。原文中提到這么做的原因主要有三點：
- 減少兩個開發者同時開發一個 View Controller 時的 git 沖突
- 加速 storyboard 加載，因為只需要加載一個 UIViewController
- 只用 initial view controller 就可以從 SB 中加載想要的 View Controller
在 Xcode 7 引入了 SB reference 以后，「SB 容易沖突」已經徹底變成假命題了。通過合理地劃分功能模塊和每個開發者負責的部分，我們可以完全避免 SB 的修改沖突。近兩三年以來我們在實際項目中完全沒有出現過 SB 沖突的情況。
另外，即使 SB 劃分出現問題，影響也是可控的。在單個的 SB 文件中，每個 View Controller 有各自的范圍域，因此即使存在不同開發者同時著手一個 SB 文件的情況，只要他們不同時修改同一個 View Controller 的內容，也并不會在 View Controller 上產生沖突。在 SB 文件中確實存在一些共用的部分，比如 IB 的版本，系統的版本等，但它們并不影響實質的 UI，而且可以通過統一開發成員的環境來避免沖突。因此，一個 SB 中多個 VC 和一個 SB 中一個 VC，其實所帶來的沖突風險幾乎是一樣的。
關于 SB 的加載，可以看出原作者可能并沒有搞清 UI 加載的整個流程，不求甚解地認為 SB 文件中 View Controller 越多加載時間越長，但事實并非如此。細心的同學 (或者項目中有很多 SB 文件的同學) 會發現，在編譯的時候 Xcode 有一個 Compiling Storyboard files 的過程：
編譯過程中，項目里用到的 SB 文件也會被編譯，并以 storyboardc 為擴展名保存在終的 app 包內。這個文件和 .bundle或者 .framework 類似，實際上是一個文件夾，里面存儲了一個描述該編譯后的 SB 信息的 Info.plist 文件，以及一系列.nib 文件。原來的 SB 中的每個對象 (或者說，一般就是每個 View Controller) 將會被編譯為一個單獨的 .nib，而 .nib 中包含了編碼后的對應的對象層級。在加載一個 SB，并從中讀取單個 View Controller 時，首先系統會找到編譯后的.storyboardc 文件，從 Info.plist 中獲取所需的 View Controller 類型和 nib 的關系，來完成 UIStoryboard 的初始化。接下來讀取對應的某個 nib，并使用 UINibDecoder 進行解碼，將 nib 二進制還原為實際的對象，后調用該對象的initWithCoder: 完成各個屬性的解碼。在完成這些工作后，awakeFromNib 被調用，來通知開發者從 nib 的加載已經完畢。
如果你理解這個過程，就可以看出，從只有單個 View Controller 的 SB 中加載這個 VC，與從多個 View Controller 中加載一個的情況，在速度上并不會有什么區別。硬要說的話，如果使用太多 SB 文件，反而會在初始化 UIStoryboard 時需要讀取更多的 Info.plist，反而造成性能下降 (相對地我們可以使用 View Controller 的 storyboard 屬性來獲取當前 VC 所屬的UIStoryboard，從而避免多次初始化同一個 Storyboard，不過這點性能損失其實無關緊要)。
關于第三點，原作者使用了一段代碼來展示如何通過類似這樣的方法來創建類型安全的對象：
let feed = FeedViewController.instance() // `feed` is of type `FeedViewController`
這么做有幾個前提，首先它需要按照 View Controller 類型名字來創建 SB 文件，其次還需要為 UIViewController 添加按照類型名字尋找 SB 文件的輔助方法。這并不是一個很明顯的優點，它肯定會引入 NSStringFromClass 這種動態的東西，而且其實我們有很多更好的方式來創建類型安全的 View Controller。我會在第二部分介紹一些相關的內容。
原文中第二個主要觀點是：
不要使用 Segue
Segue 的基本作用是串聯不同的 View Controller，完成各 VC 的遷移或者組織。在個觀點 (一個 SB 文件只含有一個 VC) 的前提下，不使用 Segue 是自然而然的推論，因為同一個 SB 中沒有多個 VC 的關系需要組織，segue 的作用被大大降低。但是作者使用了一個不是很好的例子想要強行說明使用 segue 以及 prepare(for:sender:) 的壞處。下面是原文中的一段示例代碼：
class UsersViewController: UIViewController, UITableViewDelegate { private enum SegueIdentifier { static let showUserDetails = "showUserDetails" } var usernames: [String] = ["Marin"]
func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
usernameToSend = usernames[indexPath.row]
performSegue(withIdentifier: SegueIdentifier.showUserDetails, sender: nil)
} private var usernameToSend: String? override func prepare(for segue: UIStoryboardSegue, sender: Any?) { switch segue.identifier { case SegueIdentifier.showUserDetails?:
guard let usernameToSend = usernameToSend else {
assertionFailure("No username provided!") return } let destination = segue.destination as! UserDetailViewController
destination.username = usernameToSend default: break }
}
}
簡單說，這段代碼做的就是在用戶點擊 table view 中某個 cell 的時候，將點擊的內容保存到 View Controller 的一個成員變量usernameToSend 中，然后調用 performSegue(withIdentifier:sender:)。接下來，在 prepare(for:sender:) 中獲取保存的這個成員變量，并且設置給目標 View Controller。對于 table view 來說，這是一個不太必要的做法。我們完全可以直接將 cell 通過 segue 連接到目標 View Controller 上，然后在 prepare(for:sender:) 中使用 table view 的indexPathForSelectedRow 獲取需要的數據，并對目標 View Controller 進行設置。可能原作者不太清楚 UITableView 有這么一個 API，所以用了不太好的例子。
那么 segue 有問題嗎？我的回答是有，但是問題不大。實際開發中確實存在不少類似原作者說到的情形，需要將數據在prepare(for:sender:) 中傳遞給目標 View Controller，不過這種情況的數據很多時候已經存在于當前 View Controller 中 (比如需要傳遞文本框中輸入的文字，或者當前 VC 的 model 的某個屬性等)。相比于變量的問題，segue 帶來的更大的挑戰在于 View Controller 之間遷移的管理。現在我們可以通過代碼進行轉場 (pushViewController(:animated) 或者present(:animated:completion))，也可以使用 SB 里點擊控件的 segue，甚至還可以從代碼中調用 performSegue，在不同的地方進行管理讓代碼變得復雜和難以理解，所以我們可能需要考慮如何以集中的方式進行管理。objc.io 的 Swift Talk 的第五期視頻 - Connecting View Controllers (而且是免費的) 對這個問題進行了一些探討，并給出了一種集中管理 View Controller 之間遷移的方式。其中使用回調的方法可以借鑒，但是我個人對整個思路運用在實際項目里存有疑慮，大家也不妨作為參考了解。
除了管理轉場外，segue 還能夠提供方便的 Container View 的 embed 關系，也可以在使用像是 UIPageViewController 這樣的多個 VC 關系的時候，用來提供一些初始化時運行的代碼，又或者是用 unwind 來方便地實現 dismiss。這些「附加」的功能都讓我們少寫很多代碼，開發效率得到提升，不去嘗試使用的話可以說是相當可惜。
原文作者的后一個主要觀點是：
所有的屬性都在代碼中設置
作者在原文一開始就提到，人都是視覺動物，使用 SB 的一大目標就是直觀地理解界面。通過 SB 畫布我們可以迅速獲得要進行開發的 View Controller 的信息，這比閱讀代碼要快得多。但是，如果所有屬性都在代碼中進行設置的話，這一優勢還剩多少呢？
作者提議在 SB 中對添加的 View 或者 ViewController 保留所有默認設置 (甚至是 view 的背景顏色，或者 label 文字等)，然后使用代碼對它們進行設置。在這一點上，原文作者的顧慮是對于 UI 元素樣式的更改。作者希望通過使用一些常量來保存像是字體，顏色等，并在代碼中將它們分別賦值給 UI 元素，這樣能做到設計改變時只在一處進行更改就可以對應。
這種做法帶來的缺點相當明顯，那就是為了設置這些屬性，你需要很多的 IBOutlet，以及很多額外的工作量。我的建議是，對于那些不會隨著程序狀態改變的內容，好盡量使用 SB 直接進行設置。比如一個 label 上的文字，除非這些文字確實需要改變 (比如顯示的是用戶名，或者當前評論數之類)，否則完全沒有必要添加 @IBOutlet，直接設置 text 會簡單得多。其他像是UIScrollView 的 Cancellable Content Touches 等屬性，如果不需要在程序中根據程序狀態進行改變，也好直接在 IB 里設置。作者在原文里提到，“通過掃描代碼來尋找 view 的屬性要比在 storyboard 中尋找一個勾號來的容易”，關于這一點，我認為其實兩者并沒有什么不同。舉例來說，通過 IB 將 UIScrollView 的 Cancellable Content Touches 設置為 false，在對應的 SB 文件中的 scroll view 里會加上 canCancelContentTouches="NO" 這樣的屬性。通過全局搜索的方式找到這個屬性也是輕而易舉的。甚至你可以直接修改 SB 的源碼達到目的，而根本不需要打開 Xcode 或者 IB。基于查找的可能性，批量的替換和更新與使用代碼來設置也并無異。并不存在說在代碼里更容易被找到這種情況。
不過要注意的是，SB 中的屬性在 Xcode 的查找結果中是被過濾，不會出現的，所以可能需要使用其他的文本編輯器來全局查找。
關于像是字體或者顏色這樣的 view 樣式，作者的顧慮可以理解。IB 現在缺乏良好的做樣式的方法，這也是大家詬病已久的問題。在 Font 選擇中存在 style 的選項，讓我們可以從 Body，Headline 之類的項目中進行選擇，看起來很好：
但是這僅僅只是為了支持 Dynamic Type，設置這些值和調用 UIFont 的 preferredFont(forTextStyle:) 獲取特定字體是一樣的。我們并不能自行定義這些字體樣式，也不能進行添加。顏色也一樣，Xcode 并沒有提供一個類似可以在 IB 里使用的項目顏色版或者顏色變量的概念。
關于 view 樣式，常見也是簡單的解決方案大概有兩種。
種是使用自定義的子類，來統一設置字體或者顏色這些屬性。比如說你的項目里可以會有 HeaderLabel，或者 BodyLable這樣的 UILabel 的子類，然后在子類里相應的方法中設置字體。這種方式來得比較直接，你可以通過更改 IB 里的 label 類型來適用字體。但是缺點在于當項目變大以后，可能 label 的類型會變得很多。另外，對于非全局性的修改，比如只針對某一個特定 label 調整的時候會比較麻煩，很可能你會想只針對個例做個別調整，而不是專門為這種情況建立新的子類，而這個決定往往會讓你之前為了統一樣式所做的努力付之一炬。
另外一種方式是為目標 view 的類型添加像是 style 屬性，然后使用 runtime attribute 來設置。簡單的想法大概是這樣的，比如針對字體：
extension UIFont { enum Style: String { case p = "p" case h1 = "h1" case defalt = "" } static func font(forStyle string: String?) -> UIFont {
guard let fontStyle = Style(rawValue: string ?? "") else {
fatalError("Unrecognized font style.")
} switch fontStyle { case .p: return .systemFont(ofSize: 14) case .h1: return .boldSystemFont(ofSize: 22) case .defalt: return .systemFont(ofSize: 17)
}
}
}
這段代碼為 UIFont 添加了一個靜態方法，通過輸入的字符串獲取不同樣式的字體。
然后，我們為需要字體樣式支持的類型添加設置 style 的擴展，比如對 UILabel：
extension UILabel { var style: String { get { fatalError("Getting the label style is not permitted.") } set { font = UIFont.font(forStyle: newValue) }
}
}
在使用的時候，我們在 IB 里想要適用樣式的 UILabel 添加 runtime attribute 就可以了：
不過不論哪種做法，缺點都是我們無法在 IB 中直觀地看到 label 的變化。當然，可以通過為自定義的 UILabel 子類實現@IBDesignable 來克服這個缺點，不過這也需要額外的工作量。還是希望 Xcode 和 IB 能夠進步，原生支持類似的樣式組織方式吧。不過就因此放棄簡單明了的 UI 構建方式，未免有些過于武斷。
基本上我對原文的每個觀點已經提出了我的想法，不過正如原文作者后說的那樣，你應該選擇你自己的使用風格，并決定要如何使用 Storyboard。
It’s not all or nothing.
原文作者就只將 IB 和 Storyboard 作為一個設置 view 層次和添加 layout 約束的工具，這確實是 SB 的強項所在，但是我認為它的功能要遠比這強大的多。正確地理解 SB 的設計思想和哲學，正確地在可控范圍內使用 SB，對于發掘這個工具的潛力，對于進一步提高開發效率，都會帶來好處。
本文下一部分將會簡單介紹幾個使用 SB 的實踐。
原文作者提到使用單個 VC 的 Storyboard 可以以類型安全的方式進行創建。其實這并不是必要條件，甚至我們通過別的方式可以做得更好。在 Cocoa 框架中，為了靈活性，確實有很多基于字符串的 API，這導致了一定程度的不安全。Apple 自己為了 API 的通用性和兼容性，不太可能對現有的類型不安全的 API 進行大幅修改，不過通過一些合適的封裝，我們依然可以讓 API 更加安全。不管是我個人的項目還是公司的項目，其實都在使用像是 R.swift 這樣的工具。這個項目通過掃描你的各種基于字符串命名的資源 (比如圖片名，View Controller 和 segue 的 identifier 等)，創建一個使用類型來獲取資源的方式。相比與原作者的類型安全的手法，這顯然是一種更成熟和完善的方式。
比如原來我們可以要用這樣的代碼來從 SB 里獲取 View Controller：
let myImage = UIImage(names: "myImage") let viewController = UIStoryboard(name: "Main", bundle: nil).instantiateViewController(withIdentifier: "myViewController") as! MyViewController在 R.swift 的幫助下，我們將可以使用下面的代碼：
let myImage = R.image.myImage()
// myImage: UIImage?
let viewController = R.storyboard.main.myViewController()
// viewController: MyViewController?這種做法在保證類型安全的同時，還可以在編譯時就確認相應資源的存在。要是你修改了 SB 中 View Controller 的 identifier，但是沒有修改相應代碼的話，你會得到一個編譯錯誤。
R.swift 除了可以針對圖片和 View Controller 外，也可以用在本地化字符串、Segue、nib 文件或者 cell 等一系列含有字符串 identifier 的地方。通過在項目中引入 R.swift 進行管理，我們在開發中避免了很多可能的資源使用上的危險和 bug，也在自動補全的幫助下節省了無數時間，而像是使用 Storyboard 并從中創建 View Controller 這樣的工作也變得完全不值一提了。
通過 IB 設置 view 的屬性有一個局限，那就是有一些屬性沒有暴露在 IB 的設置面板中，或者是設置的時候有可能要“轉個彎”。雖然在 IB 面板中已經包含了八九成經常使用的屬性，但是難免會有「漏網之魚」。我們在工程實踐中常遇到的情形有兩種：為一個顯示文字的 view 設置本地化字符串，以及為一個 image view 設置圓角。
這兩個課題我們都使用在對應的 view 中添加 @IBInspectable 的 extension 方法來解決。比如對于本地化字符串的問題，我們會有類似這樣的 extension：
extension UILabel {
@IBInspectable var localizedKey: String? { set {
guard let newValue = newValue else { return }
text = NSLocalizedString(newValue, comment: "")
} get { return text }
}
}
extension UIButton {
@IBInspectable var localizedKey: String? { set {
guard let newValue = newValue else { return }
setTitle(NSLocalizedString(newValue, comment: ""), for: .normal)
} get { return titleLabel?.text }
}
}
extension UITextField {
@IBInspectable var localizedKey: String? { set {
guard let newValue = newValue else { return }
placeholder = NSLocalizedString(newValue, comment: "")
} get { return placeholder }
}
}這樣，在 IB 中我們就可以利用對應類型的 Localized Key 來直接設置本地化字符串了：
設置圓角也類似，為 UIImageView (或者甚至是 UIView) 引入這樣的擴展，并直接在 IB 中進行設置，可以避免很多模板代碼：
@IBInspectable var cornerRadius: CGFloat { get { return layer.cornerRadius
} set {
layer.cornerRadius = newValue
layer.masksToBounds = newValue > 0 }
}
@IBInspectable 實際上和上面提到的 UILabel 的 style 方法一樣，它們都使用了 runtime attribute。顯然，你也可以把UILabel style 寫成一個 @IBInspectable，來方便在 IB 中直接設置樣式。
雖然這個小技巧并不會對 IB 或者 SB 的使用帶來實質性的改善，但是我覺得還是值得一提。如果我們由于某種原因，確實需要在代碼中設置一些 view 的屬性，在連接 @IBOutlet 后，不少開發者會選擇在 viewDidLoad 中進行設置。其實個人認為一個更合適的地方是在該 @IBoutlet 的 didSet 中進行。@IBoutlet 所修飾的也是一個屬性，這個關鍵詞所做的僅只是將屬性暴露給 IB，所以它的各種屬性觀察方法 (willSet，didSet 等) 也會被正常調用。比如，下面我們實際項目中的一段代碼：
@IBOutlet var myTextField: UITextField! {
didSet {
// Workaround for https://openradar.appspot.com/28751703 myTextField.layer.borderWidth = 1.0 myTextField.layer.borderColor = UIColor.lineGreen.cgColor }
}
這么做可以讓設置 view 的代碼和 view 本身相對集中，也可以使 viewDidLoad 更加干凈。
夸了 Storyboard 這么多，當然不是說它沒有缺點。事實不僅如此，SB 還有很多很多可以改善的地方，其中，使用 SB 來實現繼承和重用是困難的地方。
Storyboard 不允許放置單獨的 view，所以如果想要通過 IB 來實現 view 的重用的話，我們需要回退到 xib 文件。即使如此，想要在 SB 的 View Controller 中初始化一個通過 xib 加載的 view 也并不是一件很容易的事情。一般對于這種需求，我們會選擇在 init(coder:) 中加載目標 nib 然后將它作為 subview 添加到目標 view 中。整個過程需要開發者對 nib 加載 view 和 View Controller 的過程有比較清楚的了解，但不幸的是 Apple 把這個過程藏得有些深，所以絕大多數開發者并不關心、也不是很清楚這個過程，就認為這是不可能的。
對于 view 的繼承的話更困難一些。依然是由于二進制 nib 將通過解碼的方式進行還原，所以在設置父類的屬性時需要特別注意。另外，子類的 UI 是否應該通過創建新的 xib 進行構建，還是應該通過代碼將父類的 UI 加到子類上，也會是艱難的選擇。相比起來，使用代碼進行 view 的繼承和重用就要容易得多，方法也明確得多。
不光是單獨的 view，SB 中 View Controller 的繼承和重用也面臨著同樣的問題。View Controller 的重用相對簡單，通過 storyboard 初始化對應的 View Controller，或者通過 segue 就可以了。繼承則更麻煩，不過好在相比起 view 的繼承，View Controller 的繼承關系并不會特別復雜，在 UIKit 中對于 UIViewController 的繼承常用的基本也就UITableViewController，UICollectionViewController，而作為終展示給用戶的 view 的管理代碼來說，也很少有需要繼承一個已經高度專用，并使用 IB 構建的 View Controller。如果你在項目中出現這種繼承的需求，首先對繼承的必要性進行考慮會是不錯的選擇。如果可以通過不同的配置重用已有的 View Controller，那么說明「繼承」可能只是一個偽需求。
不管如何，不能否認，因為構建 UI 的方式是對 xml 文件的編碼和解碼，由此帶來了繼承和重用的困難，這是 IB 或者說 SB 的大的短板。
本文旨在介紹一些我自己對 Storyboard 的看法，和我日常開發中的使用方式。并不是說什么「你應該這樣使用」或者「佳實踐就應當如此這般」。你可以選擇使用純代碼構建 UI，但同時 Apple 也為我們提供了更快捷的 IB 和 Storyboard 的方式。在我這么幾年的使用經驗來看，SB 的設計并沒有這么不堪，而相比于以前使用代碼或者 xib 的方式，現在的開發方式確實讓效率得到了提高。開發者根據自己的需求和理解對工具進行選擇，每個人的選擇和使用的方式都是值得尊重。只要愿意擁抱變化，勇于嘗試新的事物，并從中找到合適自己的東西，那么使用什么樣的方式本身其實便沒有那么重要了。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
