对 iOS 组件化和路由实现各开源方案的比较

1 JLRoutes 是将 url 转换为数组保存，匹配时遍历数组，比较个对象，返回数组各部分；
优点：url 的全局统一处理，灵活实现各页面的跳转；缺点： URL 遍历低效；

2 HHRoutes 是将 url 转换为层层字典保存，匹配Controller 成功后，返回带有参数的 Controller 实例；也可以匹配 Block;
优点：匹配高效，实现简单；缺点：和ViewController耦合严重；

3 MGJRouter 采用 HHRoutes 字典的存储方式，部分实现了 JLRoutes 的优点，比如注册全局处理url的方式; open 时可以传递参数 userinfo, completionblock等；可以通过 #define 宏的方式，统一管理 URL；各组件间通过 protocol 的方式，由组件的入口Entity实现协议方法，其他组件调用时，直接通过 protocol 为key 获取 Entity；
优点：借鉴了 JLRoutes 和 HHRoutes 的优点，可以实现页面间跳转；缺点：URL实现跳转，存在硬编码；

5 CTMediator 以 CTMediator 为桥梁，通过下面的方法，来实现不同模块间的调用：

- (id _Nullable )performTarget:(NSString * _Nullable)targetName action:(NSString * _Nullable)actionName params:(NSDictionary * _Nullable)params shouldCacheTarget:(BOOL)shouldCacheTarget;

在运行时调用其他模块的实现方法；模块暴露的接口通过 Category 来实现，其中可以容错；Category由模块开发者维护；
优点： 模块代码无侵入，十分灵活，脚手架脚本也很有用；缺点：Category 通过 String 识别模块和方法，是硬编码方式，编译期无法查错；

6 BeeHIive 通过protocol 实现各模块间的解耦, 使用前需要注册到 BHServiceManager, 使用时通过 protocol 作为key 进行寻找，然后调用 protocol 中的方法，具体实现由模块负责； BeeHive中各Module的基协议，规定了 module 的生命周期，可以将各个模块看做一个单独的 App，各模块单独负责事件的处理和协议的实现；BeeHive也支持注册 URL, 通过 URL 进行页面间的跳转；
优点：实现比较全面；缺点：采用 protocol 限定了各模块的实现，对代码侵入较多。工程复杂，人数较多可以采用；

结论： 最好的方案要根据实际情况，适合的才是最好的；