[譯] 介紹適用於 iOS 的 AloeStackView

• 原文地址：Introducing AloeStackView for iOS
• 原文做者：Marli Oshlack
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：LoneyIsError
• 校對者：Weslie

一個簡單的開源類，經過一些方便的 API 來對視圖集合進行佈局。

在 Airbnb iOS APP 中，大約有 200 個頁面是經過使用 AloeStackView 構建的。

在 Airbnb，咱們一直在尋找提升構建產品效率的方法。

在過去幾年中，咱們的移動開發工做以驚人的速度增加。僅在過去一年中，咱們就已經爲咱們的 iOS 應用添加了超過 260 個頁面。與此同時，愈來愈多的人開始使用咱們的原生移動應用程序。這種趨勢沒有顯示出放緩的跡象。

大約兩年前，咱們詳盡討論了咱們在 iOS 上如何構建產品，看看是否有提升開發效率的空間。咱們發現的一個主要問題是，在咱們的 iOS 應用中實現一個新的頁面須要花費數天甚至數週的開發時間。

因此咱們要着手改變這一點。咱們但願找到一個儘量比咱們想象的還要快的方法來構建頁面。咱們但願工程師可以在在幾分鐘或幾小時內爲 iOS 應用添加新頁面，而不是數天或數週的時間。

在過去兩年中，咱們在快速構建高質量的 iOS UI 方面吸收了許多教訓。

基於其中的一些知識，咱們今天很是興奮地介紹咱們在 Airbnb 開發過程當中的一種工具，以幫助您快速，輕鬆，高效地編寫 iOS UI。

AloeStackView 簡介

在 Airbnb，咱們從 2016 年開始在咱們的 iOS 應用程序中使用 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 找到咱們），或者你能夠經過 aloestackview@airbnb.com 聯繫咱們。

---

想參與其中嗎？咱們一直在尋找 有才華的人加入咱們的團隊！

---

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、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。