一、用法簡析
這個庫的還是比較精簡單的，當前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? 參數(shù) : 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");
}];
簡潔的代碼就已經(jīng)完成js與app的橋接，那么我們來看看他整個流程是怎么執(zhí)行，
首先js 調用的代碼出現(xiàn)一個了創(chuàng)建了一個iframe 并且設置src = 'https://bridge_loaded'
我們很清楚的知道如果WKWebView 可以捕獲到url 的變化的 也就是說設置src后WKWebView 是有回調的，那么我把斷點斷到WKWebView的代理看看這里發(fā)生了什么(PS:為什么這里iframe 要appendChild到document, 然后又快速的remove 呢 ，我想到一個解釋 ，是因為iframe 設置src 就無用了，iframe 只能通過 removeChild 才能移除掉，然后要想remove 就必須得先append )
原理簡釋：
當js 第一次app 橋接 我們在代理截獲到 這段
我們截獲到 這段url https://bridge_loaded
這里有個loaded 我可以猜測類似ViewDidLoad 頁面加載完成，那么我們進代理看看做了什么
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] 這個方法去區(qū)分是否是從這個庫的iframe 設置的src的url 他們是根據(jù)
#define kOldProtocolScheme @"wvjbscheme"
#define kNewProtocolScheme @"https"
#define kQueueHasMessage? @"__wvjb_queue_message__"
#define kBridgeLoaded? ? ? @"__bridge_loaded__"
判斷url 是否包含以上字符串，那么接著看看當url 是https://bridge_loaded 這個的時候做了什么，也就是執(zhí)行了這個 [_base injectJavascriptFile] 注入一段js，自然這段js 必然起到重要的作用，我們先簡單看一下這段js，也就是這個兩個文件
這段js簡單來看是插入一個(function(){xxx})()的匿名函數(shù)
創(chuàng)建了一個WebViewJavascriptBridge 全局變量
window.WebViewJavascriptBridge = {
registerHandler: registerHandler,
callHandler: callHandler,
disableJavscriptAlertBoxSafetyTimeout: disableJavscriptAlertBoxSafetyTimeout,
_fetchQueue: _fetchQueue,
_handleMessageFromObjC: _handleMessageFromObjC
};
簡單過完這段js 然后我繼續(xù)調試，發(fā)現(xiàn)出現(xiàn)了一個url 為https://wvjb_queue_message/ 的變化
那可以猜想是不是告訴app端 js 正在調用你的方法呢，但是很奇怪的是，斷點在app方法回調的部分卻沒有執(zhí)行，這是為啥，那我們在看看 那段注入的js 做了什么
[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 這個數(shù)組,可以猜測他估計這一次只是為了重新初始化sendMessageQueue 這個數(shù)組，那么這么說下一次就應該是響應js 調用 app的方法了，那么耐著性子繼續(xù)來下一步，果然WKFlushMessageQueue 注入js 的回調了handelName 和參數(shù)
接著在[_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];
}
說到這里大概知道他是根據(jù)代理判斷url 變化來截獲到js 調用app 這個事件，那到這里還有一個很大疑問就是他的url https://wvjb_queue_message/ 他是怎么把參數(shù)傳過來的了，貌似我們一直在看注入的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數(shù)組里面，并且設置src 為https://wvjb_queue_message/ 通知app 端將發(fā)送消息，當代理攔截到這段url 便調用WKFlushMessageQueue 方法調用WebViewJavascriptBridge._fetchQueue() 這個方法去sendMessageQueue這個數(shù)組獲取消息內(nèi)容字典，大致流程已經(jīng)解析完，最后在來看看流程圖，梳理下流程吧
最后總結下原來這個庫原來很簡單只是通過iframe 設置src變化去觸發(fā)app 的webView 的代理回調,但是使用這個庫卻察覺不到這個痕跡，使用十分簡單，代碼邏輯也十分整潔，還是十分推薦的。
