ios组件化方案对比

　　目前iOS组件化方案主要有三种；URLSchemeProtocolClassTargetActionURLScheme方案实现方式：
　　在启动时，注册组件提供的服务（注册URL以及关联服务Block），然后在使用时，通过URL直接调用（openURL）；使用URL处理本地跳转逻辑注册组件，内存中维护URL注册服务优点：统一了不同平台的客户端在跳转上的不一致
　　处理网页跳转上较为方便缺点：url参数受限（例如非字符串类型，UIImage，XXModel，NSData等）业务分散，耦合多组件很多的情况下，可能会影响到内存ProtocolClass方案实现方式：
　　通过Protocol定义服务接口，组件通过实现该接口来提供服务，最终的实现就是将Protocol和Class映射在一起，同时在内存中保存一张映射表，使用的时候，通过Protocol去获取Class对应的服务。增加ProtocolWrapper（包装）层中间件返回Protocol对应的Class解决硬编码的问题优点：协议接口规范，遵循依赖反转原则缺点：缺少统一调度层，组件方法调用分散，难于集中管理（团队规模大，架构管控越重要）架构的灵活性不够高TargetAction方案实现方式：
　　TargetAction这个方案是基于ObjC的runtime、category特性动态获取模块，例如通过NSClassFromString获取类并创建实例，通过performSelectorNSInvocation动态调用方法。
　　首先每个模块需要配置Target和Category，其中Target是每个组件对应一个或者多个Target，Category是中间层Mediator的分类，使用分类的目的是为了让Mediator的业务代码分离，从而降低Mediator中的依赖和耦合性。
　　那么中间层Mediator是如何找到并调用组件的呢？这里正是利用了runtime的反射机制，在Category中找到对应Target以及调用Target对应的Action。
　　CTMediator正是采用的TargetAction方案，巧妙的使用了cocoaTouch提供的反射机制，方法签名与命令模式，简单又完美的解决了组件间的解耦问题。抽离业务层逻辑提供由中间层调用逻辑中间层实现上使用Runtime反射优点：解耦，只存在组件依赖中间层（单向依赖）利用Category可以明确声明的接口，进行编译检查统一处理了所有组件间调用入口，方便管理缺点：每个组件的Category对应一个Target，Category中的Action对应Target中的Action。（此类的代码量很多）有硬编码的问题，各种定义的string