我們要堅信絕大部分問題搓萧，其他人早就遇到過，并且很可能有絕佳的解決方案宛畦，即使沒有瘸洛，至少別人踩過的坑，我們不必再踩一次次和。所以對于組件化反肋，也是一樣，我們要避免重復(fù)造輪子踏施。于是石蔗，第一件事我們要做的就是找這個輪子。
iOS的兩個輪子：
（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é)合著看畅形，非常有意思养距，另外底下評論的內(nèi)容更精彩，有點像兩個高手在擂臺上切磋日熬，底下有一堆圍觀助威點贊的棍厌。
文章自己看就好，很長碍遍，內(nèi)容很豐富定铜，甚至Casa還寫了一個Demo來論證自己的觀點，我們?nèi)ゴ秩【戮矗钊敕治鲆幌拢?/p>
英雄所見略同：
我們先看看兩個同學(xué)意見相同的地方：
- 組件間的通訊涉及到傳參問題揣炕，那么這個參數(shù)首先需要去Model化，否則調(diào)用者和被調(diào)用者都需要持有Model的引用东跪，達(dá)不到解耦的目的畸陡。
(去Model化會帶來一個問題鹰溜，就是參數(shù)需要以NSDcitionary的方式傳遞，勢必會影響開發(fā)效率丁恭，因為調(diào)用雙方需要約定好各種Key曹动，以及Key有問題時能夠準(zhǔn)確拋出相關(guān)的異常) - 組件間通訊的參數(shù)需要分為常規(guī)（能夠使用JSON進(jìn)行序列化的對象）和非常規(guī)。
- 對于遠(yuǎn)程APP調(diào)用牲览，都使用openUrl的方式（這個算是廢話墓陈，蘋果只支持這個），并且過程基本一致：openUrl-> parse-> target-action
求同存異
再看看兩個同學(xué)意見相左的地方：
- 發(fā)現(xiàn)服務(wù)：
Limboy采用應(yīng)用初始化第献，各個組件向ModuleManager注冊的方式贡必。
Casa采用iOS runtime機制，使用Mediator+target-action方式自動發(fā)現(xiàn)服務(wù)庸毫，免注冊化仔拟。 - 組件間通訊問題：
Limbo的方案，對于常規(guī)參數(shù)飒赃，使用openUrl方式利花，非常規(guī)參數(shù)使用注冊protocol的方式，通過publicProtocol暴露出需的類和方法载佳，所有組件持有這個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)建頁面實例并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)建頁面實例并返回 -> 調(diào)用方拿到實例后進(jìn)行處理肋联。
我們可以看到Limboy方案的好處是：調(diào)用方不需要關(guān)心響應(yīng)方的邏輯威蕉，只需要正確調(diào)用方法和傳遞參數(shù)即可，缺點是不夠靈活橄仍，如果調(diào)用方想Present而不是Push呢韧涨？而Casa的方案正好相反。
我個人更傾向Casa的方案侮繁，雖然代碼會長一些虑粥，但是清晰，對于這種跨組件的調(diào)用宪哩，清晰是第一位的娩贷，否則業(yè)務(wù)工程師很容易懵逼。
推薦另外一個同學(xué)bang（JSPatch的作者）的分析：http://blog.cnbang.net/tech/3080/
