写一个易于维护使用方便性能可靠的Hybrid框架（二）—— 插件化
《写一个易于维护使用方便性能可靠的Hybrid框架（一）—— 思路构建》
《写一个易于维护使用方便性能可靠的Hybrid框架（二）—— 插件化》
《写一个易于维护使用方便性能可靠的Hybrid框架（三）—— 配置插件》
《写一个易于维护使用方便性能可靠的Hybrid框架（四）—— 框架构建》
前言
继上一篇以后，我反复思来想去，我下一篇该怎么写，那么想法有了，我应该怎么去落实，框架在代码层面我要怎么设计，怎么样才能使用起来尽量的方便，那么好吧，我深深的以为，上一篇我给本身挖了个大坑，最近的思想一直依托于Cordova框架的设计模式，说实话想跳出来很难，我真的很难很难想出一个比它插件化部分更好设计，因此插件化这一块，我依旧延续Cordova思想，精简掉平时工做用不到的部分，偏向于更方便的方向设计，因此，今天我写了个简短的demo，基本实现了js和native端的通信，下面依托demo来写个人Hybrid框架第二篇，先聊聊native端插件化部分。html
正题
在框架使用层面和js-bridge方面，依旧延续上篇提到的两篇博文，也就是框架内不提供webView，webView由使用者本身实现，webView的一切我不关心，我只负责给你的webView提供Hybrid能力。第二点是通讯上基于WKWebView的addScriptMessageHandler方式，弃用UIWebView的URL拦截方式。前端
仍是简单说一下WKWebView的addScriptMessageHandler的通讯问题，只是简单介绍下就不详细讲解它的通讯过程了，WKWebView初始化时，有一个参数叫configuration，它是WKWebViewConfiguration类型的参数，而WKWebViewConfiguration有一个属性叫userContentController，它又是WKUserContentController类型的参数。WKUserContentController对象有一个方法-addScriptMessageHandler:name:，第一个参数是userContentController的代理对象，第二个参数对应着js端postMessage的对象(本篇看完你就明白了没啥说的)。既然设置了代理对象，固然还要实现它的代理方法，也就是WKScriptMessageHandler协议提供的userContentController:didReceiveScriptMessage:函数，有了他俩，咱们就能够进行通讯了，WKWebView通讯就是这么简单。java
先看一下个人Hybrid框架是怎么使用的，固然思想仍是基于上篇提到的大佬，直接看代码吧：web
#import "ViewController.h"
#import <WebKit/WebKit.h>
#import "SHRMWebViewEngine.h"
@interface ViewController ()<WKNavigationDelegate>
@property (strong, nonatomic) WKWebView *webView;
@end
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
WKWebViewConfiguration *configuration = [[WKWebViewConfiguration alloc] init];
WKPreferences *preferences = [WKPreferences new];
preferences.javaScriptCanOpenWindowsAutomatically = YES;
preferences.minimumFontSize = 40.0;
configuration.preferences = preferences;
self.webView = [[WKWebView alloc] initWithFrame:self.view.frame configuration:configuration];
/***/
SHRMWebViewEngine *jsBridge = [[SHRMWebViewEngine alloc] init];
jsBridge.delegate = self;
[jsBridge bindBridgeWithWebView:self.webView];
/***/
NSString *urlStr = [[NSBundle mainBundle] pathForResource:@"index.html" ofType:nil];
NSURL *fileURL = [NSURL fileURLWithPath:urlStr];
if (@available(iOS 9.0, *)) {
[self.webView loadFileURL:fileURL allowingReadAccessToURL:fileURL];
} else {
// Fallback on earlier versions
}
[self.view addSubview:self.webView];
}
@end
复制代码
这其实应该是框架使用者要编写的代码，看上去很常规，中间多了三行代码，SHRMWebViewEngine *jsBridge = [[SHRMWebViewEngine alloc] init];jsBridge.delegate = self;[jsBridge bindBridgeWithWebView:self.webView];，实际上这三行代码就让你的webView具备了Hybird的能力了，用起来是否是很方便，其实这没啥说的，这个思想也是以前大佬提过的了，我就当是作了个总结吧。那再经过代码看一下我在里面都作了什么吧。设计模式
#import "SHRMWebViewEngine.h"
#import "SHRMWebViewDelegate.h"
#import "SHRMWebViewHandleFactory.h"
@interface SHRMWebViewEngine ()
@property (nonatomic, strong) SHRMWebViewDelegate *webViewDelegate;
@property (nonatomic, strong) SHRMWebViewHandleFactory *webViewhandleFactory;
@end
@implementation SHRMWebViewEngine
- (instancetype)init {
if (self = [super init]) {
_webViewhandleFactory = [[SHRMWebViewHandleFactory alloc] initWithWebViewEngine:self];
_webViewDelegate = [[SHRMWebViewDelegate alloc] initWithWebViewEngine:self];
}
return self;
}
- (void)bindBridgeWithWebView:(WKWebView *)webView {
self.webView = webView;
if (![_delegate conformsToProtocol:@protocol(WKUIDelegate)]) {
self.webView.UIDelegate = _webViewDelegate;
}
if (![_delegate conformsToProtocol:@protocol(WKNavigationDelegate)]) {
self.webView.navigationDelegate = _webViewDelegate;
}
webView.configuration.userContentController = [[WKUserContentController alloc] init];
[webView.configuration.userContentController addScriptMessageHandler:self name:@"SHRMWKJSBridge"];
}
- (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message {
if ([message.body isKindOfClass:[NSArray class]]) {
[_webViewhandleFactory handleMsgCommand:message.body];
}
}
#pragma mark - SHRMWebViewProtocol
- (void)sendPluginResult:(NSString *)result callbackId:(NSString*)callbackId {
NSString *jsStr = [NSString stringWithFormat:@"fetchComplete('(%@)','%@')",callbackId,result];
[self.webView evaluateJavaScript:jsStr completionHandler:^(id _Nullable result, NSError * _Nullable error) {
NSLog(@"%@----%@",result, error);
}];
}
- (void)runInBackground:(void (^)(void))block {
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), block);
}
#pragma mark - dealloc
- (void)dealloc {
[self.webView.configuration.userContentController removeScriptMessageHandlerForName:@"SHRMWKJSBridge"];
}
@end
复制代码
1.
SHRMWebViewHandleFactory对象，负责执行native端插件的调用过程，内部未来会作成工厂。bash
2.
SHRMWebViewDelegate对象，负责WKWebView的代理实现，个人思路是若是开发者没有本身实现WKWebView的代理，那么默认我会走框架内提供的代理方法，包括进度条等。网络
3.
bindBridgeWithWebView:函数作了webView的绑定和代理的绑定，主要仍是为了拿到想要得到Hybrid能力的webView。拿到这个webView，咱们就能够作接下来的通讯了。SHRMWKJSBridge为自定义的js端postMessage的对象（和上面提到的匹配上了），是jsBridge的统一入口，这个SHRMWKJSBridge一会下面还会说到，再对比下就更清楚了。架构
4.
userContentController:didReceiveScriptMessage:拿到js传递过来的参数，参数怎么传递过来的一会会粘js端的代码。框架
5.
SHRMWebViewProtocol：提供了两个接口，一个是native回调js接口，一个是开辟子线程执行耗时操做接口。经过代码能够看到native回调js使用的是evaluateJavaScript:completionHandler:函数，这是WKWebView以后提供的，自然异步执行，不须要像UIWebView那样要开发者手动处理js端回调native端的异步问题。异步
那么实际上SHRMWebViewEngine核心类目前只作了这几件事情，固然这只是我今天写的demo，后续会对代码进行优化和对通讯调优，咱们先一步一步来。
@protocol SHRMWebViewProtocol <NSObject>
/**
native call back js
@param result simulate data
@param callbackId callbackId
*/
- (void)sendPluginResult:(NSString *)result callbackId:(NSString*)callbackId;
/**
background
@param block long running
*/
- (void)runInBackground:(void (^)(void))block;
@end
复制代码
这个就是咱们刚才看到的接口定义的地方，今天一直在想，Cordova在插件处理的时候，咱们自定义插件都是须要继承自CDVPlugin基类的（没用过不要紧，就理解为一个提供了js回调native接口的基类就好了），它的回调接口实现类CDVPlugin基类里面有提供，因此它能够经过CDVPlugin基类来进行native端对js的回调。关于这一块我作了简单改造，移除了CDVPlugin基类，由于咱们的插件彻底能够不用继承任何其余的类，只须要继承自NSObject就好，仍是看代码：
@class SHRMMsgCommand;
@interface SHRMFetchPlugin : NSObject
- (void)nativeFentch:(SHRMMsgCommand *)command;
@end
@implementation SHRMFetchPlugin
- (void)nativeFentch:(SHRMMsgCommand *)command {
NSString *method = [command argumentAtIndex:0];
NSString *url = [command argumentAtIndex:1];
NSString *param = [command argumentAtIndex:2];
NSLog(@"(%@):%@,%@,%@",command.callbackId, method, url, param);
[command.delegate sendPluginResult:@"fetch success" callbackId:command.callbackId];
}
@end
复制代码
不可避免，我仍是须要SHRMMsgCommand这个对象，否则插件没法和框架构成联系。SHRMMsgCommand上面没有说干吗的，它实际上只是js传递过来的参数接受者，存储着参数信息供插件使用。command.delegate实际是id <SHRMWebViewProtocol> delegate类型的对象，由于我目前是把回调接口是如今了SHRMWebViewEngine里面，实际上这个delegate就是它。这么作的目的主要是为了解耦合，这样SHRMMsgCommand彻底没必要引用SHRMWebViewEngine的头文件了。这个就是模拟网络请求native端提供的插件，什么是插件，顾名思义，就是不跟框架产生耦合，实际上框架内是不须要引入SHRMFetchPlugin的，若是说哪天这个插件不用了，直接把这个类删了就能够了。
到这里咱们在native端的简单插件化基本实现了，js与native间基于WKWebView的通讯也实现了。这样我在js端直接调用
window.webkit.messageHandlers.SHRMWKJSBridge.postMessage(['13383445','SHRMFetchPlugin','nativeFentch',['post','https:www.baidu.com','user']]);
复制代码
就能够实现js call native了，SHRMWKJSBridge(这个到这里就很明白了吧)就是我上面定义的发送postMessage的对象，固然native回调js是须要js提供一个全局函数供给native来调用的，我在demo里面定义了一个fetchComplete函数：
function fetchComplete(id,result) {
asyncAlert(result);
document.getElementById("returnValue").value = (id) + result;
}
function asyncAlert(content) {
setTimeout(function(){
alert(content);
},1);
}
复制代码
再来看下上面回调js的代码：
- (void)sendPluginResult:(NSString *)result callbackId:(NSString*)callbackId {
NSString *jsStr = [NSString stringWithFormat:@"fetchComplete('(%@)','%@')",callbackId,result];
[self.webView evaluateJavaScript:jsStr completionHandler:^(id _Nullable result, NSError * _Nullable error) {
NSLog(@"%@----%@",result, error);
}];
}
复制代码
一目了然了吧，这样整个调用过程就结束了，固然window.webkit.messageHandlers.SHRMWKJSBridge.postMessage和fetchComplete后期咱们会把他们单独封装起来，对于前端开发者来讲只会给他们统一的调用接口和回调接口，这个后面再说。若是说只是为了简单实现功能其实到这里就能够了，可是毕竟咱们是在构建一个框架，因此这样是远远不行的，二篇就先到这吧（PS:主要是demo就写到了这，另外时候不早了得睡了）。
总结
总结一下，本篇简单实现了native端的插件化，基于WKWebView通讯的构建，框架内不提供webView的实现三个功能这与咱们上一篇的预期也是相符合的，可是远远不够，那么咱们后续第三篇再继续。那么下篇会着重介绍native端插件的可配置和js端接口的封装（这点真是难为了我这个未入门的前端了）。