iOS 列表界面如何優雅實現模塊化與動態化

前言

去年作了一個小組件，前些時間考慮到項目中可能會大規模實施，完善簡化後新開了一個 repo: YBHandyList 。

有些朋友拋出了 nimbus、IGListKit 等業界應用很廣的庫，前些時間網易工程師也推出了 M80TableViewComponent。理論上這些組件的原理大同小異，雖然它們各有優點，但卻不太能知足筆者對架構清晰度的要求。

本文分析 YBHandyList 的應用價值，但願能解開一些朋友的疑惑。

業務痛點

iOS 界面開發中 UITableView / UICollectionView 的出場率極高，它們都是使用代理方法配置數據源，雖然這樣的設計理念符合了單一職責原則，但在列表變得複雜時代理方法的處理將變得力不從心：

• 同一個 Cell / Header / Footer 處理邏輯分散在各個代理方法中，不便於管理。
• 當列表數據動態變化時，每個代理方法裏的判斷邏輯都將變得複雜，且這些邏輯極可能會相互關聯。

顯然，在這樣的場景下將是維護的災難，特別是當你接手別人的代碼發現每一個 UITableView 代理方法裏都有幾十個if-else，它們人多勢衆，量你不敢動它們任何一個。

因而可知，若想維護性高須要解開每個 Cell 之間的邏輯耦合，也就是一般意義的模塊化，由此才能更輕易的實現動態化。解決方案其實很簡單，只須要一箇中間類，將分散的配置集中起來（在代理方法裏取這個中間類的對應值）：

@interface Config : NSObject
@property (nonatomic, assign) CGFloat height;
@property (nonatomic, strong) Class cls;
@property (nonatomic, strong) id model;
@end
複製代碼

然而對於業務工程師來講，每次寫這樣的代碼都意味着時間成本，因此製做一個基礎組件是頗有必要的，它須要知足如下特性：

• 模塊化配置 Cell / Header / Footer。
• 更容易實施列表動態化。
• 能拓展原生能實現的全部場景。

爲此，YBHandyList 應運而生，它足夠簡單以致於從設計到編碼基本就花了一天時間。

YBHandyList 的優點

原理：

代碼簡單輕量

YBHandyList 保留最小功能，代碼量不多，核心思路就一句話：將 UITableView / UICollectionView 的數據源從代理方法配置轉化爲數組配置。

在其它庫當中能夠看到高度緩存、訪問迭代器等邏輯，筆者認爲這樣的基礎設施不該該侵入過多業務，它們本應該是業務關注的邏輯，這樣的語法糖只能在簡單場景下少寫些代碼，當業務變得複雜時每每這樣的優點就不存在了。

YBHandyList 的語法糖很是收斂，簡單的一個延展，你甚至能夠選擇不使用語法糖，直接使用代理實現類。

由此，新手工程師也能對實施代碼充滿信心。

業務侵入性低

YBHandyList 採用 IOP 設計，最大限度的下降了業務侵入性，只須要在 Cell / Header / Footer 中實現幾個代理方法就好了。

去基類化設計讓數據流動過程更加純粹，不須要考慮父類作了什麼，沒作什麼。在老業務中可能存在相似BaseTableViewCell 的東西，YBHandyList 也能優雅的接入，這種場景下繼承的設計範式將力不從心。

這種架構規範類組件接入的成本很是重要，而捨棄的成本也不容忽視，因爲 IOP 自然的優點，YBHandyList 結構代碼的捨棄將垂手可得，不拖泥帶水。

直觀的動態化控制

構建界面只須要關注全部id<Config>在數據源數組中的順序，就像搭積木同樣拼接起來，數組中的順序就是對應 Cell 在界面中的顯示順序，由此就能經過改變數據源數組的順序輕易的實現動態化控制。

在 MVVM 架構中實施

YBHandyList 的設計方式讓它在各類架構中都能無障礙實施，下面以 MVVM 舉例（僅說明 UITableViewCell 的實施，具體能夠看 DEMO）：

能夠看到，Cell 與 UITableView 非直接耦合，因此若須要將 Cell 的事件傳遞出來最好經過 Cell 的 ViewModel，ViewModel 做爲鏈接 Cell 與外界的橋樑。

Cell 的 ViewModel 也能夠在主 ViewModel 中構建，這樣 Controller 中就不用導入這些類，不過當 Cell 的 ViewModel 須要將事件傳遞到 Controller 時，就會須要一些膠水代碼經過主 ViewModel 間接傳遞。

數據綁定並不是必須作的事情，你能夠用 RAC，或者另一個選擇：EasyReact，能夠參考筆者的文章：美團 EasyReact 源碼剖析：圖論與響應式編程。

更安全和優雅的複用

不少時候，咱們會將具體業務的處理邏輯放 Cell 中或者其 ViewModel 中，那麼它們就很難複用，由於複用是創建在無具體業務侵入的前提下。

實際上只須要將具體業務的處理邏輯抽離出來，處理事後再放在 ViewModel 中，Cell 拿到 ViewModel 再進行具體業務無關的界面刷新。如此，ViewModel 將能夠在任何地方複用。

使用 YBHandyList 後，ViewModel 把 Cell 與外部業務解開耦合，只把須要暴露的東西寫在ViewModel .h中，外部業務無需導入 Cell 便能經過 ViewModel 直接複用，更加的安全。

能拓展原生支持的場景

一個基礎設施最怕的就是不能知足全部場景的狀況下還封閉了拓展的入口。YBHandyList 經過繼承默認代理實現類就能拓展實現其它的 UITableView / UICollectionView 代理方法。

這看起來有些繁瑣，使用多代理技術能避免額外的建立代理實現類，但這樣會致使代碼再也不簡單和透明。換個角度想，代理實現類中將大量複雜邏輯處理事後，僅僅回調給外部業務一個簡單的方法，達到爲外部模塊瘦身的目的。

後語

筆者一直偏好簡潔的代碼設計，讓核心功能最小化實現，當它沒法覆蓋全部的場景時必定要有原生拓展能力。語法糖的主要意義是減小使用者的思考成本而不僅僅是爲了少寫兩句代碼，它不該該侵入功能收斂的核心代碼。要作好這一切，就必定要透過現象看清問題的本質。