共计 1447 个字符，预计需要花费 4 分钟才能阅读完成。
背景
记得四年前 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 组件模板，让你的开发更简略！
