一、.URL路由

这也是很多iOS项目使用的通信方案，它就是基于路由匹配，或者根据命名约定，用runtime方法进行动态调用，URL路由思路采用了中间者模式.
这些动态化的方案的优点是实现简单，缺点是需要维护字符串表，或者依赖于命名约定，无法在编译时暴露出所有问题，需要在运行时才能发现错误.

思路：
App启动时实例化各组件模块，然后这些组件向MGJRouter注册URL，有时候不需要实例化，使用Class注册
当组件A需要调用组件B时，向ModuleManager传递URL，参数跟随URL以GET方式传递，类似openURL.然后由ModuleManager负责调度组件B，最后完成任务.

【优点】
极高的动态性，适合经常展开运营活动的app.例如：电商类
方便统一管理多平台的路由规则
易于适配URL Scheme

【缺点】
传参方式有限，并且无法利用编译期进行参数类型检查（所有的参数都是通过字符串转换而来）
只适用于界面模块，不适用于通用模块
参数格式不明确，是个灵活的dictionary，还需要有个地方查看参数格式
不支持storyboard
依赖于字符串硬编码，难以管理，蘑菇街为此专门做了一个后台管理这部分
无法保证所有使用的模块一定存在
解耦能力有限，URL的"注册"，"实现"，"使用"必须使用相同的字符串规则，一旦任何一方做出修改都会导致其他地方的代码失效，并且重构难度大

代表：MGJRouter(以蘑菇街)

总结：
调用皆服务，服务皆URL，维护一张路由表
在初始化app时（load方法中）加载这张路由表，由路由表决定需要做什么

二、target-action

这个方案是基于OC的runtime、category特性动态获取模块，例如通过NSClassFromString获取类并创建实例，通过performSelector+NSInvocation动态调用方法

思路：
1.利用分类为路由添加新的接口，在接口通过字符串获取对应的类
2.通过runtime创建实例，动态调用实例的方法

【优点】
利用分类可以声明接口，进行编译检查
实现方式轻量级

【缺点】
需要在mediator和target中重新添加每一个接口，模块化时代码较为繁琐
在category中仍然要引入字符串硬编码，内部使用字典传参，一定程度上也存在和URL路由相同的问题
无法保证使用的模块一定存在，target在修改后，使用者只能在运行时才能发现错误
创建过多的target类，导致target类泛滥

代表：CTMediator

总结：
target类定义跳转到那个组建，分类定义跳转的参数及回调等。
运行时解耦，消息转发时，去寻找相应的组建，进行消息转发

三、protocol匹配

1.将protocol和对应的类进行字典匹配
2.通过用protocol获取class，再动态创建实例
BeeHive借鉴了Spring Service、Apache DSO的架构理念，采用AOP+扩展App生命周期API形式，将业务功能、基础功能模块以模块方式解决大型应用中的复杂问题，并让模块之间以Service形式调用，将复杂问题切分，以AOP方式模块化服务.

核心思想:
1.各个模块间调用从直接调用对应模块，变成调用Service的形式，避免直接依赖
2.App生命周期的分发，将耦合在AppDelegate中逻辑拆分，每个模块以微应用的形式独立存在

【优点】
1.利用接口调用，实现参数传递时的类型安全
2.直接使用模块的protocol接口，无需再重复封装

【缺点】
1.用框架来创建所有对象，创建方式不同，即不支持外部传参
2.用OC的runtime创建对象，不支持Swift
3.只做了protocol和class的匹配，不支持更复杂的创建方式和依赖注入
4.无法保证所以使用的protocol一定存在对应的模块，也无法直接判断某个protocol是否能用于获取模块.

代表：BeeHive

总结：
每个模块都有对应的model(模块被不同的功能分开，每个模块都可以通过自己的服务与其他模块进行通信)，server(服务是特定模块的接口)，protocal
动态匹配协议，解析出对应的类，进行动态创建