在使用原生与h5页面进行交互的时候，会建立通道双方互传消息，但除了消息通道外，有时候还会在url后面拼接参数区分不同的业务场景，交互的方式不是那么单一，具体可能会有：
- 通过消息通道 h5 to app 或 app to h5 ，这时一般会传一个消息，包含有业务意义的事件名称eventName和相关的数data。
- h5要求app open 一个新页面并通过url 后面拼接相关参数，来传递信息。
- h5要求app在本页面加载到一个新页面，并通过url后面拼接参数，来传递信息。
同时由于业务需要，存在多个h5页面，并且每个页面都有不同的事件event。
比较简单的处理方式：
- 搭建h5 - native消息通道
- 处理好本页面跳转，还是打开一个新页面的逻辑。
- 把全部的event写到一起，通过if-else 进行判断处理，如果存在同名event，那么与url + event一起判断确定唯一性。
这样无疑是比较简单和便捷的处理方式，但这其实并不是真正便捷的方式。随着业务的迭代，每个页面会增加新的业务，同时页面也会增加，此时把event都堆积在一起，导致代码臃肿、阅读性降低，并且会加大了出错的概率，降低了可维护性。
为了解决这个问题，必须要构建一个与h5 - native交互模式匹配的交互方案，对代码进行解耦，并要求在迭代的过程中，不提高其维护成本。
这个方案的大概思路如下：
- 有多一个页面，对应应该有多个实体，每个实体对应这个页面的业务。
- 每个实体在前台的时候能接受和响应event。
- 当页面切换的时候切换对应的实体。
- 增加一个新的页面，那么就通过增加一个新的实体来匹配。这个过程中，不需要修改任何逻辑。实现OCP。
交互图：
-
事件交互流程
a.png
-
变更页面，切换
b.png
-
扩展多个页面的逻辑
c.png
通过webViewProcess 完成事件的转发，完成eventDelegate的切换。
使用原型模式思想，创建一个新的delegate类是，要实现相关协议，并把元类对象注册到builder单例中，用于后面根据url匹配创建。
APIWebEventDelegateProtocol
@protocol APIWebEventDelegateProtocol <NSObject>
@optional
/*native to h5 event; can be register notifiction*/
- (void)webEventSetupAction;
/*do somthing like native to h5 when webView perload*/
- (void)webPerLoadAction;
/*revice from h5 ,native respod*/
- (void)receiveWebMsg:(NSDictionary *)msg;
/*if respond wiht url*/
- (APIWebEventDelegateRespondType)respodWithUrl:(NSString*)url;
/*handle with url*/
- (void)handleWithUrl:(NSString*)url;
@end
@implementation APICameraWebEventDelegate
#pragma mark -
+ (void)load
{
//注册
[[APIWebDelegateBuilder shareInstance]registerWithClass:self.class];
}
...
@end
APIWebDelegateBuilder
@interface APIWebDelegateBuilder : NSObject
+ (instancetype)shareInstance;
- (void)registerWithClass:(Class)class;
///生成合适的webDelegate
- (nullable id)webDelegateWithUrl:(NSString *)url param:(NSDictionary *)param;
@end
网友评论