浅谈iOS中的WKWebView和H5之间通信及WKWebVie

大家好，今天笔者分享一下自己在项目开发中，对iOS和H5之间的通信的一些知识点。主要是针对于苹果APP混合开发中的一点点小知识。然后是对WKWebViewJavascriptBridge，这个iOS原生OC代码和H5之间的通信桥接第三方包的一些分析。
首先在这里，先说明，这篇文章iOS这块的控件用的是WKWebview。因为再iOS12之后，UIWebview因为性能不足和内存占有过大等一系列问题，Apple公司最终决定将它慢慢移出iOS的舞台。
先来大致看下WKWebview一些常规用到的代理方法：

// --------------- WKNavigationDelegate -----------------
// 请求之间，决定是否跳转网页：一般用户在点击一个链接时跳转到下一个页面之间会调用这个方法
// 重点的代理方法，拦截webView 中url的方法
- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler;

// 获取响应数据之后，决定是否跳转
- (void)webView:(WKWebView *)webView decidePolicyForNavigationResponse:(WKNavigationResponse *)navigationResponse decisionHandler:(void (^)(WKNavigationResponsePolicy))decisionHandler;

// 开始加载页面时调用
- (void)webView:(WKWebView *)webView didStartProvisionalNavigation:(null_unspecified WKNavigation *)navigation;

// 主机地址被重定向时调用
- (void)webView:(WKWebView *)webView didReceiveServerRedirectForProvisionalNavigation:(null_unspecified WKNavigation *)navigation;

// 页面加载失败时调用
- (void)webView:(WKWebView *)webView didFailProvisionalNavigation:(null_unspecified WKNavigation *)navigation withError:(NSError *)error;

// 页面加载完毕时调用
- (void)webView:(WKWebView *)webView didFinishNavigation:(null_unspecified WKNavigation *)navigation;

// 跳转失败时调用
- (void)webView:(WKWebView *)webView didFinishNavigation:(null_unspecified WKNavigation *)navigation;

// 证书验证步骤：如果需要证书验证，与使用AFN进行HTTPS证书验证是一样的
- (void)webView:(WKWebView *)webView didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * _Nullable credential))completionHandler;

//  ------- WKUIDelegate方面一个比较重要的代理 ---------------
// 在webview中使用alert函数时，需要执行这个代理，否则将无法打开
// 坏处在于，需要我们硬性执行代理方法，好处在于，可以在我们原生iOS这边自定义弹出框
- (void)webView:(WKWebView *)webView runJavaScriptAlertPanelWithMessage:(NSString *)message initiatedByFrame:(WKFrameInfo *)frame completionHandler:(void (^)(void))completionHandler

接下来笔者说一下，最基础的iOS和js之间的通信方式，在WKWebview这边主要的方法：

- (void)evaluateJavaScript:(NSString *)javaScriptString completionHandler:(void (^ _Nullable)(_Nullable id, NSError * _Nullable error))completionHandler;

这里我们和UIWebview中执行通信代码的方法比较一下：

- (nullable NSString *)stringByEvaluatingJavaScriptFromString:(NSString *)script;

可以看到，WKWebview这边的通信方法相对而言比较的人性化，因为iOS传递给js代码之后，得到的结果不一定是NSString类型，在很多情况下我们会需要得到一个对象、数组等等数据。
接下来，顺便提一下一个iOS和H5之间通信的架包：JavaScriptCore.framework。这个架包是苹果自带支持的架包，主要目的就是让开发人员更加简便的去操作iOS和H5之间的通信代码。导入方式是直接从build phases中导入。如下图：

image.png
接下来，我们正式进入，对WKWebViewJavascriptBridge这个第三方包的使用和源码的分析。首先，笔者这边给出了一个简单的使用WKWebViewJavascriptBridge的demo，代码地址：https://github.com/IBIgLiang/WKWebView-WebViewJavascriptBridge
。而WKWebViewJavascriptBridge这个第三方包的GitHub地址如下：https://github.com/marcuswestin/WebViewJavascriptBridge。里面已经很明确的指出的使用流程和注意事项。
这里笔者用一张图来总结一下这个过程，当然这些代码在demo中都有，大家可以照着图看下：
image.png
接下来，我们重点来看看这个第三方的源代码，我们这里通过流程图，大致看下整个过程。先说明，笔者这里暂时不考虑UIWebview的操作，因为笔者已经说了它将退出。作为iOS开发，我们就从iOS这边开始整个流程，先从ViewController开始：
image.png
从上图中可以看出，一般来说，VC中所作的基本上都是准备工作，无论是注册通信还是响应通信，除了当响应通信时，没有需要传递的参数，因为WebViewJavascriptBridge本身所有的保存的参数的消息队列是统一处理的。
接下来我们来看看，上面说过的一个重要的代理：

- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler;

这个代理主要是做请求拦截操作，WebViewJavascriptBridge作者在拦截的过程中，加载WebViewJavascriptBridge_JS文件，然后是处理消息队列中的数据，具体我们还是一起看流程图：

image.png

这张图的发起点是在H5的JS端：

function setupWebViewJavascriptBridge(callback) {
            if (window.WebViewJavascriptBridge) { return callback(WebViewJavascriptBridge); }
            if (window.WVJBCallbacks) { return window.WVJBCallbacks.push(callback); }
            window.WVJBCallbacks = [callback];
            // 创建一个看不见的iframe,发起一个请求,这个请求用来加载WebViewJavascriptBridge_JS.m中的js代码
            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)
        }

调用setupWebViewJavascriptBridge这个方法之后，通过iFrame发送https://bridge_loaded请求，进入decidePolicyForNavigationAction代理中，然后走上面流程图中的流程。当地址是https://bridge_loaded时，此时直接进入[_base injectJavascriptFile];代码段。具体内容如下：

