组件化方案对比

目前iOS组件化方案主要有三种；

• URL Scheme
• Protocol Class
• Target Action

URL Scheme 方案

实现方式：

在启动时，注册组件提供的服务（注册URL以及关联服务Block），然后在使用时，通过URL直接调用（openURL）；

• 使用URL处理本地跳转逻辑
• 注册组件，内存中维护URL注册服务

优点：

• 统一了不同平台的客户端在跳转上的不一致
• 处理网页跳转上较为方便

缺点：

• url参数受限（例如非字符串类型，UIImage，XXModel，NSData等）
• 业务分散，耦合多
• 组件很多的情况下，可能会影响到内存

Protocol Class方案

实现方式：

通过Protocol定义服务接口，组件通过实现该接口来提供服务，最终的实现就是将Protocol和Class映射在一起，同时在内存中保存一张映射表，使用的时候，通过Protocol去获取Class对应的服务。

• 增加 Protocol Wrapper（包装） 层
• 中间件返回 Protocol 对应的 Class
• 解决硬编码的问题

优点：

• 协议接口规范，遵循依赖反转原则

缺点：

• 缺少统一调度层，组件方法调用分散，难于集中管理（团队规模大，架构管控越重要）
• 架构的灵活性不够高

Target Action方案

实现方式：

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

首先每个模块需要配置Target和Category，其中Target是每个组件对应一个或者多个Target，Category是中间层Mediator的分类，使用分类的目的是为了让Mediator的业务代码分离，从而降低Mediator中的依赖和耦合性。
那么中间层Mediator是如何找到并调用组件的呢？这里正是利用了runtime的反射机制，在Category中找到对应Target以及调用Target对应的Action。

CTMediator正是采用的Target Action方案，巧妙的使用了cocoaTouch提供的反射机制，方法签名与命令模式，简单又完美的解决了组件间的解耦问题。

• 抽离业务层逻辑
• 提供由中间层调用逻辑
• 中间层实现上使用Runtime反射

优点：

• 解耦，只存在组件依赖中间层（单向依赖）
• 利用 Category 可以明确声明的接口，进行编译检查
• 统一处理了所有组件间调用入口，方便管理

缺点：

• 每个组件的Category对应一个Target，Category中的Action对应Target中的Action。（此类的代码量很多）
• 有硬编码的问题，各种定义的string