日常開發中，你可能會遇到這樣的問題，各個模塊相互引用，相互依賴，直觀表現就是引入了很多頭文件，很混亂，比如登錄、收藏、消息模塊間的相互調用，這樣的代碼顯然不能符合 低耦合、高內聚、職責單一邏輯清晰的代碼設計原則。
為此，我們可能需要使用一個 調度中心 去管理這些模塊，有了這個調度中心，每個模塊就不需要依賴其它模塊，不用導入其它模塊的頭文件了，只需要調度中心關心每個模塊的調度，其它模塊只需要關心怎么調用和調用后反饋的結果，這個調度中心就是 路由(Router), 這種設計模式也被稱為 中介者模式。
下面我將從以下幾個方面來介紹一下我學習到的關于路由的知識：
- 路由是什么
- 路由和組件化的關系
- 業界常見的三種解決方案
- 總結
路由是什么
路由簡單來說就是一個中轉站，輸入一條數據，然后按照內部的一定規則，處理這條數據，最后輸出特定格式的新數據。
1.網絡層
從網絡的角度來說，路由就是指路由器從一個接口收到數據包，根據數據路由包的目的地址進行定向并轉發到另一個接口的過程。
2.服務器端
從服務器角度來說，當接收到客戶端發來的 HTTP 請求時，會根據請求的URL，來找到相應的映射函數，然后執行該函數，并將函數的返回值發送給客戶端。 在WEB開發中，路由就是URL到函數的映射，在WEB開發中，Route 是指根據URL找到處理這個URL的類和函數，Router 可以理解為一個容器，或者說是一種機制，它管理了一組Route
3.移動端
從移動端的角度來說，就是把URL映射到相應的類上，iOS中的路由不是僅僅做頁面跳轉的，只是用的最多的地方，主要是因為可以解耦頁面跳轉的邏輯，它可以中轉的不僅僅是 Controller還可以是其它對象,比如 UIImage ...
路由和組件化的關系
路由是一個很好的解耦的方案，它可以為各個組件之間調用提供遍歷，沒有路由，組件化也是可以用的。
業界常見的三種解決方案
1.Url-scheme注冊(MGJRouter)
iOS系統中默認是支持 url scheme方式的，例如可以在瀏覽器中輸入： weixin:// 就可以打開微信應用。自然在APP內部也可以通過這種方法來實現組件之間的路由設計。
這種方式實現的原理是在APP啟動的時候，或者是向以下實例中的每個模塊自己的load方法里面注冊自己的斷鏈（url）,以及對外提供服務(Block)，通過url-scheme標記好，然后維護在url-router里面。 url-router中保存了各個組件對應的url-scheme,只要其它組件調用了 open url 的方法，url-router就會去根據url去查找對應的服務并執行，詳見demo。
1.1 URL的命名規范
遵循網上通用的 URI（web service模式的資源通用表示方式） 的格式，例如 appscheme://path ：ctd://home/scan
1.2 常見案例
1.2.1 JLRoutes git 上 star 最多的一個開源庫
本質可以理解為保存一個全局的map，key是url,value是對應存放的block數組，url和block都會常駐在內存中，當打開一個url時，GLRoutes就可以遍歷這個全局的map，通過url來執行對應的block。
1.2.2 routable-ios
1.2.3 HHRouter
1.2.4 MGJRouter
蘑菇街的技術團隊開源的一個router，特點是使用簡單方便，JLRoutes的問題主要在于查找url的實現不夠高效，通過遍歷而不是匹配。還有就是功能偏多。HHRouter的url查找是基于匹配，所以會更高效，MGJRouter也是采用的這種方法，但它和viewcontroller綁定地過于緊密，一定程度上降低了靈活性。于是就有了 MGJrouter, 從數據結構上看它和 HHRouter是一樣的。
蘑菇街方案不好的地方：
URL注冊對于實施組件化是完全沒有必要的，拓展性和可維護性都降低；- 基于
Open-url的方案的話，有一個致命缺陷：非常規對象無法參與本地組件間調度；但是可以通過傳遞parms來解決，但是這個區分了遠程調用和本地調用的接口；- 模塊內部是否仍然需要使用
URL去完成調度？是沒有必要的，為啥要復雜化？- 當組件多起來的時候，需要提供一個關乎
URL和服務的對應表，并且需要開發人員對這樣一個表進行維護;- 這種方式需要在APP啟動時，每個組件需要到路由管理中心注冊自己的
URL及服務，因此 內存中需要保存這樣一份表，當組件多起來以后就會出現一些內存的問題- 混淆了本地調用和遠程調用，它們的處理邏輯是不同的，正確的做法應該是把遠程調用通過一個中間層轉化成本地調用，如果把兩者混為一談，后期可能會出現無法區分業務的情況。比如對于組件無法響應的問題，遠程調用可能直接顯示一個
404頁面，但是本地調用可能需要做其它處理。如果不加以區分，那么就無法完成這種業務要求。 遠程調用只能傳遞被序列化JSON的數據，像UIImage這樣非常規的對象是不行的，所以如果組件接口要考慮遠程調用，這里的參數與就不能是這類非常規對象
2.利用Runtime實現的target-action方式（CTMediator）- 推薦
相較于url-scheme的方式進行組件間的路由，runtime的方式借助了OC運行時的特征，實現了組件間服務的自動發現，無需注冊即可實現組件間的調用，因此，不管從維護性、可讀性、擴展性來說，都是一個比較完美的方案， 詳見demo。
原理：
傳統的
中介者模式，這個中間件Mediator會依賴其它組件，其它組件也會依賴mediator, 但是能不能讓mediator不在依賴組件，各個組件之間不再依賴，組件間調用只依賴中間者mediator？
casa 大神是這樣優化的：
利用target-action的方式，創建一個taget的類，里面定義了一些action方法，這些方法的結果是返回一個controller或其它object，再給中間件CTMedator添加一個分類方法,定義組件外部可調用的方法接口，內部實現方法perform：target：action的方法，主要通過runtime中的NSClassFromString獲取target類和NSSelectorFromString獲取方法名，這樣就可以執行先去創建的target類中的方法得到返回值，再通過分類中的方法傳值出去，完美解決~
3.protcol-class注冊
通過協議和類綁定，核心思想和代理傳值是一樣的，遵循協議，實現協議中的方法，詳見demo。
主要思路
1、創建一個頭文件 CommonProtocol.h ，里面存放各個模塊提供的協議。在各個模塊依賴這個頭文件，實現協議的方法。
2、創建一個中間類 ProtocolMediator, 提供模塊的注冊和獲取模塊的功能（其實就是將類和協議名進行綁定，放在一個字典里，key是協議名字符串，value是類）。
3、在各個模塊中實現協議,核心代碼如下：
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];
參考文章
總結
通過這次對路由方案的研究，認識到了自己對系統架構方面的認識還是太少，以前并沒有認真考慮怎么去設計一個好代碼，我們需要的事寫一些優質代碼，牢記 低耦合、高內聚、職責單一邏輯清晰，不能甘心做碼農，只知道堆代碼！??！
本文Demo地址：點我 CXRouterDemo