//TODO:WebViewJavascriptBridge桥接js文件的导入,并且发送iOS端业务数据给js
- (void)injectJavascriptFile {
    NSString *js = WebViewJavascriptBridge_js();
    [self _evaluateJavascript:js];
    //导入桥接文件之后,将iOS端需要发送的数据发送给js端
    //self.startupMessageQueue中放置了iOS发起给js的数据
    if (self.startupMessageQueue) {
        NSArray* queue = self.startupMessageQueue;
        self.startupMessageQueue = nil;
        for (id queuedMessage in queue) {
            // 发送iOS端数据到JS端
            [self _dispatchMessage:queuedMessage];
        }
    }
}

主要做的就是导入js桥接问题，然后就是发送iOS端的业务参数，这个参数的来源已经在上面ViewController准备工作的流程图中写明。
除了JS端的iFrame发送https://bridge_loaded请求之外，还有WebViewJavascriptBridge_js中的https://wvjb_queue_message，这个请求发起的主要作用就是处理消息队列中的信息。也就是[self WKFlushMessageQueue];这个步骤。这个消息队列的处理包含了JS端发送的数据。代码如下：

//TODO:处理消息队列中的数据
- (void)WKFlushMessageQueue {
    
    // 读取js发送的数据
    [_webView evaluateJavaScript:[_base webViewJavascriptFetchQueyCommand] completionHandler:^(NSString* result, NSError* error) {
        if (error != nil) {
            NSLog(@"WebViewJavascriptBridge: WARNING: Error when trying to fetch data from WKWebView: %@", error);
        }
        // 处理消息队列中的数据
        [_base flushMessageQueue:result];
    }];
}

[_base flushMessageQueue:result];这个方法中包含了JS端发送的数据和iOS处理完数据之后回调给JS端的数据的处理，包括两个部分：一个是iOS响应JS端通信后JS端回调给iOS端的消息内容，key值包含callbackId；另一个是JS响应iOS端的通信的消息内容，key值包含responseId。主要代码段：

NSString* responseId = message[@"responseId"];
        if (responseId) {
            // 如果是js注册函数中回调回来的数据,就直接回到iOS的callHandler的block中
            // js注册registerHandler -> iOS发送相应业务数据callHandler -> js中注册函数的block回调到iOS中
            WVJBResponseCallback responseCallback = _responseCallbacks[responseId];
            responseCallback(message[@"responseData"]);
            [self.responseCallbacks removeObjectForKey:responseId];
        } else {
            // iOS注册函数, js相应数据后,回到iOS注册函数registerHandler中的block,然后回调给js
            //iOS注册registerHandler -> js发送相应业务数据callHandler -> 进入iOS的registerHandler的block中 -> responseCallback回调给js
            WVJBResponseCallback responseCallback = NULL;
            NSString* callbackId = message[@"callbackId"];
            if (callbackId) {
                responseCallback = ^(id responseData) {
                    if (responseData == nil) {
                        responseData = [NSNull null];
                    }
                    
                    WVJBMessage* msg = @{ @"responseId":callbackId, @"responseData":responseData };
                    // 将js发送给iOS之后,iOS处理完业务,重新将业务数据发送给js端
                    [self _queueMessage:msg];
                };
            } 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);

到此，除了桥接js文件没有涉及讲解之外，其余重要步骤都已讲解完毕。

============================================================

接下来就是最后的WebViewJavascriptBridge_JS文件。这个js文件的内容其实很好理解，就是为iOS和JS两端的通信创建一个通用的WebViewJavascriptBridge对象：

// 定义一个webview和js之间的桥
    window.WebViewJavascriptBridge = {
        // 用于JS端注册通信
        registerHandler: registerHandler,
        // 用于存储JS端相应iOS端的通信的参数,放入_fetchQueue中
        callHandler: callHandler,
        // 请求超时字段
        disableJavscriptAlertBoxSafetyTimeout: disableJavscriptAlertBoxSafetyTimeout,
        // 消息队列,用于放置JS端发送给iOS端的数据
        _fetchQueue: _fetchQueue,
        // 处理iOS端发送给JS端的数据
        _handleMessageFromObjC: _handleMessageFromObjC
    };

这个文件里面的方法中，需要重点说明一下的就是_dispatchMessageFromObjC这个方法中的这个代码段：

if (message.responseId) {
    responseCallback = responseCallbacks[message.responseId];
    if (!responseCallback) {
        return;
    }
    responseCallback(message.responseData);
    delete responseCallbacks[message.responseId];
} else {
    if (message.callbackId) {
        var callbackResponseId = message.callbackId;
        responseCallback = function(responseData) {
            _doSend({ handlerName:message.handlerName, responseId:callbackResponseId, responseData:responseData });
        };
    }
    
    var handler = messageHandlers[message.handlerName];
    if (!handler) {
        console.log("WebViewJavascriptBridge: WARNING: no handler for message from ObjC:", message);
    } else {
        handler(message.data, responseCallback);
    }
}

其实大家可以发现，这个代码段和笔者上面贴出来flushMessageQueue部分的那个代码段是相对应的，它就是JS端处理iOS发送过来的数据的过程。这里笔者就不具体展开了。
由于篇幅长度原因，关于iOS中的WKWebView和H5之间通信及WKWebViewJavascriptBridge的源码分析就到此为止了。
笔者将在下一篇文章WKURLSchemeHandler在WKWebView的拦截请求中的使用中指出NSURLProtocol拦截这WKWebView无效的问题以及原因（scheme底层注册有关），并且使用WKURLSchemeHandler拦截请求，当前有个前提是这个请求的scheme是自定义的，有兴趣的同学可以瞄一眼！