本文将介绍下主流的三种组件化方案,并对比分析各自的优缺点。
Target Action
主要思路
- 抽离业务逻辑
- 通过中间层进行调用
- 中间层使用Runtime反射
缺点
- 硬编码
- 中间层容易臃肿<可以用分类做拆分>
- performSelector 方法传参有限
代码实现
.h文件
1 |
|
.m文件
1 | @implementation BPMediator |
调用<控制器1>
1 | [self.navigationController pushViewController:[BPMediator twoViewControllerWithParam:@"Target Action"] animated:YES]; |
URL Scheme
主要思路
- 使用URL处理本地的跳转
- 通过中间层进行注册和调用
- 注册表无需使用反射
缺点
- 具体参数不透明
- 非懒加载
- 注册表的维护
代码实现
.h文件
1 |
|
.m文件
1 |
|
注册URL<控制器2>
1 | + (void)load { |
调用URL<控制器1>
1 |
|
Protocol Class
主要思路
- 增加 Protocol Wrapper 层
- 中间件返回 Protocol 对应的 Class
- 解决硬编码的问题
缺点
同URL Scheme
代码实现
.h文件
1 |
|
.m文件
1 |
|
遵守、实现、注册Protocol <控制器2>
1 | + (void)load { |
调用Protocol <控制器1>
1 |
|
总结
这三种方案各有优劣。
在实际的开发中,结合当前的业务情况,有可能采用多种方案。要根据当前的需求细节和团队开发能力,选择合适的方案。