githup地址：https://github.com/marcuswestin/WebViewJavascriptBridge
一 用法簡析

image.png

這個庫的還是比較精簡單的，當前webView 是用UIWebView 那么我只需要引入WebViewJavascriptBridge ,相應的WKWebView則需要用到WKWebViewJavascriptBridge
這個橋接主要是介于js 和 app 間我們先來看js 要怎么做
我們需要copy 這段代碼到js里至于為什么要這么做，后文會提到

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)
}
export default class IOSBridge {
// key : xxx  參數 : json   回調: responseCallback
      changeState (json) {
          setupWebViewJavascriptBridge(function (bridge) {
                 bridge.callHandler('xxx', json, function                responseCallback (responseData) {
      })
    })
  }
}

app 端只需要

_bridge = [WebViewJavascriptBridge bridgeForWebView:webView];
[_bridge setWebViewDelegate:self];
[self.bridge registerHandler:@"xxx" handler:^(id data, WVJBResponseCallback responseCallback) {
    responseCallback(@"xxx");
}];

簡潔的代碼就已經完成js與app的橋接，那么我們來看看他整個流程是怎么執行，
首先js 調用的代碼出現一個了創建了一個iframe 并且設置src = 'https://bridge_loaded'
我們很清楚的知道如果WKWebView 可以捕獲到url 的變化的 也就是說設置src后WKWebView 是有回調的，那么我把斷點斷到WKWebView的代理看看這里發生了什么(PS:為什么這里iframe 要appendChild到document, 然后又快速的remove 呢 ，我想到一個解釋 ，是因為iframe 設置src 就無用了，iframe 只能通過 removeChild 才能移除掉，然后要想remove 就必須得先append )

原理簡釋：
當js 第一次app 橋接 我們在代理截獲到 這段

image.png

if ([_base isWebViewJavascriptBridgeURL:url]) {
        if ([_base isBridgeLoadedURL:url]) {
            [_base injectJavascriptFile];
        } else if ([_base isQueueMessageURL:url]) {
            [self WKFlushMessageQueue];
        } else {
            [_base logUnkownMessage:url];
        }
        decisionHandler(WKNavigationActionPolicyCancel);
        return;
    }

直接點進去我們看到[_base isWebViewJavascriptBridgeURL:url] 這個方法去區分是否是從這個庫的iframe 設置的src的url 他們是根據

#define kOldProtocolScheme @"wvjbscheme"
#define kNewProtocolScheme @"https"
#define kQueueHasMessage   @"__wvjb_queue_message__"
#define kBridgeLoaded      @"__bridge_loaded__"

判斷url 是否包含以上字符串，那么接著看看當url 是https://bridge_loaded 這個的時候做了什么，也就是執行了這個 [_base injectJavascriptFile] 注入一段js，自然這段js 必然起到重要的作用，
我們先簡單看一下這段js 也就是這個兩個文件

image.png

這段js簡單來看是插入一個(function(){xxx})()的匿名函數
創建了一個WebViewJavascriptBridge 全局變量

window.WebViewJavascriptBridge = {
        registerHandler: registerHandler,
        callHandler: callHandler,
        disableJavscriptAlertBoxSafetyTimeout: disableJavscriptAlertBoxSafetyTimeout,
        _fetchQueue: _fetchQueue,
        _handleMessageFromObjC: _handleMessageFromObjC
    };

簡單過完這段js 然后我繼續調試，發現出現了一個url 為https://wvjb_queue_message/ 的變化

image.png

[self.bridge registerHandler:@"xxx" handler:^(id data, WVJBResponseCallback responseCallback) {
    responseCallback(@"xxx");
}];

我們看到注入的js里面有一個iframe 同樣也設置了src 代碼如下

messagingIframe = document.createElement('iframe');
    messagingIframe.style.display = 'none';
    messagingIframe.src = CUSTOM_PROTOCOL_SCHEME + '://' + QUEUE_HAS_MESSAGE;
    document.documentElement.appendChild(messagingIframe);

那為什么他設置src,這樣調試有啥用，是不是為了初始化什么呢,那接著調試看看，他調用了WKFlushMessageQueue這個方法，調用js WebViewJavascriptBridge._fetchQueue()的方法,那我們在來看看注入js 有沒有_fetchQueue這個方法，

    function _fetchQueue() {
        var messageQueueString = JSON.stringify(sendMessageQueue);
        sendMessageQueue = [];
        return messageQueueString;
    }

他是返回了messageQueueString ，并且清空sendMessageQueue 這個數組,可以猜測他估計這一次只是為了重新初始化sendMessageQueue 這個數組，那么這么說下一次就應該是響應js 調用 app的方法了，那么耐著性子繼續來下一步，果然WKFlushMessageQueue 注入js 的回調了handelName 和參數

image.png

接著在[_base flushMessageQueue:result]； 這個方法將result字符串轉換成字典 并且在messageHandlers這個全局變量獲取到對應handlerName 的 hanlder 回調給app 注冊的回調中
ps: app 端注冊hanler 就會把這個hanler 添加messageHandlers這個可變字典中

- (void)registerHandler:(NSString *)handlerName handler:(WVJBHandler)handler {
    _base.messageHandlers[handlerName] = [handler copy];
}

說到這里大概知道他是根據代理判斷url 變化來截獲到js 調用app 這個事件，那到這里還有一個很大疑問就是他的url https://wvjb_queue_message/ 他是怎么把參數傳過來的了，貌似我們一直在看注入的js ，忽略了剛開始復制那段js 代碼，我們在過頭來看看

      changeState (json) {
          setupWebViewJavascriptBridge(function (bridge) {
                 bridge.callHandler('xxx', json, function                     responseCallback (responseData) {
      })
    })
  }

這里調用注入的js 的callHandler 方法了要繞回去，下面我會畫一個流程圖梳理一下整個流程，那我們來看看callHandler方法又做了什么，

    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;
    }

原來在這個時候callHandler 方法message 這個字典塞入sendMessageQueue數組里面，并且設置src 為https://wvjb_queue_message/ 通知app 端將發送消息，當代理攔截到這段url 便調用WKFlushMessageQueue 方法調用WebViewJavascriptBridge._fetchQueue() 這個方法去sendMessageQueue這個數組獲取消息內容字典，大致流程已經解析完，最后在來看看流程圖，梳理下流程吧

image.png

最后總結下原來這個庫原來很簡單只是通過iframe 設置src變化去觸發app 的webView 的代理回調,但是使用這個庫卻察覺不到這個痕跡，使用十分簡單，代碼邏輯也十分整潔，還是十分推薦的。