"一个组件要有一个插头和一个插座" ---- 达拉崩吧斑得贝迪卜多比鲁翁
组件解耦交互在项目中的应用场景(注:"我"代表一个组件,"你"代表另外一个组件)
- 场景一(接口):
- 实现在我这里;
- 暴露API给你,在你需要的时候调用;
- 场景二(广播):
- 调用在我这里;
- 当我做出特定动作的时候会调用相应的方法;
- 而如果你需要响应我的动作,那么你需要实现对应的方法
一、URL解耦
-
思路
URL Scheme解耦的思路很简单:
- 通过自定义Scheme来做URL拦截
- 拦截后解析URL中携带的参数
- 根据解析后的参数,通过配置文件查询映射模块、映射类
- 最终调起映射模块、映射类特定的方法
- 其中通过Context上下文缓存组件交互方法的返回数据,通过completeBlock回调上下文,实现组件间数据回传交互
-
关键代码解读
-
创建映射配置文件
- 外部通过自定义Scheme来统跳方法
- 统跳方法内部解析Scheme,通过配置文件将方法分发到对应组件
- 解析url:
-(void)openUrl:params:
- 进入组件:
-(void)jumpToModule:pageId:context:
- 查找组件:
-(void)componentWithName:
- 读取组件类(初始化时执行):
-(void)loadAllComponnet
- 进入页面:
-(void)jumpPageWithID:context:callBack:
- 查询页面:
-(void)pageWithID:context:
-
对应组件内部映射方法被调起
- 查找组件:
- 解析url:
-
-
评价
- 可以实现组件间解耦
- 配置文件以字符串形式映射,可读性查,多组件维护成本高
- 不符合项目初衷
二、默认实现类解耦
-
前言
- Swift语法出现后,我们发现官方已经支持protocol方法的默认实现,而OC并不支持
-
@defs()
是Object-C保留关键字,但在语法迭代过程中已经接近废弃,但在N年前,ProtocolKit使这个关键字重新复活,使用ProtocolKit配合@defs()
关键字则成为了"默认实现类"解耦的核心思路
-
思路
- 定义协议类,下沉到协议层
- 定义实现类,保留在组件内,同时通过@defs(
<protocol>
)生成中间类 - 外部import协议类,并遵守协议后,即可使用
self
来调用协议中的API
(protocolKit:旧版为动态添加imp来实现方法注入,新版为消息转发来实现方法间接调用)
-
关键代码解读
- protocolKit重定义了OC保留的关键字
defs
,当使用@defs(<protocol>
)配合@end修饰一个协议后,相当于创建了一个中间类的声明和实现
- 而protocolKit指定了一个次级函数入口,来为所有遵守
<protocol>
的类动态插入了中间类所定义的方法实现,这里会影响性能
-
创建协议类,下沉到协议层
- 定义实现类,在其中使用@defs(
<protocol>
)生成中间类
-
import协议
- 使用
self
调用协议中的API实现组件间交互
- protocolKit重定义了OC保留的关键字
-
评价
- 可以实现组件间解耦
- 轻量级,只有一个类的代码量
- 性能较低,作者后续将实现方式从"注入实现"调整为"消息转发"后性能有提升
- 可读性差,所有协议方法均以self调用
- 不符合项目初衷
三、协议式解耦
-
前言
-
思路
- 创建BeeHiveProtocol下沉到协议层,定义组件API
- 创建实现类,存放在组件内部,外部使用BeeHiveImpl通过泛型的方式来调用BeeHiveProtocol中定义的API
- 创建serviceClient下沉到协议层,定义组件广播
- 组件内部使用NOTIFY_SERVICE_CLIENT()发送广播,组件外部根据需要,来是想广播协议中定义的方法
-
实际应用
-
BeeHive协议API:
-
创建协议类,下沉到协议层
-
组件内部创建实现类
-
外部import协议后使用泛型调用
-
-
ServiceCenter广播:
-
创建协议类,下沉到协议层
-
组件内部通过NOTIFY_SERVICE_CLIENT()调用
- 外部import协议后,监听-实现协议方法-移除监听
-
遵守协议
-
监听与移除
-
方法实现
-
-
-
-
评价
- 可以实现组件间解耦
- 无性能问题
- 可读性好
- 符合项目初衷
- BeeHive重量级