iOS路由最佳選擇是什麼
背景
記得四年前iOS路由開始盛行，當時比較有名的是蘑菇街的，後來CTMediator寫了幾篇文章把蘑菇街批的體無完膚，導致我後來寫新項目用了CTMediator，那一堆組件創建的叫一個酸爽啊！再後來陸續出現了HHRouter、JLRoutes等；面對這麼多優秀的第三方路由，我們如何選擇？是否需要重造輪子？
個人思考
無論是路由還是工程架構都需要根據實際項目來選擇，比如你的工程就是小工程，然後還各種設計模式，這就會導致過度設計，本來一個小船就能搞定的事情你卻動用了航空母艦；過度設計往往是一個業務研發過渡到架構師常犯的錯誤。對於大項目前期一定要考慮好架構，最少便於後期迭代，這時候選擇什麼路由以及基礎組件怎麼設計就關係到了未來道路是坎坷還是一帆風順。
什麼架構才適合自己的項目呢？以我的理解，中小型項目一定是使用cocoapod等組件管理工具來管理的，模組間低耦合是硬要求；一些第三方和獨立的功能都用獨立組件管理，一些上層邏輯可以暫時全部放主工程，後期能夠逐漸優化；路由的選擇可以是任何一個第三方，無論target-action還是protocol，能解耦夠用即可；對於大型項目，主工程就應該是一個殼工程，只負責整個項目的配置和組件的配置，除了配置不應該有任何業務邏輯，路由的選擇可以是自造輪子也可以使用優秀第三方，工程也一定是組件化；這種大型項目一般公司也是有實力的，有必要專門的架構組還處理架構的維護和運維，打造一套特有的CI/CD；甚至APS和APM系統也要打造一套，人員上配置也必然是後台、FE、Android、iOS。
蘑菇街路由
這個路由思想比較經典，相關文章比較多，不做過多介紹
CTMediator路由 github上3.7K個星
本質上算不上是路由；路由思想的來源就是模仿web開發中的路由，路由一定是有URL的；網上基本沒有提CTMediator缺點的，不知道是我用的不對還是咋地！CTMediator在使用的時候每個組件都還有一個中間組件作為中轉（中間件），這樣組件的個數就翻倍了，每修改一個組件介面，都需要重新發布倆組件！因此用於組件化的工程中，CTMediator至少有4個缺點：
1，導致組件個數翻倍
2，導致組件發布複雜
3，維護成本變大
4，基於runtime運行時，不支援Swift
竟然有面試題這麼問：為什麼CTMediator方案優於基於Router的方案？
我覺得這種問法就有點紙上談兵了，沒有實際操作過就來做對比
JLRoutes github 5.5k個星
本人沒研究過這個路由，看關注度應該是目前最火的一個，而且一直有維護
阿里的BeeHive github 4.1k個星
本人沒深入研究過這個路由，雖然是阿里的開源庫，但是很少有公司去使用這個，更多是的學習研究，最主要的是最近四年來沒有任何更新維護
總結
對於中小型項目，可以選擇JLRoutes作為第一考慮對象，因為用的人多了，大家相互之間沒有技術壁壘。對於大型項目，可以根據自己工程自造輪子，但一定是在研究了各種路由實現之後，考慮好路由應有的功能範圍，然後開發一個更方便使用和適合公司文化的路由；使用單例對象調用url我們可以封裝到object的分類中，這樣調用會更加方便；另外可以根據項目結構，把跳轉邏輯也訂製化到路由中
更多技術文章以及iOS面試題解，請下載 iOS技術app 《逆天面經 》，每日背誦一個面試題，避免臨時抱佛腳！
另外，iOS組件開發模板大全 《資源庫》app，收集了五千多個iOS組件模板，讓你的開發更簡單！
