簡述
前幾天的一個晚上在infoQ的微信群里，來自蘑菇街的Limboy做了一個分享，講了蘑菇街的組件化之路。我不認(rèn)為這條組件化之路蘑菇街走對了。分享后我私聊了Limboy，Limboy似乎也明白了問題所在，我答應(yīng)他我會把我的方案寫成文章，于是這篇文章就出來了。
另外，按道理說組件化方案也屬于iOS應(yīng)用架構(gòu)談的一部分，但是當(dāng)初構(gòu)思架構(gòu)談時，我沒打算寫組件化方案，因為我忘了還有這回事兒。。。后來寫到view的時候才想起來，所以在view的那篇文章最后補了一點內(nèi)容。而且覺得這個組件化方案太簡單，包括實現(xiàn)組件化方案的組件也很簡單，代碼算上注釋也才100行，我就偷懶放過了，畢竟寫一篇文章好累的啊。
本文的組件化方案demo在這里https://github.com/casatwy/CTMediator 拉下來后記得pod install 拉下來后記得pod install 拉下來后記得pod install，這個Demo對業(yè)務(wù)敏感的邊界情況處理比較簡單，這需要根據(jù)不同App的特性和不同產(chǎn)品的需求才能做，所以只是為了說明組件化架構(gòu)用的。如果要應(yīng)用在實際場景中的話，可以根據(jù)代碼里給出的注釋稍加修改，就能用了。
蘑菇街的原文地址在這里：《蘑菇街 App 的組件化之路》，沒有耐心看完原文的朋友，我在這里簡要介紹一下蘑菇街的組件化是怎么做的：
App啟動時實例化各組件模塊，然后這些組件向ModuleManager注冊Url，有些時候不需要實例化，使用class注冊。
當(dāng)組件A需要調(diào)用組件B時，向ModuleManager傳遞URL，參數(shù)跟隨URL以GET方式傳遞，類似openURL。然后由ModuleManager負(fù)責(zé)調(diào)度組件B，最后完成任務(wù)。
這里的兩步中，每一步都存在問題。
第一步的問題在于，在組件化的過程中，注冊URL并不是充分必要條件，組件是不需要向組件管理器注冊Url的。而且注冊了Url之后，會造成不必要的內(nèi)存常駐，如果只是注冊Class，內(nèi)存常駐量就小一點，如果是注冊實例，內(nèi)存常駐量就大了。至于蘑菇街注冊的是Class還是實例，Limboy分享時沒有說，文章里我也沒看出來，也有可能是我看漏了。不過這還并不能算是致命錯誤，只能算是小缺陷。
真正的致命錯誤在第二步。在iOS領(lǐng)域里，一定是組件化的中間件為openUrl提供服務(wù)，而不是openUrl方式為組件化提供服務(wù)。
什么意思呢？
也就是說，一個App的組件化方案一定不是建立在URL上的，openURL的跨App調(diào)用是可以建立在組件化方案上的。當(dāng)然，如果App還沒有組件化，openURL方式也是可以建立的，就是丑陋一點而已。
為什么這么說？
因為組件化方案的實施過程中，需要處理的問題的復(fù)雜度，以及拆解、調(diào)度業(yè)務(wù)的過程的復(fù)雜度比較大，單純以openURL的方式是無法勝任讓一個App去實施組件化架構(gòu)的。如果在給App實施組件化方案的過程中是基于openURL的方案的話，有一個致命缺陷：非常規(guī)對象無法參與本地組件間調(diào)度。關(guān)于非常規(guī)對象我會在詳細(xì)講解組件化方案時有一個辨析。
實際App場景下，如果本地組件間采用GET方式的URL調(diào)用，就會產(chǎn)生兩個問題：
根本無法表達非常規(guī)對象
比如你要調(diào)用一個圖片編輯模塊，不能傳遞UIImage到對應(yīng)的模塊上去的話，這是一個很悲催的事情。 當(dāng)然，這可以通過給方法新開一個參數(shù)，然后傳遞過去來解決。比如原來是:
[aopenUrl:"http://casa.com/detail?id=123&type=0"];
同時就也要提供這樣的方法：
[aopenUrl:"http://casa.com/detail"params:@{@"id":"123",@"type":"0",@"image":[UIImageimageNamed:@"test"]}]
如果不像上面這么做，復(fù)雜參數(shù)和非常規(guī)參數(shù)就無法傳遞。如果這么做了，那么事實上這就是拆分遠(yuǎn)程調(diào)用和本地調(diào)用的入口了，這就變成了我文章中提倡的做法，也是蘑菇街方案沒有做到的地方。
另外，在本地調(diào)用中使用URL的方式其實是不必要的，如果業(yè)務(wù)工程師在本地間調(diào)度時需要給出URL，那么就不可避免要提供params，在調(diào)用時要提供哪些params是業(yè)務(wù)工程師很容易懵逼的地方。。。在文章下半部分給出的demo代碼樣例已經(jīng)說明了業(yè)務(wù)工程師在本地間調(diào)用時，是不需要知道URL的，而且demo代碼樣例也闡釋了如何解決業(yè)務(wù)工程師遇到傳params容易懵逼的問題。
URL注冊對于實施組件化方案是完全不必要的，且通過URL注冊的方式形成的組件化方案，拓展性和可維護性都會被打折
注冊URL的目的其實是一個服務(wù)發(fā)現(xiàn)的過程，在iOS領(lǐng)域中，服務(wù)發(fā)現(xiàn)的方式是不需要通過主動注冊的，使用runtime就可以了。另外，注冊部分的代碼的維護是一個相對麻煩的事情，每一次支持新調(diào)用時，都要去維護一次注冊列表。如果有調(diào)用被棄用了，是經(jīng)常會忘記刪項目的。runtime由于不存在注冊過程，那就也不會產(chǎn)生維護的操作，維護成本就降低了。
由于通過runtime做到了服務(wù)的自動發(fā)現(xiàn)，拓展調(diào)用接口的任務(wù)就僅在于各自的模塊，任何一次新接口添加，新業(yè)務(wù)添加，都不必去主工程做操作，十分透明。
小總結(jié)
蘑菇街采用了openURL的方式來進行App的組件化是一個錯誤的做法，使用注冊的方式發(fā)現(xiàn)服務(wù)是一個不必要的做法。而且這方案還有其它問題，隨著下文對組件化方案介紹的展開，相信各位自然心里有數(shù)。
正確的組件化方案
先來看一下方案的架構(gòu)圖
--------------------------------------|[CTMediatorsharedInstance]||||openUrl:<<<<<<<<<(AppDelegate)<<<
這幅圖是組件化方案的一個簡化版架構(gòu)描述，主要是基于Mediator模式和Target-Action模式，中間采用了runtime來完成調(diào)用。這套組件化方案將遠(yuǎn)程應(yīng)用調(diào)用和本地應(yīng)用調(diào)用做了拆分，而且是由本地應(yīng)用調(diào)用為遠(yuǎn)程應(yīng)用調(diào)用提供服務(wù)，與蘑菇街方案正好相反。
調(diào)用方式
先說本地應(yīng)用調(diào)用，本地組件A在某處調(diào)用[[CTMediator sharedInstance] performTarget:targetName action:actionName params:@{...}]向CTMediator發(fā)起跨組件調(diào)用，CTMediator根據(jù)獲得的target和action信息，通過objective-C的runtime轉(zhuǎn)化生成target實例以及對應(yīng)的action選擇子，然后最終調(diào)用到目標(biāo)業(yè)務(wù)提供的邏輯，完成需求。
在遠(yuǎn)程應(yīng)用調(diào)用中，遠(yuǎn)程應(yīng)用通過openURL的方式，由iOS系統(tǒng)根據(jù)info.plist里的scheme配置找到可以響應(yīng)URL的應(yīng)用（在當(dāng)前我們討論的上下文中，這就是你自己的應(yīng)用），應(yīng)用通過AppDelegate接收到URL之后，調(diào)用CTMediator的openUrl:方法將接收到的URL信息傳入。當(dāng)然，CTMediator也可以用openUrl:options:的方式順便把隨之而來的option也接收，這取決于你本地業(yè)務(wù)執(zhí)行邏輯時的充要條件是否包含option數(shù)據(jù)。傳入URL之后，CTMediator通過解析URL，將請求路由到對應(yīng)的target和action，隨后的過程就變成了上面說過的本地應(yīng)用調(diào)用的過程了，最終完成響應(yīng)。
針對請求的路由操作很少會采用本地文件記錄路由表的方式，服務(wù)端經(jīng)常處理這種業(yè)務(wù)，在服務(wù)端領(lǐng)域基本上都是通過正則表達式來做路由解析。App中做路由解析可以做得簡單點，制定URL規(guī)范就也能完成，最簡單的方式就是scheme://target/action這種，簡單做個字符串處理就能把target和action信息從URL中提取出來了。
組件僅通過Action暴露可調(diào)用接口
所有組件都通過組件自帶的Target-Action來響應(yīng)，也就是說，模塊與模塊之間的接口被固化在了Target-Action這一層，避免了實施組件化的改造過程中，對Business的侵入，同時也提高了組件化接口的可維護性。
--------------------------------
|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
|? ? ? ? ? Business A? ? ? ? |
|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
---? ----------? ----------? ---
|? |? ? ? ? |? |? ? ? ? |? |
|? |? ? ? ? |? |? ? ? ? |? |
...........|? |........|? |........|? |...........
.? ? ? ? ? |? |? ? ? ? |? |? ? ? ? |? |? ? ? ? ? .
.? ? ? ? ? |? |? ? ? ? |? |? ? ? ? |? |? ? ? ? ? .
.? ? ? ? ---? ---? ? ---? ---? ? ---? ---? ? ? ? .
.? ? ? ? |? ? ? |? ? |? ? ? |? ? |? ? ? |? ? ? ? .
.? ? ? ? |action|? ? |action|? ? |action|? ? ? ? .
.? ? ? ? |? ? ? |? ? |? ? ? |? ? |? ? ? |? ? ? ? .
.? ? ? ? ---|----? ? -----|--? ? --|-----? ? ? ? .
.? ? ? ? ? |? ? ? ? ? ? |? ? ? ? |? ? ? ? ? ? .
.? ? ? ? ? |? ? ? ? ? ? |? ? ? ? |? ? ? ? ? ? .
.? ? ? ----|------? ? --|--------|--? ? ? ? ? .
.? ? ? |? ? ? ? |? ? |? ? ? ? ? ? |? ? ? ? ? .
.? ? ? |Target_A1|? ? |? Target_A2 |? ? ? ? ? .
.? ? ? |? ? ? ? |? ? |? ? ? ? ? ? |? ? ? ? ? .
.? ? ? -----------? ? --------------? ? ? ? ? .
.? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .
.? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .
..................................................
大家可以看到，虛線圈起來的地方就是用于跨組件調(diào)用的target和action，這種方式避免了由BusinessA直接提供組件間調(diào)用會增加的復(fù)雜度，而且任何組件如果想要對外提供調(diào)用服務(wù)，直接掛上target和action就可以了，業(yè)務(wù)本身在大多數(shù)場景下去進行組件化改造時，是基本不用動的。
復(fù)雜參數(shù)和非常規(guī)參數(shù)，以及組件化相關(guān)設(shè)計思路
這里我們需要針對術(shù)語做一個理解上的統(tǒng)一：
復(fù)雜參數(shù)是指由普通類型的數(shù)據(jù)組成的多層級參數(shù)。在本文中，我們定義只要是能夠被json解析的類型就都是普通類型，包括NSNumber， NSString， NSArray， NSDictionary，以及相關(guān)衍生類型，比如來自系統(tǒng)的NSMutableArray或者你自己定義的都算。
總結(jié)一下就是：在本文討論的場景中，復(fù)雜參數(shù)的定義是由普通類型組成的具有復(fù)雜結(jié)構(gòu)的參數(shù)。普通類型的定義就是指能夠被json解析的類型。
非常規(guī)參數(shù)是指由普通類型以外的類型組成的參數(shù)，例如UIImage等這些不能夠被json解析的類型。然后這些類型組成的參數(shù)在文中就被定義為非常規(guī)參數(shù)。
總結(jié)一下就是：非常規(guī)參數(shù)是包含非常規(guī)類型的參數(shù)。非常規(guī)類型的定義就是不能被json解析的類型都叫非常規(guī)類型。
邊界情況：
假設(shè)多層級參數(shù)中有存在任何一個內(nèi)容是非常規(guī)參數(shù)，本文中這種參數(shù)就也被認(rèn)為是非常規(guī)參數(shù)。
如果某個類型當(dāng)前不能夠被json解析，但通過某種轉(zhuǎn)化方式能夠轉(zhuǎn)化成json，那么這種類型在場景上下文中，我們也稱為普通類型。
舉個例子就是通過json描述的自定義view。如果這個view能夠通過某個組件被轉(zhuǎn)化成json，那么即使這個view本身并不是普通類型，在具有轉(zhuǎn)化器的上下文場景中，我們依舊認(rèn)為它是普通類型。
如果上下文場景中沒有轉(zhuǎn)化器，這個view就是非常規(guī)類型了。
假設(shè)轉(zhuǎn)化出的json不能夠被還原成view，比如組件A有轉(zhuǎn)化器，組件B中沒有轉(zhuǎn)化器，因此在組件間調(diào)用過程中json在B組件里不能被還原成view。在這種調(diào)用方向中，只要調(diào)用者能將非常規(guī)類型轉(zhuǎn)化成json的，我們就依然認(rèn)為這個view是普通類型。如果調(diào)用者是組件A，轉(zhuǎn)化器在組件B中，A傳遞view參數(shù)時是沒辦法轉(zhuǎn)化成json的，那么這個view就被認(rèn)為是非常規(guī)類型，哪怕它在組件B中能夠被轉(zhuǎn)化成json。
然后我來解釋一下為什么應(yīng)該由本地組件間調(diào)用來支持遠(yuǎn)程應(yīng)用調(diào)用：
在遠(yuǎn)程App調(diào)用時，遠(yuǎn)程App是不可能通過URL來提供非常規(guī)參數(shù)的，最多只能以json string的方式經(jīng)過URLEncode之后再通過GET來提供復(fù)雜參數(shù)，然后再在本地組件中解析json，最終完成調(diào)用。在組件間調(diào)用時，通過performTarget:action:params:是能夠提供非常規(guī)參數(shù)的，于是我們可以知道，遠(yuǎn)程App調(diào)用時的上下文環(huán)境以及功能是本地組件間調(diào)用時上下文環(huán)境以及功能的子集。
因此這個邏輯注定了必須由本地組件間調(diào)用來為遠(yuǎn)程App調(diào)用來提供服務(wù)，只有符合這個邏輯的設(shè)計思路才是正確的組件化方案的設(shè)計思路，其他跟這個不一致的思路一定就是錯的。因為邏輯上子集為父集提供服務(wù)說不通，所以強行這么做的話，用一個成語來總結(jié)就叫做倒行逆施。
另外，遠(yuǎn)程App調(diào)用和本地組件間調(diào)用必須要拆分開，遠(yuǎn)程App調(diào)用只能走CTMediator提供的專用遠(yuǎn)程的方法，本地組件間調(diào)用只能走CTMediator提供的專用本地的方法，兩者不能通過同一個接口來調(diào)用。
這里有兩個原因：
遠(yuǎn)程App調(diào)用處理入?yún)⒌倪^程比本地多了一個URL解析的過程，這是遠(yuǎn)程App調(diào)用特有的過程。這一點我前面說過，這里我就不細(xì)說了。
架構(gòu)師沒有充要條件條件可以認(rèn)為遠(yuǎn)程App調(diào)用對于無響應(yīng)請求的處理方式和本地組件間調(diào)用無響應(yīng)請求的處理方式在未來產(chǎn)品的演進過程中是一致的
在遠(yuǎn)程App調(diào)用中，用戶通過url進入app，當(dāng)app無法為這個url提供服務(wù)時，常見的辦法是展示一個所謂的404界面，告訴用戶"當(dāng)前沒有相對應(yīng)的內(nèi)容，不過你可以在app里別的地方再逛逛"。這個場景多見于用戶使用的App版本不一致。比如有一個URL只有1.1版本的app能完整響應(yīng)，1.0版本的app雖然能被喚起，但是無法完成整個響應(yīng)過程，那么1.0的app就要展示一個404了。
在組件間調(diào)用中，如果遇到了無法響應(yīng)的請求，就要分兩種場景考慮了。
場景1
如果這種無法響應(yīng)的請求發(fā)生場景是在開發(fā)過程中，比如兩個組件同時在開發(fā)，組件A調(diào)用組件B時，組件B還處于舊版本沒有發(fā)布新版本，因此響應(yīng)不了，那么這時候的處理方式可以相對隨意，只要能體現(xiàn)B模塊是舊版本就行了，最后在RC階段統(tǒng)測時是一定能夠發(fā)現(xiàn)的，只要App沒發(fā)版，怎么處理都來得及。
場景2
如果這種無法響應(yīng)的請求發(fā)生場景是在已發(fā)布的App中，有可能展示個404就結(jié)束了，那這就跟遠(yuǎn)程App調(diào)用時的404處理場景一樣。但也有可能需要為此做一些額外的事情，有可能因為做了額外的事情，就不展示404了，展示別的頁面了，這一切取決于產(chǎn)品經(jīng)理。
那么這種場景是如何發(fā)生的呢？
我舉一個例子：當(dāng)用戶在1.0版本時收藏了一個東西，然后用戶升級App到1.1版本。1.0版本的收藏項目在本地持久層存入的數(shù)據(jù)有可能是會跟1.1版本收藏時存入的數(shù)據(jù)是不一致的。此時用戶在1.1版本的app中對1.0版本收藏的東西做了一些操作，觸發(fā)了本地組件間調(diào)用，這個本地間調(diào)用又與收藏項目本身的數(shù)據(jù)相關(guān)，那么這時這個調(diào)用就是有可能變成無響應(yīng)調(diào)用，此時的處理方式就不見得跟以前一樣展示個404頁面就結(jié)束了，因為用戶已經(jīng)看到了收藏了的東西，結(jié)果你還告訴他找不到，用戶立刻懵逼。。。這時候的處理方式就會用很多種，至于產(chǎn)品經(jīng)理會選擇哪種，你作為架構(gòu)師是沒有辦法預(yù)測的。如果產(chǎn)品經(jīng)理提的需求落實到架構(gòu)上，對調(diào)用入口產(chǎn)生要求然而你的架構(gòu)又沒有拆分調(diào)用入口，對于你的選擇就只有兩個：要么打回產(chǎn)品需求，要么加個班去拆分調(diào)用入口。
當(dāng)然，架構(gòu)師可以選擇打回產(chǎn)品經(jīng)理的需求，最終挑選一個自己的架構(gòu)能夠承載的需求。但是，如果這種是因為你早期設(shè)計架構(gòu)時挖的坑而打回的產(chǎn)品需求，你不覺得丟臉么？
鑒于遠(yuǎn)程app調(diào)用和本地組件間調(diào)用下的無響應(yīng)請求處理方式不同，以及未來不可知的產(chǎn)品演進，拆分遠(yuǎn)程app調(diào)用入口和本地組件間調(diào)用入口是功在當(dāng)代利在千秋的事情。
組件化方案中的去model設(shè)計
組件間調(diào)用時，是需要針對參數(shù)做去model化的。如果組件間調(diào)用不對參數(shù)做去model化的設(shè)計，就會導(dǎo)致業(yè)務(wù)形式上被組件化了，實質(zhì)上依然沒有被獨立。
假設(shè)模塊A和模塊B之間采用model化的方案去調(diào)用，那么調(diào)用方法時傳遞的參數(shù)就會是一個對象。
如果對象不是一個面向接口的通用對象，那么mediator的參數(shù)處理就會非常復(fù)雜，因為要區(qū)分不同的對象類型。如果mediator不處理參數(shù)，直接將對象以范型的方式轉(zhuǎn)交給模塊B，那么模塊B必然要包含對象類型的聲明。假設(shè)對象聲明放在模塊A，那么B和A之間的組件化只是個形式主義。如果對象類型聲明放在mediator，那么對于B而言，就不得不依賴mediator。但是，大家可以從上面的架構(gòu)圖中看到，對于響應(yīng)請求的模塊而言，依賴mediator并不是必要條件，因此這種依賴是完全不需要的，這種依賴的存在對于架構(gòu)整體而言，是一種污染。
如果參數(shù)是一個面向接口的對象，那么mediator對于這種參數(shù)的處理其實就沒必要了，更多的是直接轉(zhuǎn)給響應(yīng)方的模塊。而且接口的定義就不可能放在發(fā)起方的模塊中了，只能放在mediator中。響應(yīng)方如果要完成響應(yīng)，就也必須要依賴mediator，然而前面我已經(jīng)說過，響應(yīng)方對于mediator的依賴是不必要的，因此參數(shù)其實也并不適合以面向接口的對象的方式去傳遞。
因此，使用對象化的參數(shù)無論是否面向接口，帶來的結(jié)果就是業(yè)務(wù)模塊形式上是被組件化了，但實質(zhì)上依然沒有被獨立。
在這種跨模塊場景中，參數(shù)最好還是以去model化的方式去傳遞，在iOS的開發(fā)中，就是以字典的方式去傳遞。這樣就能夠做到只有調(diào)用方依賴mediator，而響應(yīng)方不需要依賴mediator。然而在去model化的實踐中，由于這種方式自由度太大，我們至少需要保證調(diào)用方生成的參數(shù)能夠被響應(yīng)方理解，然而在組件化場景中，限制去model化方案的自由度的手段，相比于網(wǎng)絡(luò)層和持久層更加容易得多。
因為組件化天然具備了限制手段：參數(shù)不對就無法調(diào)用！無法調(diào)用時直接debug就能很快找到原因。所以接下來要解決的去model化方案的另一個問題就是：如何提高開發(fā)效率。
在去model的組件化方案中，影響效率的點有兩個：調(diào)用方如何知道接收方需要哪些key的參數(shù)？調(diào)用方如何知道有哪些target可以被調(diào)用？其實后面的那個問題不管是不是去model的方案，都會遇到。為什么放在一起說，因為我接下來要說的解決方案可以把這兩個問題一起解決。
解決方案就是使用category
mediator這個repo維護了若干個針對mediator的category，每一個對應(yīng)一個target，每個category里的方法對應(yīng)了這個target下所有可能的調(diào)用場景，這樣調(diào)用者在包含mediator的時候，自動獲得了所有可用的target-action，無論是調(diào)用還是參數(shù)傳遞，都非常方便。接下來我要解釋一下為什么是category而不是其他：
category本身就是一種組合模式，根據(jù)不同的分類提供不同的方法，此時每一個組件就是一個分類，因此把每個組件可以支持的調(diào)用用category封裝是很合理的。
在category的方法中可以做到參數(shù)的驗證，在架構(gòu)中對于保證參數(shù)安全是很有必要的。當(dāng)參數(shù)不對時，category就提供了補救的入口。
category可以很輕松地做請求轉(zhuǎn)發(fā)，如果不采用category，請求轉(zhuǎn)發(fā)邏輯就非常難做了。
category統(tǒng)一了所有的組件間調(diào)用入口，因此無論是在調(diào)試還是源碼閱讀上，都為工程師提供了極大的方便。
由于category統(tǒng)一了所有的調(diào)用入口，使得在跨模塊調(diào)用時，對于param的hardcode在整個App中的作用域僅存在于category中，在這種場景下的hardcode就已經(jīng)變成和調(diào)用宏或者調(diào)用聲明沒有任何區(qū)別了，因此是可以接受的。
這里是業(yè)務(wù)方使用category調(diào)用時的場景，大家可以看到非常方便，不用去記URL也不用糾結(jié)到底應(yīng)該傳哪些參數(shù)。
if(indexPath.row==0){UIViewController*viewController=[[CTMediatorsharedInstance]CTMediator_viewControllerForDetail];// 獲得view controller之后，在這種場景下，到底push還是present，其實是要由使用者決定的，mediator只要給出view controller的實例就好了[selfpresentViewController:viewControlleranimated:YEScompletion:nil];}if(indexPath.row==1){UIViewController*viewController=[[CTMediatorsharedInstance]CTMediator_viewControllerForDetail];[self.navigationControllerpushViewController:viewControlleranimated:YES];}if(indexPath.row==2){// 這種場景下，很明顯是需要被present的，所以不必返回實例，mediator直接present了[[CTMediatorsharedInstance]CTMediator_presentImage:[UIImageimageNamed:@"image"]];}if(indexPath.row==3){// 這種場景下，參數(shù)有問題，因此需要在流程中做好處理[[CTMediatorsharedInstance]CTMediator_presentImage:nil];}if(indexPath.row==4){[[CTMediatorsharedInstance]CTMediator_showAlertWithMessage:@"casa"cancelAction:nilconfirmAction:^(NSDictionary*info){// 做你想做的事NSLog(@"%@",info);}];}
本文對應(yīng)的demo展示了如何使用category來實現(xiàn)去model的組件調(diào)用。上面的代碼片段也是摘自這個demo。
基于其他考慮還要再做的一些額外措施
基于安全考慮
我們需要防止黑客通過URL的方式調(diào)用本屬于native的組件，比如支付寶的個人財產(chǎn)頁面。如果在調(diào)用層級上沒有區(qū)分好，沒有做好安全措施，黑客就有通過safari查看任何人的個人財產(chǎn)的可能。
安全措施其實有很多，大部分取決于App本身以及產(chǎn)品的要求。在架構(gòu)層面要做的最基礎(chǔ)的一點就是區(qū)分調(diào)用是來自于遠(yuǎn)程App還是本地組件，我在demo中的安全措施是采用給action添加native前綴去做的，凡是帶有native前綴的就都只允許本地組件調(diào)用，如果在url階段發(fā)現(xiàn)調(diào)用了前綴為native的方法，那就可以采取響應(yīng)措施了。這也是將遠(yuǎn)程app調(diào)用入口和本地組件調(diào)用入口區(qū)分開來的重要原因之一。
當(dāng)然，為了確保安全的做法有很多，但只要拆出遠(yuǎn)程調(diào)用和本地調(diào)用，各種做法就都有施展的空間了。
基于動態(tài)調(diào)度考慮
動態(tài)調(diào)度的意思就是，今天我可能這個跳轉(zhuǎn)是要展示A頁面，但是明天可能同樣的跳轉(zhuǎn)就要去展示B頁面了。這個跳轉(zhuǎn)有可能是來自于本地組件間跳轉(zhuǎn)也有可能是來自于遠(yuǎn)程app。
做這個事情的切點在本文架構(gòu)中，有很多個：
以url parse為切點
以實例化target時為切點
以category調(diào)度方法為切點
以target下的action為切點
如果以url parse為切點的話，那么這個動態(tài)調(diào)度就只能夠?qū)h(yuǎn)程App跳轉(zhuǎn)產(chǎn)生影響，失去了動態(tài)調(diào)度本地跳轉(zhuǎn)的能力，因此是不適合的。
如果以實例化target時為切點的話，就需要在代碼中針對所有target都做一次審查，看是否要被調(diào)度，這是沒必要的。假設(shè)10個調(diào)用請求中，只有1個要被動態(tài)調(diào)度，那么就必須要審查10次，只有那1次審查通過了，才走動態(tài)調(diào)度，這是一種相對比較粗暴的方法。
如果以category調(diào)度方法為切點的話，那動態(tài)調(diào)度就只能影響到本地件組件的跳轉(zhuǎn)，因為category是只有本地才用的，所以也不適合。
以target下的action為切點是最適合的，因為動態(tài)調(diào)度在一般場景下都是有范圍的，大多數(shù)是活動頁需要動態(tài)調(diào)度，今天這個活動明天那個活動，或者今天活動正在進行明天活動就結(jié)束了，所以產(chǎn)生動態(tài)調(diào)度的需求。我們在可能產(chǎn)生動態(tài)調(diào)度的action中審查當(dāng)前action是否需要被動態(tài)調(diào)度，在常規(guī)調(diào)度中就沒必要審查了，例如個人主頁的跳轉(zhuǎn)，商品詳情的跳轉(zhuǎn)等，這樣效率就能比較高。
大家會發(fā)現(xiàn)，如果要做類似這種效率更高的動態(tài)調(diào)度，target-action層被抽象出來就是必不可少的，然而蘑菇街并沒有抽象出target-action層，這也是其中的一個問題。
當(dāng)然，如果你的產(chǎn)品要求所有頁面都是存在動態(tài)調(diào)度需求的，那就還是以實例化target時為切點去調(diào)度了，這樣能做到審查每一次調(diào)度請求，從而實現(xiàn)動態(tài)調(diào)度。
說完了調(diào)度切點，接下來要說的就是如何完成審查流程。完整的審查流程有幾種，我每個都列舉一下：
App啟動時下載調(diào)度列表，或者定期下載調(diào)度列表。然后審查時檢查當(dāng)前action是否存在要被動態(tài)調(diào)度跳轉(zhuǎn)的action，如果存在，則跳轉(zhuǎn)到另一個action
每一次到達新的action時，以action為參數(shù)調(diào)用API獲知是否需要被跳轉(zhuǎn)，如果需要被跳轉(zhuǎn)，則API告知要跳轉(zhuǎn)的action，然后再跳轉(zhuǎn)到API指定的action
這兩種做法其實都可以，如果產(chǎn)品對即時性的要求比較高，那么采用第二種方案，如果產(chǎn)品對即時性要求不那么高，第一種方案就可以了。由于本文的方案是沒有URL注冊列表的，因此服務(wù)器只要給出原始target-action和對應(yīng)跳轉(zhuǎn)的target-action就可以了，整個流程不是只有注冊URL列表才能達成的，而且這種方案比注冊URL列表要更易于維護一些。
另外，說采用url rewrite的手段來進行動態(tài)調(diào)度，也不是不可以。但是這里我需要辨析的是，URL的必要性僅僅體現(xiàn)在遠(yuǎn)程App調(diào)度中，是沒必要蔓延到本地組件間調(diào)用的。這樣，當(dāng)我們做遠(yuǎn)程App的URL路由時（目前的demo沒有提供URL路由功能，但是提供了URL路由操作的接入點，可以根據(jù)業(yè)務(wù)需求插入這個功能），要關(guān)心的事情就能少很多，可以比較干凈。在這種場景下，單純以URL rewrite的方式其實就與上文提到的以url parse為切點沒有區(qū)別了。
相比之下，蘑菇街的組件化方案有以下缺陷
蘑菇街沒有拆分遠(yuǎn)程調(diào)用和本地間調(diào)用
不拆分遠(yuǎn)程調(diào)用和本地間調(diào)用，就使得后續(xù)很多手段難以實施，這個我在前文中都已經(jīng)有論述了。另外再補充一下，這里的拆分不是針對來源做拆分。比如通過URL來區(qū)分是遠(yuǎn)程App調(diào)用還是本地調(diào)用，這只是區(qū)分了調(diào)用者的來源。
這里說的區(qū)分是指：遠(yuǎn)程調(diào)用走遠(yuǎn)程調(diào)用路徑，也就是openUrl->urlParse->perform->target-action。本地組件間調(diào)用就走本地組件間調(diào)用路徑：perform->target-action。這兩個是一定要作區(qū)分的，蘑菇街方案并沒有對此做好區(qū)分。
蘑菇街以遠(yuǎn)程調(diào)用的方式為本地間調(diào)用提供服務(wù)
這是本末倒置的做法，倒行逆施導(dǎo)致的是未來架構(gòu)難以為業(yè)務(wù)發(fā)展提供支撐。因為前面已經(jīng)論述過，在iOS場景下，遠(yuǎn)程調(diào)用的實現(xiàn)是本地調(diào)用實現(xiàn)的子集，只有大的為小提供服務(wù)，也就是本地調(diào)用為遠(yuǎn)程調(diào)用提供服務(wù)，如果反過來就是倒行逆施了。
蘑菇街的本地間調(diào)用無法傳遞非常規(guī)參數(shù)，復(fù)雜參數(shù)的傳遞方式非常丑陋
注意這里復(fù)雜參數(shù)和非常規(guī)參數(shù)的辨析。
由于采用遠(yuǎn)程調(diào)用的方式執(zhí)行本地調(diào)用，在前面已經(jīng)論述過兩者功能集的關(guān)系，因此這種做法無法滿足傳遞非常規(guī)參數(shù)的需求。而且如果基于這種方式不變的話，復(fù)雜參數(shù)的傳遞也只能依靠經(jīng)過urlencode的json string進行，這種方式非常丑陋，而且也不便于調(diào)試。
蘑菇街必須要在app啟動時注冊URL響應(yīng)者
這個條件在組件化方案中是不必要條件，demo也已經(jīng)證實了這一點。這個不必要的操作會導(dǎo)致不必要的維護成本，如果單純從只要完成業(yè)務(wù)就好的角度出發(fā)，這倒不是什么大問題。這就看架構(gòu)師對自己是不是要求嚴(yán)格了。
新增組件化的調(diào)用路徑時，蘑菇街的操作相對復(fù)雜
在本文給出的組件化方案中，響應(yīng)者唯一要做的事情就是提供Target和Action，并不需要再做其它的事情。蘑菇街除此之外還要再做很多額外不必要措施，才能保證調(diào)用成功。
蘑菇街沒有針對target層做封裝
這種做法使得所有的跨組件調(diào)用請求直接hit到業(yè)務(wù)模塊，業(yè)務(wù)模塊必然因此變得臃腫難以維護，屬于侵入式架構(gòu)。應(yīng)該將原本屬于調(diào)用相應(yīng)的部分拿出來放在target-action中，才能盡可能保證不將無關(guān)代碼侵入到原有業(yè)務(wù)組件中，才能保證業(yè)務(wù)組件未來的遷移和修改不受組件調(diào)用的影響，以及降低為項目的組件化實施而帶來的時間成本。
總結(jié)
本文提供的組件化方案是采用Mediator模式和蘋果體系下的Target-Action模式設(shè)計的。
然而這款方案有一個很小的缺陷在于對param的key的hardcode，這是為了達到最大限度的解耦和靈活度而做的權(quán)衡。在我的網(wǎng)絡(luò)層架構(gòu)和持久層架構(gòu)中，都沒有hardcode的場景，這也從另一個側(cè)面說明了組件化架構(gòu)的特殊性。
權(quán)衡時，考慮到這部分hardcode的影響域僅僅存在于mediator的category中。在這種情況下，hardcode對于調(diào)用者的調(diào)用是完全透明的。對于響應(yīng)者而言，處理方式等價于對API返回的參數(shù)的處理方式，且響應(yīng)者的處理方式也被限制在了Action中。
因此這部分的hardcode的存在雖然確實有點不干凈，但是相比于這些不干凈而帶來的其他好處而言，在權(quán)衡時是可以接受的，如果不采用hardcode，那勢必就會導(dǎo)致請求響應(yīng)方也需要依賴mediator，然而這在邏輯上是不必要的。另外，在我的各個項目的實際使用過程中，這部分hardcode是沒有影響的。
另外要談的是，之所以會在組件化方案中出現(xiàn)harcode，而網(wǎng)絡(luò)層和持久層的去model化都沒有發(fā)生hardcode情況，是因為組件化調(diào)用的所有接受者和調(diào)用者都在同一片上下文里。網(wǎng)絡(luò)層有一方在服務(wù)端，持久層有一方在數(shù)據(jù)庫。再加上設(shè)計時針對hardcode部分的改進手段其實已經(jīng)超出了語言本身的限制。也就是說，harcode受限于語言本身。objective-C也好，swift也好，它們的接口設(shè)計哲學(xué)是存在缺陷的。如果我們假設(shè)在golang的背景下，是完全可以用golang的接口體系去做一個最優(yōu)美的架構(gòu)方案出來的。不過這已經(jīng)不屬于本文的討論范圍了，有興趣的同學(xué)可以去了解一下相關(guān)知識。架構(gòu)設(shè)計有時就是這么無奈。
組件化方案在App業(yè)務(wù)穩(wěn)定，且規(guī)模（業(yè)務(wù)規(guī)模和開發(fā)團隊規(guī)模）增長初期去實施非常重要，它助于將復(fù)雜App分而治之，也有助于多人大型團隊的協(xié)同開發(fā)。但組件化方案不適合在業(yè)務(wù)不穩(wěn)定的情況下過早實施，至少要等產(chǎn)品已經(jīng)經(jīng)過MVP階段時才適合實施組件化。因為業(yè)務(wù)不穩(wěn)定意味著鏈路不穩(wěn)定，在不穩(wěn)定的鏈路上實施組件化會導(dǎo)致將來主業(yè)務(wù)產(chǎn)生變化時，全局性模塊調(diào)度和重構(gòu)會變得相對復(fù)雜。
當(dāng)決定要實施組件化方案時，對于組件化方案的架構(gòu)設(shè)計優(yōu)劣直接影響到架構(gòu)體系能否長遠(yuǎn)地支持未來業(yè)務(wù)的發(fā)展，對App的組件化不只是僅僅的拆代碼和跨業(yè)務(wù)調(diào)頁面，還要考慮復(fù)雜和非常規(guī)業(yè)務(wù)參數(shù)參與的調(diào)度，非頁面的跨組件功能調(diào)度，組件調(diào)度安全保障，組件間解耦，新舊業(yè)務(wù)的調(diào)用接口修改等問題。
蘑菇街的組件化方案只實現(xiàn)了跨業(yè)務(wù)頁面調(diào)用的需求，本質(zhì)上只實現(xiàn)了我在view層架構(gòu)的文章中跨業(yè)務(wù)頁面調(diào)用的內(nèi)容，這還沒有到成為組件化方案的程度，且蘑菇街的組件化方案距離真正的App組件化的要求還是差了一段距離的，且存在設(shè)計邏輯缺陷，希望蘑菇街能夠加緊重構(gòu)，打造真正的組件化方案。
2016-03-14 20:26 補
沒想到limboy如此迅速地發(fā)文回應(yīng)了。文章地址在這里：蘑菇街 App 的組件化之路 續(xù)。然后我花了一些時間重新看了limboy的第一篇文章。我覺得在本文開頭我對蘑菇街的組件化方案描述過于簡略了，而且我還忽略了原來是有ModuleManager的，所以在這里我重新描述一番。
蘑菇街是以兩種方式來做跨組件操作的
第一種是通過MGJRouter的registerURLPattern:toHandler:進行注冊，將URL和block綁定。這個方法前面一個參數(shù)傳遞的是URL，例如mgj://detail?id=:id這種，后面的toHandler:傳遞的是一個^(NSDictionary *routerParameters){// 此處可以做任何事}的block。
當(dāng)組件執(zhí)行[MGJRouter openURL:@"mgj://detail?id=404"]時，根據(jù)之前registerURLPattern:toHandler:的信息，找到之前通過toHandler:收集的block，然后將URL中帶的GET參數(shù)，此處是id=404，傳入block中執(zhí)行。如果在block中執(zhí)行NSLog(routerParameters)的話，就會看到@{@"id":@"404"}，因此block中的業(yè)務(wù)就能夠得到執(zhí)行。
然后為了業(yè)務(wù)方能夠不生寫URL，蘑菇街列出了一系列宏或者字符串常量（具體是宏還是字符串我就不是很確定，沒看過源碼，但limboy文章中有提到通過一個后臺系統(tǒng)生成一個裝滿URL的源碼文件）來表征URL。在openURL時，無論是遠(yuǎn)程應(yīng)用調(diào)用還是本地組件間調(diào)用，只要傳遞的參數(shù)不復(fù)雜，就都會采用openURL的方式去喚起頁面，因為復(fù)雜的參數(shù)和非常規(guī)參數(shù)這種調(diào)用方式就無法支持了。
缺陷在于：這種注冊的方式其實是不必要的，而且還白白使用URL和block占用了內(nèi)存。另外還有一個問題就是，即便是簡單參數(shù)的傳遞，如果參數(shù)比較多，業(yè)務(wù)工程師不看原始URL字符串是無法知道要傳遞哪些參數(shù)的。
蘑菇街之所以采用id=:id的方式，我猜是為了怕業(yè)務(wù)工程師傳遞多個參數(shù)順序不同會導(dǎo)致問題，而使用的占位符。這種做法在持久層生成sql字符串時比較常見。不過這個功能我沒在limboy的文章中看到有寫，不知道實現(xiàn)了沒有。
在本文提供的組件化方案中，因為沒有注冊，所以就沒有內(nèi)存的問題。因為通過category提供接口調(diào)用，就沒有參數(shù)的問題。對于蘑菇街來說，這種做法其實并沒有做到拆分遠(yuǎn)程應(yīng)用調(diào)用和本地組件間調(diào)用的目的，而不拆分會導(dǎo)致的問題我在文章中已經(jīng)論述過了，這里就不多說了。
由于前面openURL的方式不能夠傳遞非常規(guī)參數(shù)，因此有了第二種注冊方式：新開了一個對象叫做ModuleManager，提供了一個registerClass:forProtocol:的方法，在應(yīng)用啟動時，各組件都會有一個專門的ModuleEntry被喚起，然后ModuleEntry將@protocol和Class進行配對。因此ModuleManager中就有了一個字典來記錄這個配對。
當(dāng)有涉及非常規(guī)參數(shù)的調(diào)用時，業(yè)務(wù)方就不會去使用[MGJRouter openURL:@"mgj://detail?id=404"]的方案了，轉(zhuǎn)而采用ModuleManager的classForProtocol:方法。業(yè)務(wù)傳入一個@protocol給ModuleManager，然后ModuleManager通過之前注冊過的字典查找到對應(yīng)的Class返回給業(yè)務(wù)方，然后業(yè)務(wù)方再自己執(zhí)行alloc和init方法得到一個符合剛才傳入@protocol的對象，然后再執(zhí)行相應(yīng)的邏輯。
這里的ModuleManager其實跟之前的MGJRouter一樣，是沒有任何必要去注冊協(xié)議和類名的。而且無論是服務(wù)提供者調(diào)用registerClass:forProtocol:也好，服務(wù)的調(diào)用者調(diào)用classForProtocol:，都必須依賴于同一個protocol。蘑菇街把所有的protocol放入了一個publicProtocol.h的文件中，因此調(diào)用方和響應(yīng)方都必須依賴于同一個文件。這個我在文章中也論述過：響應(yīng)方在提供服務(wù)的時候，是不需要依賴任何人的。
所以針對蘑菇街的這篇文章我是這么回應(yīng)的：
蘑菇街所謂分開了遠(yuǎn)程應(yīng)用調(diào)用和本地組件調(diào)用是不成立的，蘑菇街分開的只是普通參數(shù)調(diào)用和非常規(guī)參數(shù)調(diào)用。不去區(qū)分遠(yuǎn)程應(yīng)用調(diào)用和本地組件間調(diào)用的缺陷我在文中已經(jīng)論述過了，這里不多說。
蘑菇街確實不只有openURL方式，還提供了ModuleManager方式，然而所謂的我們其實是分為「組件間調(diào)用」和「頁面間跳轉(zhuǎn)」兩個維度，只要 app 響應(yīng)某個 URL，無論是 app 內(nèi)還是 app 外都可以，而「組件間」調(diào)用走的完全是另一條路，所以也不會有安全上的問題。其實也是不成立的，因為openURL方式也出現(xiàn)在了本地組件間調(diào)用中，這在他第一篇文章里的組件間通信小節(jié)中就已經(jīng)說了采用openURL方式調(diào)用了，這是有可能產(chǎn)生安全問題的。而且這段話也承認(rèn)了openURL方式被用于本地組件間調(diào)用，又印證了我剛才說的第一點。
根據(jù)上面兩點，蘑菇街在openURL場景下，還是出現(xiàn)了以遠(yuǎn)程調(diào)用的方式為本地間調(diào)用提供服務(wù)的問題，這個問題我也已經(jīng)在文中論述過了。
蘑菇街在本地間調(diào)用同時采用了openURL方案和protocol - class方案，所以其實之前我指出蘑菇街本地間調(diào)用不能傳遞非常規(guī)參數(shù)和復(fù)雜參數(shù)是不對的，應(yīng)該是蘑菇街在本地間調(diào)用時如果是普通參數(shù)，那就采用openURL，如果是非常規(guī)參數(shù)，那就采用protocol - class了，這個做法對于本地間調(diào)用的管理和維護，顯而易見是不利的。。。
limboy說必須要在 app 啟動時注冊 URL 響應(yīng)者這步不可避免，但沒有說原因。我的demo已經(jīng)證實了注冊是不必要的，所以我想聽聽limboy如何解釋原因。
你的架構(gòu)圖畫錯了
按照你的方案來看，紅圈的地方是不可能沒有依賴的。。。
另外，limboy也對本文方案提出了一些看法：
認(rèn)為category在某種意義上也是一個注冊過程。
蘑菇街的注冊和我這里的category其實是兩回事，而且我無論如何也無法理解把category和注冊URL等價聯(lián)系的邏輯??
一個很簡單的事實就可以證明兩者完全不等價了：我的方案如果沒有category，照樣可以跑，就是業(yè)務(wù)方調(diào)用丑陋一點。蘑菇街如果不注冊URL，整個流程就跑不起來了～
認(rèn)為openURL的好處是可以更少地關(guān)心業(yè)務(wù)邏輯，本文方案的好處是可以很方便地完成參數(shù)傳遞。
我沒覺得本文方案關(guān)心的業(yè)務(wù)邏輯比openURL更多，因為兩者比較起來，都是傳參數(shù)發(fā)調(diào)用請求，在關(guān)心業(yè)務(wù)邏輯的條件下，兩者完全一樣。唯一的不同就是，我能傳非常規(guī)參數(shù)而openURL不能。本文方案的整個過程中，在調(diào)用者這一方是完全沒有涉及到任何屬于響應(yīng)者的業(yè)務(wù)邏輯的。
認(rèn)為protocol/URL注冊和將target-action抽象出調(diào)用接口是等價的
這其實只是效果等價了，兩者真正的區(qū)別在于：protocol對業(yè)務(wù)產(chǎn)生了侵入，且不符合黑盒模型。
我來解釋一下protocol侵入業(yè)務(wù)的原因
由于業(yè)務(wù)中的某個對象需要被調(diào)用，因此必須要符合某個可被調(diào)用的protocol，然而這個protocol又不存在于當(dāng)前業(yè)務(wù)領(lǐng)域，于是當(dāng)前業(yè)務(wù)就不得不依賴publicProtocol。這對于將來的業(yè)務(wù)遷移是有非常大的影響的。
另外再解釋一下為什么不符合黑盒模型
蘑菇街的protocol方式使對象要在調(diào)用者處使用，由于調(diào)用者并不包含對象原本所處的業(yè)務(wù)領(lǐng)域，當(dāng)完成任務(wù)需要多個這樣的對象的時候，就需要多次通過protocol獲得class來實例化多個對象，最終才能完成需求。
但是target-action模式保證了在執(zhí)行組件間調(diào)用的響應(yīng)時，執(zhí)行的上下文處于響應(yīng)者環(huán)境中，這跟蘑菇街的protocol方案相比就是最大的差別。因為從黑盒理論上講，調(diào)用者只管發(fā)起請求，請求的執(zhí)行應(yīng)該由響應(yīng)者來負(fù)責(zé)，因此執(zhí)行邏輯必須存在于響應(yīng)者的上下文內(nèi)，而不能存在于調(diào)用者的上下文內(nèi)。
舉個具體一點的例子就是，當(dāng)你發(fā)起了一個網(wǎng)頁請求，后端取好數(shù)據(jù)渲染好頁面，無論獲取數(shù)據(jù)涉及多少渠道，獲取數(shù)據(jù)的邏輯都在服務(wù)端完成，然后再返回給瀏覽器展示。這個是正確的做法，target-action模式也是這么做的。
但是蘑菇街的方案就變成了這樣：你發(fā)起了一個網(wǎng)絡(luò)請求，后端返回的不是數(shù)據(jù)，返回的竟然是一個數(shù)據(jù)獲取對象(DAO)，然后你再通過DAO去取數(shù)據(jù)，去渲染頁面，如果渲染頁面的過程涉及多個DAO，那么你還要再發(fā)起更多請求，拿到的還是DAO，然后再拿這個DAO去獲取數(shù)據(jù)，然后渲染頁面。這是一種非常詭異的做法。。。
如果說這么做是為了應(yīng)對執(zhí)行業(yè)務(wù)的過程中，需要根據(jù)中間階段的返回值來決定接下來的邏輯走向的話，那也應(yīng)該是多次調(diào)用獲得數(shù)據(jù)，然后決定接下來的業(yè)務(wù)走向，而不是每次拿到的都是DAO啊。。。使用target-action方式來應(yīng)對這種場景其實也很自然啊～
所以綜上所述，蘑菇街的方案是存在很大問題的，希望蘑菇街繼續(xù)改正
