iOS WebViewJavascriptBridge源碼解析
一 用法簡析
這個庫的還是比較精簡單的徽惋，當(dāng)前webView 是用UIWebView 那么我只需要引入WebViewJavascriptBridge ,相應(yīng)的WKWebView則需要用到WKWebViewJavascriptBridge
這個橋接主要是介于js 和 app 間我們先來看js 要怎么做
我們需要copy 這段代碼到j(luò)s里至于為什么要這么做，后文會提到
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.src = 'https://__bridge_loaded__';
document.documentElement.appendChild(WVJBIframe);
setTimeout(function() { document.documentElement.removeChild(WVJBIframe) }, 0)
}
export default class IOSBridge {
// key : xxx 參數(shù) : json 回調(diào): 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 調(diào)用的代碼出現(xiàn)一個了創(chuàng)建了一個iframe 并且設(shè)置src = 'https://bridge_loaded'
我們很清楚的知道如果WKWebView 可以捕獲到url 的變化的 也就是說設(shè)置src后WKWebView 是有回調(diào)的进宝，那么我把斷點斷到WKWebView的代理看看這里發(fā)生了什么(PS:為什么這里iframe 要appendChild到document, 然后又快速的remove 呢 鼓蜒，我想到一個解釋 ，是因為iframe 設(shè)置src 就無用了蝗羊，iframe 只能通過 removeChild 才能移除掉，然后要想remove 就必須得先append )
原理簡釋：
當(dāng)js 第一次app 橋接 我們在代理截獲到 這段
我們截獲到 這段url https://bridge_loaded
這里有個loaded 我可以猜測類似ViewDidLoad 頁面加載完成仁锯，那么我們進(jìn)代理看看做了什么
if ([_base isWebViewJavascriptBridgeURL:url]) {
if ([_base isBridgeLoadedURL:url]) {
[_base injectJavascriptFile];
} else if ([_base isQueueMessageURL:url]) {
[self WKFlushMessageQueue];
} else {
[_base logUnkownMessage:url];
}
decisionHandler(WKNavigationActionPolicyCancel);
return;
}
直接點進(jìn)去我們看到[_base isWebViewJavascriptBridgeURL:url] 這個方法去區(qū)分是否是從這個庫的iframe 設(shè)置的src的url 他們是根據(jù)
#define kOldProtocolScheme @"wvjbscheme"
#define kNewProtocolScheme @"https"
#define kQueueHasMessage @"__wvjb_queue_message__"
#define kBridgeLoaded @"__bridge_loaded__"
判斷url 是否包含以上字符串耀找，那么接著看看當(dāng)url 是https://bridge_loaded 這個的時候做了什么，也就是執(zhí)行了這個 [_base injectJavascriptFile] 注入一段js扑馁，自然這段js 必然起到重要的作用
我們先簡單看一下這段js 也就是這個兩個文件
這段js簡單來看是插入一個(function())()的匿名函數(shù)
創(chuàng)建了一個WebViewJavascriptBridge 全局變量
window.WebViewJavascriptBridge = {
registerHandler: registerHandler,
callHandler: callHandler,
disableJavscriptAlertBoxSafetyTimeout: disableJavscriptAlertBoxSafetyTimeout,
_fetchQueue: _fetchQueue,
_handleMessageFromObjC: _handleMessageFromObjC
};
簡單過完這段js 然后我繼續(xù)調(diào)試涯呻，發(fā)現(xiàn)出現(xiàn)了一個url 為"https://wvjb_queue_message/ "的變化
那可以猜想是不是告訴app端 js 正在調(diào)用你的方法呢，但是很奇怪的是腻要，斷點在app方法回調(diào)的部分卻沒有執(zhí)行复罐，這是為啥，那我們在看看 那段注入的js 做了什么
[self.bridge registerHandler:@"xxx" handler:^(id data, WVJBResponseCallback responseCallback) {
responseCallback(@"xxx");
}];
我們看到注入的js里面有一個iframe 同樣也設(shè)置了src 代碼如下
messagingIframe = document.createElement('iframe');
messagingIframe.src = CUSTOM_PROTOCOL_SCHEME + '://' + QUEUE_HAS_MESSAGE;
document.documentElement.appendChild(messagingIframe);
那為什么他設(shè)置src,這樣調(diào)試有啥用雄家，是不是為了初始化什么呢,那接著調(diào)試看看效诅，他調(diào)用了WKFlushMessageQueue這個方法，調(diào)用js WebViewJavascriptBridge._fetchQueue()的方法,那我們在來看看注入js 有沒有_fetchQueue這個方法，
function _fetchQueue() {
var messageQueueString = JSON.stringify(sendMessageQueue);
sendMessageQueue = [];
return messageQueueString;
}
他是返回了messageQueueString 乱投，并且清空sendMessageQueue 這個數(shù)組,可以猜測他估計這一次只是為了重新初始化sendMessageQueue 這個數(shù)組咽笼，那么這么說下一次就應(yīng)該是響應(yīng)js 調(diào)用 app的方法了，那么耐著性子繼續(xù)來下一步戚炫，果然WKFlushMessageQueue 注入js 的回調(diào)了handelName 和參數(shù)
接著在[_base flushMessageQueue:result]剑刑； 這個方法將result字符串轉(zhuǎn)換成字典 并且在messageHandlers這個全局變量獲取到對應(yīng)handlerName 的 hanlder 回調(diào)給app 注冊的回調(diào)中
ps: app 端注冊hanler 就會把這個hanler 添加messageHandlers這個可變字典中
- (void)registerHandler:(NSString *)handlerName handler:(WVJBHandler)handler {
_base.messageHandlers[handlerName] = [handler copy];
}
說到這里大概知道他是根據(jù)代理判斷url 變化來截獲到j(luò)s 調(diào)用app 這個事件，那到這里還有一個很大疑問就是他的url https://wvjb_queue_message/ 他是怎么把參數(shù)傳過來的了双肤，貌似我們一直在看注入的js 施掏，忽略了剛開始復(fù)制那段js 代碼，我們在過頭來看看
changeState (json) {
setupWebViewJavascriptBridge(function (bridge) {
bridge.callHandler('xxx', json, function responseCallback (responseData) {
})
})
}
這里調(diào)用注入的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ù)組里面蔑赘，并且設(shè)置src 為https://wvjb_queue_message/ 通知app 端將發(fā)送消息狸驳，當(dāng)代理攔截到這段url 便調(diào)用WKFlushMessageQueue 方法調(diào)用WebViewJavascriptBridge._fetchQueue() 這個方法去sendMessageQueue這個數(shù)組獲取消息內(nèi)容字典，大致流程已經(jīng)解析完缩赛，最后在來看看流程圖耙箍，梳理下流程吧
最后總結(jié)下原來這個庫原來很簡單只是通過iframe 設(shè)置src變化去觸發(fā)app 的webView 的代理回調(diào),但是使用這個庫卻察覺不到這個痕跡，使用十分簡單峦筒，代碼邏輯也十分整潔究西，還是十分推薦的。
