最近在考虑是否要替换项目中的Hybrid方案，于是对比研究了下WKWebViewJavascriptBridge和目前使用的EasyJsWebView（下文用easyjs代之）。
js调用native方法流程：
1、native端：通过native端bridge的registerHandler来注册可以被js调用的方法。
[_bridge registerHandler:@"testObjcCallback" handler:^(id data, WVJBResponseCallback responseCallback) {
NSLog(@"testObjcCallback called: %@", data);
responseCallback(@"Response from testObjcCallback");
}];
注册的实现：通过bridge中的全局字典messageHandlers，以方法名为key来保存plugin方法的具体实现（block形式），等js端调用该方法时取出方法实现block并执行。
这边handler里的responseCallback是执行完native方法后给js的回调block。如何回调给js，我们后面再说。
//WKWebViewJavascriptBridge
- (void)registerHandler:(NSString *)handlerName handler:(WVJBHandler)handler {
_base.messageHandlers[handlerName] = [handler copy];
}
这与easy-js的方案不太一样，后者通过nsinvocation直接将js的调用分发到具体的对象具体的方法上。
2、js注入（初始化js端bridge、callHandler）
js注入的操作是由js端来完成的，通过双方约定好特定的src（https://bridge_loaded）来执行注入操作。这个操作由native来完成也是ok的，项目里的easyjs就是由native主动注入js。
//ExampleApp.html
function setupWebViewJavascriptBridge(callback) {
if (window.WebViewJavascriptBridge) { return callback(WebViewJavascriptBridge); }
if (window.WVJBCallbacks) { return window.WVJBCallbacks.push(callback); }
window.WVJBCallbacks = [callback];
var WVJBIframe = document.createElement('iframe');
WVJBIframe.style.display = 'none';
WVJBIframe.src = 'https://__bridge_loaded__';
document.documentElement.appendChild(WVJBIframe);
setTimeout(function() { document.documentElement.removeChild(WVJBIframe) }, 0)
}
上述代码执行完，就会触发webview的代理方法，在delegate中判断是否是https://bridge_loaded开头的URL，是则进行js注入。后续的js调用native方法，也是在这个delegate中去进行处理的。
//WKWebViewJavascriptBridge
- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler {
if (webView != _webView) { return; }
NSURL *url = navigationAction.request.URL;
__strong typeof(_webViewDelegate) strongDelegate = _webViewDelegate;
if ([_base isWebViewJavascriptBridgeURL:url]) {
if ([_base isBridgeLoadedURL:url]) {
[_base injectJavascriptFile];//js注入
} else if ([_base isQueueMessageURL:url]) {
[self WKFlushMessageQueue];//js调用native方法处理
} else {
[_base logUnkownMessage:url];
}
decisionHandler(WKNavigationActionPolicyCancel);
return;
}
if (strongDelegate && [strongDelegate respondsToSelector:@selector(webView:decidePolicyForNavigationAction:decisionHandler:)]) {
[_webViewDelegate webView:webView decidePolicyForNavigationAction:navigationAction decisionHandler:decisionHandler];
} else {
decisionHandler(WKNavigationActionPolicyAllow);
}
}
callHandler就是js端 调用native方法的 函数。也是在js注入的操作中一并声明的，本质上就是生成一个callbackId，然后通过修改iframe的src来触发webview回调。
注意这里用一个全局的responseCallbacks字典来保存每一个callHandler的callback，key是拼装好的唯一值callbackId，这个callbackId也会传给native，等native执行完方法后再通过这个callbackId在js环境取出callback执行。
//WebViewJavascriptBridge_JS
function callHandler(handlerName, data, responseCallback) {
if (arguments.length == 2 && typeof data == 'function') {
responseCallback = data;
data = null;
}
_doSend({ handlerName:handlerName, data:data }, responseCallback);
}
function _doSend(message, responseCallback) {
if (responseCallback) {
var callbackId = 'cb_'+(uniqueId++)+'_'+new Date().getTime();
responseCallbacks[callbackId] = responseCallback;
message['callbackId'] = callbackId;
}
sendMessageQueue.push(message);//把数据插入数组
messagingIframe.src = CUSTOM_PROTOCOL_SCHEME + '://' + QUEUE_HAS_MESSAGE;//触发webview回调
}
这边只是触发了webview的delegate，那么js调用native方法的数据是怎么传过去的呢？
注意同时执行的这句：sendMessageQueue.push(message)，将拼装好的数据存入全局的数组。
native收到js发起的方法调用之后，再通过evaluateJavaScript:方法执行js端的_fetchQueue()去取出之前存入的message数据。这样就顺利的拿到了方法调用的名称和参数。
这边有个小疑问：为什么不像easyjs那样直接把方法的信息拼装在URL后面直接传递给webview，而要绕这一步？
为了安全？为了更少的暴露参数？有知道的小伙伴可以告诉我一下～
3、native接收执行
//WKWebViewJavascriptBridge
- (void)WKFlushMessageQueue {
[_webView evaluateJavaScript:@"WebViewJavascriptBridge._fetchQueue();" completionHandler:^(NSString* result, NSError* error) {
if (error != nil) {
NSLog(@"WebViewJavascriptBridge: WARNING: Error when trying to fetch data from WKWebView: %@", error);
}
[_base flushMessageQueue:result];
}];
}
//WebViewJavascriptBridge_JS
function _fetchQueue() {
var messageQueueString = JSON.stringify(sendMessageQueue);
sendMessageQueue = [];
return messageQueueString;
}
拿到了方法名和参数，通过方法名取出第一步保存在messageHandlers中的方法实现block。
WVJBHandler handler = self.messageHandlers[message[@"handlerName"]];
执行这个handler即可。
//WebViewJavascriptBridgeBase
//删除部分非关键代码
- (void)flushMessageQueue:(NSString *)messageQueueString{
id messages = [self _deserializeMessageJSON:messageQueueString];
for (WVJBMessage* message in messages) {
WVJBResponseCallback responseCallback = NULL;
NSString* callbackId = message[@"callbackId"];
if (callbackId) {
responseCallback = ^(id responseData) {//js回调的实现
if (responseData == nil) {
responseData = [NSNull null];
}
WVJBMessage* msg = @{ @"responseId":callbackId, @"responseData":responseData };
[self _queueMessage:msg];//拼装数据，回调js
};
} else {
responseCallback = ^(id ignoreResponseData) {
// Do nothing
};
}
WVJBHandler handler = self.messageHandlers[message[@"handlerName"]];
if (!handler) {
NSLog(@"WVJBNoHandlerException, No handler for message from JS: %@", message);
continue;
}
handler(message[@"data"], responseCallback);
}
}
4、native执行完成、回调JS
至此，js调用native方法已经成功被native响应并执行，那么native执行完之后具体是怎么告诉js端结果的？上图可以清晰的看到由responseCallback代码块中的_queueMessage:方法告诉js端结果。
那么我们来看一下_queueMessage:最终做了什么。
//WebViewJavascriptBridgeBase
- (void)_queueMessage:(WVJBMessage*)message {
if (self.startupMessageQueue) {
[self.startupMessageQueue addObject:message];
} else {
[self _dispatchMessage:message];
}
}
- (void)_dispatchMessage:(WVJBMessage*)message {
NSString *messageJSON = [self _serializeMessage:message pretty:NO];
//删除部分代码
NSString* javascriptCommand = [NSString stringWithFormat:@"WebViewJavascriptBridge._handleMessageFromObjC('%@');", messageJSON];
if ([[NSThread currentThread] isMainThread]) {
[self _evaluateJavascript:javascriptCommand];
} else {
dispatch_sync(dispatch_get_main_queue(), ^{
[self _evaluateJavascript:javascriptCommand];
});
}
}
是的，最终还是绕回js环境，执行WebViewJavascriptBridge._handleMessageFromObjC('%@')方法。
function _handleMessageFromObjC(messageJSON) {
_dispatchMessageFromObjC(messageJSON);
}
function _dispatchMessageFromObjC(messageJSON) {
if (dispatchMessagesWithTimeoutSafety) {
setTimeout(_doDispatchMessageFromObjC);
} else {
_doDispatchMessageFromObjC();
}
function _doDispatchMessageFromObjC() {
var message = JSON.parse(messageJSON);
var messageHandler;
var responseCallback;
if (message.responseId) {
responseCallback = responseCallbacks[message.responseId];
if (!responseCallback) {
return;
}
responseCallback(message.responseData);
delete responseCallbacks[message.responseId];
} else {
//删减
}
var handler = messageHandlers[message.handlerName];
if (!handler) {
console.log("WebViewJavascriptBridge: WARNING: no handler for message from ObjC:", message);
} else {
handler(message.data, responseCallback);
}
}
}
}
最终还是通过native传过来的responseId（即js调用native时的callbackId）取出callHandler时存入的responseCallback并执行。执行完很严谨的将这个callback从全局字典里删除。
那么，WKWebViewJavascriptBridge和easyjs究竟有什么差别？
基础原理一样：
都是通过修改iframe的src来触发webview的代理方法（decidePolicyForNavigationAction:），以达到调用native方法的目的。
具体实现不同：
easyjs是将所有的plugin类及其方法注册到window上，然后所有的plugin方法都指向同一个实现EasyJS.call，在这个方法中去修改iframe的src来触发调用，最终的调用是通过NSInvocation分发到native的具体类具体方法中。
window.naviPlugin.setTitle(jsonStr); --> [naviPlugin实例 setTitle];
WKWebViewJavascriptBridge是由native自行注册的方式，将native方法的实现block保存在全局，统一通过WebViewJavascriptBridge.callHandler来发起调用，callHandler中去修改iframe的src来触发调用，最终的调用是取出注册时保存的native方法实现block执行。
相比而言，easyjs在分类方面做的更好，不同的plugin方法分散在不同的plugin类里，非常清晰。但当plugin方法太多时，在window上遍历注册时的消耗也就随之变大了。
WKWebViewJavascriptBridge的注册消耗相对较小，每注册一个方法，只需在全局的字典里加一下该方法的实现。不涉及与js的交互、不涉及诸多的转换操作。而缺点也显而易见了，没有进行分类，不过这一点是存在改造的可能性的，如果未来真的要引入到项目里，那还是得经过大规模的改造才行。
目前还没有很清晰的改造思路，不过有一点可以确认：我们基于WKWebViewJavascriptBridge的任何改造方案，前端都得动一动，希望能够让兄弟部门的改动最小化吧。
目前是这样：window.naviPlugin.setTitle(jsonStr);
改造后可能：bridge.callHandler(plugin方法, jsonStr, callback);
当然了，这一切只是设想，具体是否需要改造、改造的收益如何、最终如何改造等都还需要进一步的学习和研究。
