一. 總述
這個方案的最終目的很明確，就是要抽象出一個中間層來對紛亂的引用關(guān)系進行統(tǒng)一的跳轉(zhuǎn)。模塊只和中間層耦合，模塊間解耦；中間層使用runtime的形式調(diào)用模塊的業(yè)務(wù)組件，不依賴具體的模塊代碼.
二. 業(yè)務(wù)場景
脫離業(yè)務(wù)需求的設(shè)計都是空中樓閣，下面將結(jié)合具體的業(yè)務(wù)場景進行方案分析和設(shè)計。
下面是大多數(shù)app都會遇到的業(yè)務(wù)場景:
- 啟動開屏廣告是個運營位置，需要任意跳轉(zhuǎn)
- 輪播圖是個運營位置，需要任意跳轉(zhuǎn)
- webview中通過bridge，也存在任意跳轉(zhuǎn)原生的可能性
- 模塊間各種push
簡單粗暴的方法，就是switch判斷類型，引入各種頭文件，直接跳轉(zhuǎn)。隨著業(yè)務(wù)膨脹，以下弊端會越來越明顯：
- 沒有統(tǒng)一的跳轉(zhuǎn)管理，每塊業(yè)務(wù)都維護了自身的一套邏輯，使得跳轉(zhuǎn)邏輯四處散落;
- 如果要新增一種跳轉(zhuǎn)類型，如1所述，必須要找到四處的跳轉(zhuǎn)邏輯，把可能的地方都加一遍，維護起來非常費勁；
- 模塊間文件直接引用，耦合嚴重。如果修改刪除了某個模塊間的某個文件，會直接影響到所有引用了他的文件；理想期望是獨立模塊可以編譯運行，每個模塊可隨意插拔;
- 模塊間的耦合導(dǎo)致模塊無法復(fù)用；理想期望是一個模塊復(fù)制到新項目時，可以直接編譯運行;
三.梳理分析
通過上述業(yè)務(wù)場景，最直觀的痛點的跳轉(zhuǎn)管理問題，但本質(zhì)上都是耦合的問題，是文件間的引用耦合。
要調(diào)用一個類的方法，import相關(guān)的頭文件，再根據(jù)頭文件暴露的api進行調(diào)用，這再正常不過了。當(dāng)業(yè)務(wù)膨脹后，模塊內(nèi)可以直接耦合引用，但模塊間就必須想辦法解耦。
目前業(yè)內(nèi)有兩種主流方案:
- 以JLRoutes為代表的URLRoute方案:以URL為key，以待執(zhí)行的block為value，保存在一個全局map中，在內(nèi)存中常駐;
- Mediator中間人方案:把所有的調(diào)用都集合在一起，使用一個中間人管理。所有調(diào)用方都通過中間人調(diào)取另外一個模塊;
這兩種方案單獨來說都有各自的優(yōu)劣勢:
- URLRoute方案借鑒了web的思路，非常契合遠程調(diào)用這種場景。但是在開發(fā)時本地原生調(diào)用時，使用者會感到變扭。我們更習(xí)慣調(diào)方法，給方法賦值。在使用URLRoute時，我們還需要多一步轉(zhuǎn)換邏輯，將方法調(diào)用轉(zhuǎn)換成URL形式。這既不方便，同樣存在漏洞。因為URL中只能攜帶常規(guī)數(shù)據(jù)，無法把類似UIImage等格式的數(shù)據(jù)封裝在URL中。
- Mediator方案相比起來對原生調(diào)用就非常友好，但當(dāng)遇見app://user/:userName這樣的跳轉(zhuǎn)需求時，就顯得不那么契合。
詳情的分析可以參考https://casatwy.com/iOS-Modulization.html.
四. 結(jié)合URLRoute和Mediator的跳轉(zhuǎn)方案
1.png
方案如圖所示，具體demo在https://github.com/xuzhenhao/ZHMediator。下面將結(jié)合組件化的思路一起闡述整個方案如何落地。
- 模塊化拆分。
- 首先要進行模塊的劃分，只有模塊間的調(diào)用才會考慮這種方式，模塊內(nèi)的調(diào)用是允許相互間耦合的，因此合理的模塊劃分就很重要。
- 暴露Target對象。Target對象暴露整個模塊對外提供的所有服務(wù)，此外，因為Mediator和Target是通過Runtime交互的，Target暴露的方法中接收的參數(shù)是一個字典，但在方法實現(xiàn)中負責(zé)將傳過來的字典還原成各個參數(shù)，并調(diào)用該模塊具體的類和方法。
- 編寫模塊的Mediator分類。如上所述，受限于runtime只能以字典形式傳一系列參數(shù)，Mediator分類的職責(zé)就在于對外提供參數(shù)友好型的一系列方法，但在方法實現(xiàn)中包裝成字典形式。這里涉及到key的定義必須和Target中還原時的key定義一致，因此劃分給相同的開發(fā)維護。
- 遠程調(diào)用
- 配置URL解析規(guī)則。類似app://user/:userId/detail 這樣的URL，需要通過解析規(guī)則，解析出TargetName、ActionName、Params，交付給Mediator進行處理。目前只是簡單基于JLRoutes的二次封裝，當(dāng)然這里可以根據(jù)需求，后續(xù)也能方便替換。這部分配置建議統(tǒng)一放在AppDelegete+Routes的分類中統(tǒng)一配置。
至此，核心部分就介紹完畢了。完整的demo可以在https://github.com/xuzhenhao/ZHMediator獲得。
