我們要堅(jiān)信絕大部分問題，其他人早就遇到過，并且很可能有絕佳的解決方案，即使沒有，至少別人踩過的坑，我們不必再踩一次。所以對(duì)于組件化，也是一樣，我們要避免重復(fù)造輪子。于是，第一件事我們要做的就是找這個(gè)輪子。
iOS的兩個(gè)輪子：
（1）Limboy（蘑菇街）的組件化方案：
http://limboy.me/ios/2016/03/10/mgj-components.html
http://limboy.me/ios/2016/03/14/mgj-components-continued.html
（2）Casa（天貓）的組件化方案：
http://casatwy.com/iOS-Modulization.html
這兩組文章可以結(jié)合著看，非常有意思，另外底下評(píng)論的內(nèi)容更精彩，有點(diǎn)像兩個(gè)高手在擂臺(tái)上切磋，底下有一堆圍觀助威點(diǎn)贊的。
文章自己看就好，很長，內(nèi)容很豐富，甚至Casa還寫了一個(gè)Demo來論證自己的觀點(diǎn)，我們?nèi)ゴ秩【?，深入分析一下?/p>
英雄所見略同：
我們先看看兩個(gè)同學(xué)意見相同的地方：
- 組件間的通訊涉及到傳參問題，那么這個(gè)參數(shù)首先需要去Model化，否則調(diào)用者和被調(diào)用者都需要持有Model的引用，達(dá)不到解耦的目的。
(去Model化會(huì)帶來一個(gè)問題，就是參數(shù)需要以NSDcitionary的方式傳遞，勢必會(huì)影響開發(fā)效率，因?yàn)檎{(diào)用雙方需要約定好各種Key，以及Key有問題時(shí)能夠準(zhǔn)確拋出相關(guān)的異常) - 組件間通訊的參數(shù)需要分為常規(guī)（能夠使用JSON進(jìn)行序列化的對(duì)象）和非常規(guī)。
- 對(duì)于遠(yuǎn)程APP調(diào)用，都使用openUrl的方式（這個(gè)算是廢話，蘋果只支持這個(gè)），并且過程基本一致：openUrl-> parse-> target-action
求同存異
再看看兩個(gè)同學(xué)意見相左的地方：
- 發(fā)現(xiàn)服務(wù)：
Limboy采用應(yīng)用初始化，各個(gè)組件向ModuleManager注冊的方式。
Casa采用iOS runtime機(jī)制，使用Mediator+target-action方式自動(dòng)發(fā)現(xiàn)服務(wù)，免注冊化。 - 組件間通訊問題：
Limbo的方案，對(duì)于常規(guī)參數(shù)，使用openUrl方式，非常規(guī)參數(shù)使用注冊protocol的方式，通過publicProtocol暴露出需的類和方法，所有組件持有這個(gè)publicProtocol。
Casa的方案，分為遠(yuǎn)程調(diào)用和本地調(diào)用，遠(yuǎn)程調(diào)用的方式是openUrl方式，本地調(diào)用采用target-action方式，通過category將方法暴露出去，省去了注冊的這一步。 - 調(diào)用組件頁面的細(xì)節(jié)：
Limbo的方案是：調(diào)用者傳入相關(guān)參數(shù)發(fā)起調(diào)用 -> 響應(yīng)方收到調(diào)用 -> 響應(yīng)方創(chuàng)建頁面實(shí)例并pushViewController。
[MGJRouter registerURLPattern:@"mgj://detail?id=:id" toHandler:^(NSDictionary *routerParameters) {
NSNumber *id = routerParameters[@"id"];
// create view controller with id
// push view controller
}];
Casa的方案是：調(diào)用者傳入相關(guān)參數(shù)發(fā)起調(diào)用 -> 響應(yīng)方收到調(diào)用 -> 響應(yīng)方創(chuàng)建頁面實(shí)例并返回 -> 調(diào)用方拿到實(shí)例后進(jìn)行處理。
我們可以看到Limboy方案的好處是：調(diào)用方不需要關(guān)心響應(yīng)方的邏輯，只需要正確調(diào)用方法和傳遞參數(shù)即可，缺點(diǎn)是不夠靈活，如果調(diào)用方想Present而不是Push呢？而Casa的方案正好相反。
我個(gè)人更傾向Casa的方案，雖然代碼會(huì)長一些，但是清晰，對(duì)于這種跨組件的調(diào)用，清晰是第一位的，否則業(yè)務(wù)工程師很容易懵逼。
推薦另外一個(gè)同學(xué)bang（JSPatch的作者）的分析：http://blog.cnbang.net/tech/3080/
