路由是一個(gè)很好的解耦的方案寸宵，它可以為各個(gè)組件之間調(diào)用提供遍歷，沒有路由，組件化也是可以用的赡译。
業(yè)界常見的三種解決方案
1.Url-scheme注冊(cè)(MGJRouter)
iOS系統(tǒng)中默認(rèn)是支持 url scheme方式的，例如可以在瀏覽器中輸入： weixin:// 就可以打開微信應(yīng)用畸悬。自然在APP內(nèi)部也可以通過這種方法來實(shí)現(xiàn)組件之間的路由設(shè)計(jì)。
這種方式實(shí)現(xiàn)的原理是在APP啟動(dòng)的時(shí)候委煤，或者是向以下實(shí)例中的每個(gè)模塊自己的load方法里面注冊(cè)自己的斷鏈（url）,以及對(duì)外提供服務(wù)(Block)，通過url-scheme標(biāo)記好修档，然后維護(hù)在url-router里面碧绞。 url-router中保存了各個(gè)組件對(duì)應(yīng)的url-scheme,只要其它組件調(diào)用了 open url 的方法，url-router就會(huì)去根據(jù)url去查找對(duì)應(yīng)的服務(wù)并執(zhí)行吱窝，詳見demo讥邻。
1.1 URL的命名規(guī)范
遵循網(wǎng)上通用的 URI（web service模式的資源通用表示方式） 的格式，例如 appscheme://path：ctd://home/scan
1.2 常見案例
1.2.1 JLRoutes git 上 star 最多的一個(gè)開源庫
本質(zhì)可以理解為保存一個(gè)全局的map院峡，key是url,value是對(duì)應(yīng)存放的block數(shù)組计维，url和block都會(huì)常駐在內(nèi)存中，當(dāng)打開一個(gè)url時(shí)撕予，GLRoutes就可以遍歷這個(gè)全局的map，通過url來執(zhí)行對(duì)應(yīng)的block蜈首。
1.2.2 routable-ios
1.2.3 HHRouter
1.2.4 MGJRouter
蘑菇街的技術(shù)團(tuán)隊(duì)開源的一個(gè)router实抡，特點(diǎn)是使用簡(jiǎn)單方便，JLRoutes的問題主要在于查找url的實(shí)現(xiàn)不夠高效欢策，通過遍歷而不是匹配吆寨。還有就是功能偏多。HHRouter的url查找是基于匹配踩寇，所以會(huì)更高效啄清，MGJRouter也是采用的這種方法，但它和viewcontroller綁定地過于緊密俺孙，一定程度上降低了靈活性辣卒。于是就有了 MGJrouter, 從數(shù)據(jù)結(jié)構(gòu)上看它和 HHRouter是一樣的掷贾。
蘑菇街方案不好的地方：
URL注冊(cè)對(duì)于實(shí)施組件化是完全沒有必要的，拓展性和可維護(hù)性都降低荣茫；- 基于
Open-url的方案的話想帅，有一個(gè)致命缺陷：非常規(guī)對(duì)象無法參與本地組件間調(diào)度；但是可以通過傳遞parms來解決啡莉，但是這個(gè)區(qū)分了遠(yuǎn)程調(diào)用和本地調(diào)用的接口港准；- 模塊內(nèi)部是否仍然需要使用
URL去完成調(diào)度？是沒有必要的咧欣，為啥要復(fù)雜化浅缸？- 當(dāng)組件多起來的時(shí)候，需要提供一個(gè)關(guān)乎
URL和服務(wù)的對(duì)應(yīng)表魄咕，并且需要開發(fā)人員對(duì)這樣一個(gè)表進(jìn)行維護(hù);- 這種方式需要在APP啟動(dòng)時(shí)衩椒，每個(gè)組件需要到路由管理中心注冊(cè)自己的
URL及服務(wù)，因此 內(nèi)存中需要保存這樣一份表蚕礼，當(dāng)組件多起來以后就會(huì)出現(xiàn)一些內(nèi)存的問題- 混淆了本地調(diào)用和遠(yuǎn)程調(diào)用烟具，它們的處理邏輯是不同的，正確的做法應(yīng)該是把遠(yuǎn)程調(diào)用通過一個(gè)中間層轉(zhuǎn)化成本地調(diào)用奠蹬，如果把兩者混為一談朝聋，后期可能會(huì)出現(xiàn)無法區(qū)分業(yè)務(wù)的情況。比如對(duì)于組件無法響應(yīng)的問題囤躁，遠(yuǎn)程調(diào)用可能直接顯示一個(gè)
404頁面冀痕，但是本地調(diào)用可能需要做其它處理。如果不加以區(qū)分狸演，那么就無法完成這種業(yè)務(wù)要求言蛇。 遠(yuǎn)程調(diào)用只能傳遞被序列化JSON的數(shù)據(jù)，像UIImage這樣非常規(guī)的對(duì)象是不行的宵距，所以如果組件接口要考慮遠(yuǎn)程調(diào)用腊尚，這里的參數(shù)與就不能是這類非常規(guī)對(duì)象
2.利用Runtime實(shí)現(xiàn)的target-action方式（CTMediator）- 推薦
相較于url-scheme的方式進(jìn)行組件間的路由，runtime的方式借助了OC運(yùn)行時(shí)的特征满哪，實(shí)現(xiàn)了組件間服務(wù)的自動(dòng)發(fā)現(xiàn)婿斥，無需注冊(cè)即可實(shí)現(xiàn)組件間的調(diào)用，因此哨鸭，不管從維護(hù)性民宿、可讀性、擴(kuò)展性來說像鸡，都是一個(gè)比較完美的方案活鹰， 詳見demo。
原理：
傳統(tǒng)的
中介者模式，這個(gè)中間件Mediator會(huì)依賴其它組件志群，其它組件也會(huì)依賴mediator, 但是能不能讓mediator不在依賴組件着绷，各個(gè)組件之間不再依賴，組件間調(diào)用只依賴中間者mediator赖舟？
casa 大神是這樣優(yōu)化的：
利用target-action的方式蓬戚，創(chuàng)建一個(gè)taget的類，里面定義了一些action方法宾抓，這些方法的結(jié)果是返回一個(gè)controller或其它object子漩，再給中間件CTMedator添加一個(gè)分類方法,定義組件外部可調(diào)用的方法接口，內(nèi)部實(shí)現(xiàn)方法perform：target：action的方法石洗，主要通過runtime中的NSClassFromString獲取target類和NSSelectorFromString獲取方法名幢泼，這樣就可以執(zhí)行先去創(chuàng)建的target類中的方法得到返回值，再通過分類中的方法傳值出去讲衫，完美解決~
3.protcol-class注冊(cè)
通過協(xié)議和類綁定缕棵，核心思想和代理傳值是一樣的，遵循協(xié)議涉兽，實(shí)現(xiàn)協(xié)議中的方法招驴，詳見demo。
主要思路
1枷畏、創(chuàng)建一個(gè)頭文件 CommonProtocol.h 别厘，里面存放各個(gè)模塊提供的協(xié)議。在各個(gè)模塊依賴這個(gè)頭文件拥诡，實(shí)現(xiàn)協(xié)議的方法触趴。
2、創(chuàng)建一個(gè)中間類 ProtocolMediator, 提供模塊的注冊(cè)和獲取模塊的功能（其實(shí)就是將類和協(xié)議名進(jìn)行綁定渴肉，放在一個(gè)字典里冗懦，key是協(xié)議名字符串，value是類）仇祭。
3披蕉、在各個(gè)模塊中實(shí)現(xiàn)協(xié)議,核心代碼如下：
Class cls = [[ProtocolMediator sharedInstance] classForProtocol:@protocol(B_VC_Protocol)];
UIViewController<B_VC_Protocol> *B_VC = [[cls alloc] init];
[B_VC action_B:@"param1" para2:222 para3:333 para4:444];
[self presentViewController:B_VC animated:YES completion:nil];
總結(jié)
通過這次對(duì)路由方案的研究，認(rèn)識(shí)到了自己對(duì)系統(tǒng)架構(gòu)方面的認(rèn)識(shí)還是太少乌奇，以前并沒有認(rèn)真考慮怎么去設(shè)計(jì)一個(gè)好代碼嚣艇，我們需要的事寫一些優(yōu)質(zhì)代碼，牢記 低耦合华弓、高內(nèi)聚、職責(zé)單一邏輯清晰困乒，不能甘心做碼農(nóng)寂屏，只知道堆代碼！！
