背景
记得四年前iOS路由开始盛行，当时比较有名的是蘑菇街的，后来CTMediator写了几篇文章把蘑菇街批的体无完肤，导致我后来写新项目用了CTMediator，那一堆组件创建的叫一个酸爽啊！再后来陆续出现了HHRouter、JLRoutes等；面对这么多优秀的第三方路由，我们如何选择？是否需要重造轮子？
个人思考
无论是路由还是工程架构都需要根据实际项目来选择，比如你的工程就是小工程，然后还各种设计模式，这就会导致过度设计，本来一个小船就能搞定的事情你却动用了航空母舰；过度设计往往是一个业务研发过渡到架构师常犯的错误。对于大项目前期一定要考虑好架构，最少便于后期迭代，这时候选择什么路由以及基础组件怎么设计就关系到了未来道路是坎坷还是一帆风顺。
什么架构才适合自己的项目呢？以我的理解，中小型项目一定是使用cocoapod等组件管理工具来管理的，模块间低耦合是硬要求；一些第三方和独立的功能都用独立组件管理，一些上层逻辑可以暂时全部放主工程，后期能够逐渐优化；路由的选择可以是任何一个第三方，无论target-action还是protocol，能解耦够用即可；对于大型项目，主工程就应该是一个壳工程，只负责整个项目的配置和组件的配置，除了配置不应该有任何业务逻辑，路由的选择可以是自造轮子也可以使用优秀第三方，工程也一定是组件化；这种大型项目一般公司也是有实力的，有必要专门的架构组还处理架构的维护和运维，打造一套特有的CI/CD；甚至APS和APM系统也要打造一套，人员上配置也必然是后台、FE、安卓、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组件模板，让你的开发更简单！