Hybrid改造之WKWebViewJavascriptBridge简析（对比EasyJsWebView）

最近在考虑是否要替换项目中的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);

当然了，这一切只是设想，具体是否需要改造、改造的收益如何、最终如何改造等都还需要进一步的学习和研究。