[譯]介紹適用於 iOS 的 AloeStackView
一個簡單的開源類，通過一些方便的 API 來對檢視集合進行佈局。
在 Airbnb iOS APP 中，大約有 200 個頁面是通過使用 AloeStackView 構建的。
在 Airbnb，我們一直在尋找提高構建產品效率的方法。
在過去幾年中，我們的移動開發工作以驚人的速度增長。僅在過去一年中，我們就已經為我們的 iOS 應用添加了超過 260 個頁面。與此同時，越來越多的人開始使用我們的原生移動應用程式。這種趨勢沒有顯示出放緩的跡象。
大約兩年前，我們詳盡討論了我們在 iOS 上如何構建產品，看看是否有提高開發效率的空間。我們發現的一個主要問題是，在我們的 iOS 應用中實現一個新的頁面需要花費數天甚至數週的開發時間。
所以我們要著手改變這一點。我們希望找到一個儘可能比我們想象的還要快的方法來構建頁面。我們希望工程師能夠在在幾分鐘或幾小時內為 iOS 應用新增新頁面，而不是數天或數週的時間。
在過去兩年中，我們在快速構建高質量的 iOS UI 方面吸取了許多教訓。
基於其中的一些知識，我們今天非常興奮地介紹我們在 Airbnb 開發過程中的一種工具，以幫助您快速，輕鬆，高效地編寫 iOS UI。
AloeStackView 簡介
在 Airbnb，我們從 2016 年開始在我們的 iOS 應用程式中使用 ofollow,noindex">AloeStackView ，並且已經使用它在應用程式中實現了近 200 個頁面。用例非常多樣化：從設定頁面的使用到建立新的列表，再到列表狀的操作彈層(例如 UIActionSheet)。
AloeStackView 是一個允許在垂直列表中佈局檢視集合的類。從廣義上講，它類似於 UITableView，但它的實現是完全不同的，它做了不同的權衡取捨。
AloeStackView 首先著重於使 UI 非常快速，簡單和直接實現。它以以下兩種方式來實現這一點:
- 它利用自動佈局的強大功能在更改檢視時自動更新 UI。
- 它放棄了 UITableView 的一些功能，例如檢視回收，以實現更簡單，更安全的 API。
簡化 iOS UI 開發
當我們研究如何提高 iOS 開發效率時，我們意識到的第一件事就是在應用程式中實現最小的頁面需要做多少工作。
事實證明，引入了設計用於處理大型和複雜頁面的抽象，有時會成為較小頁面的負擔。
通常，較小的頁面不會受益於這些抽象提供的優點。例如，如果 UI 完全適合單個頁面，那麼它將不會從檢視回收中受益。顯然，如果我們使用圍繞檢視回收的抽象來構建單個頁面，那麼我們必須要為這個功能增加的 API 複雜性付出代價。
為了解決這個問題，我們首先尋找更簡單的方法來編寫頁面。我們發現的一種非常有效的技術是使用巢狀在 UIScrollView 中的 UIStackView 來佈局頁面。這種方法成為我們構建 AloeStackView 的基礎。
是什麼讓這項技術非常有用？是它允許您隨時保持對檢視的強引用並動態更改其屬性，而自動佈局會自動使 UI 保持最新。
在 Airbnb，我們發現這種技術非常適合接受使用者輸入的頁面，例如表格。在這些情況下，保持對使用者正在編輯的欄位的強引用通常很方便，並直接使用驗證反饋更新 UI。
我們發現這種技術另一個有用的地方是在由不同檢視組成的較小頁面上，少於一兩個內容。簡單地以簡單的方式在 UI 中宣告檢視列表通常可以更快，更輕鬆地實現這些螢幕。
在實踐中，我們發現 iOS 應用程式中的大量的頁面屬於這些類別。AloeStackView 簡單靈活的 API 使我們能夠快速，輕鬆地構建多個頁面，使其成為我們工具箱中的有用工具。
減少 Bug
我們提高開發人員效率的另一種方法是專注於使 iOS UI 開發能更容易的正確完成。AloeStackView API 的主要目標是通過設計確保安全性，以便工程師花費更多時間來構建產品，減少跟蹤 Bug 的時間。
AloeStackView 沒有 reloadData 方法，或其他任何方式通知它更改有關檢視。這使得它比像 UITableView 這樣的類更不容易出錯且更容易除錯。例如，AloeStackView 永遠不會因為對其管理的檢視的基礎資料的更改導致崩潰。
由於 AloeStackView 底層使用了 UIStackView，因此在滾動時它不會回收檢視。這消除了因未正確回收檢視而導致的常見錯誤。它還提供了額外的優點，即當用戶與它們互動時不需要獨立地維護檢視狀態。這可以使一些UI更容易實現，並減少錯誤可能蔓延的表面區域。
權衡利弊
雖然 AloeStackView 既方便又實用，但我們發現它並不適合所有的情況。
例如，AloeStackView 在您載入螢幕時一次性佈局整個 UI。因此，較長的螢幕會在 UI 首次顯示之前看到延遲。因此，AloeStackView 更適合用少於一兩個內容來實現的 UI。
放棄檢視回收機制也是一種權衡：雖然 AloeStackView 編寫 UI 的速度更快，而且不容易出錯，但是它的效能不佳，並且對更長的頁面來說，會比 UITableView 這樣的類使用更多的記憶體。因此，像 UITableView 和 UICollectionView 這樣的類仍然是展示包含許多相同型別檢視的頁面的良好選擇，它們都展示相似了的資料。
儘管有這些限制，我們發現AloeStackView非常適合大量的用例。事實證明，AloeStackView 在實現 UI 方面非常高效和高效，並幫助我們實現了提高 iOS 開發效率的目標。
保持程式碼可管理性
經常引入第三方依賴會導致的一個問題是二進位制包大小的增加。這正是我們想用 AloeStackView 避免的。整個庫少於 500 行程式碼，沒有外部依賴，這使二進位制包大小的增加最小。
少量程式碼除了佔用空間少以外也有其他方面的幫助：它使庫更易於理解，更快地整合到現有應用程式中，無需除錯，也更容易做出貢獻。
另一個問題是，有時與第三方具有依賴關係的庫和您的應用當前的工作方式之間會出現不匹配的情況。為了緩解這個問題，AloeStackVie 儘可能少地限制它的使用方式。任何 UIView 都可以與 AloeStackView 一起使用，這使您可以輕鬆地與您當前用於在應用程式中構建 UI 的任何模式整合。
所有這些功能相結合，使 AloeStackView 非常容易且毫無風險地進行試用。如果您對此感興趣，請 試一試 並告訴我們您的想法。
AloeStackView 不是我們用於在 Airbnb 上構建 iOS UI 的唯一基礎架構，但在許多情況下它對我們很有價值。我們希望您也覺得它很有用！
開始您的使用
我們很高興的開源了 AloeStackView。如果您想了解更多資訊，請訪問 GitHub repository 。
如果您或您的公司發現此庫有用，我們很樂意聽取您的意見。如果您想要取得聯絡，請隨時給維護人員傳送電子郵件（你可以在 GitHub 找到我們），或者你可以通過 [email protected] 聯絡我們。
想參與其中嗎？我們一直在尋找 有才華的人加入我們的團隊 ！
AloeStackView 由 Marli Oshlack、Fan Cox 和 Arthur Pang 開發和維護。
AloeStackView 同樣也受益於許多 Airbnb 工程師的貢獻: Daniel Crampton、Francisco Diaz、 David He、 Jeff Hodnett、 Eric Horacek、 Garrett Larson、 Jasmine Lee、 Isaac Lim、 Jacky Lu、 Noah Martin、 Phil Nachum、 Gonzalo Nuñez、 Laura Skelton、 Cal Stephens 和 Ortal Yahdav。
此外，如果沒有得到 Jordan Harband、 Tyler Hedrick、 Michael Bachand、 Laura Skelton、 Dan Federman 和 John Pottebaum 的幫助和支援，就不可能開源這個專案。
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為掘金 上的英文分享文章。內容覆蓋 Android 、 iOS 、 前端 、 後端 、 區塊鏈 、 產品 、 設計 、 人工智慧 等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃 、官方微博、 知乎專欄 。