一谐区、用法簡析
這個(gè)庫的還是比較精簡單的，當(dāng)前webView 是用UIWebView 那么我只需要引入WebViewJavascriptBridge ,相應(yīng)的WKWebView則需要用到WKWebViewJavascriptBridge
這個(gè)橋接主要是介于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.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? 回調(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的橋接，那么我們來看看他整個(gè)流程是怎么執(zhí)行，
首先js 調(diào)用的代碼出現(xiàn)一個(gè)了創(chuàng)建了一個(gè)iframe 并且設(shè)置src = 'https://bridge_loaded'
我們很清楚的知道如果WKWebView 可以捕獲到url 的變化的 也就是說設(shè)置src后WKWebView 是有回調(diào)的拯辙，那么我把斷點(diǎn)斷到WKWebView的代理看看這里發(fā)生了什么(PS:為什么這里iframe 要appendChild到document, 然后又快速的remove 呢 ，我想到一個(gè)解釋 颜价，是因?yàn)閕frame 設(shè)置src 就無用了涯保，iframe 只能通過 removeChild 才能移除掉，然后要想remove 就必須得先append )
原理簡釋：
當(dāng)js 第一次app 橋接 我們在代理截獲到 這段
我們截獲到 這段url https://bridge_loaded
這里有個(gè)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;
}
直接點(diǎn)進(jìn)去我們看到[_base isWebViewJavascriptBridgeURL:url] 這個(gè)方法去區(qū)分是否是從這個(gè)庫的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 這個(gè)的時(shí)候做了什么，也就是執(zhí)行了這個(gè) [_base injectJavascriptFile] 注入一段js专挪，自然這段js 必然起到重要的作用及志，我們先簡單看一下這段js，也就是這個(gè)兩個(gè)文件
這段js簡單來看是插入一個(gè)(function(){xxx})()的匿名函數(shù)
創(chuàng)建了一個(gè)WebViewJavascriptBridge 全局變量
window.WebViewJavascriptBridge = {
registerHandler: registerHandler,
callHandler: callHandler,
disableJavscriptAlertBoxSafetyTimeout: disableJavscriptAlertBoxSafetyTimeout,
_fetchQueue: _fetchQueue,
_handleMessageFromObjC: _handleMessageFromObjC
};
簡單過完這段js 然后我繼續(xù)調(diào)試寨腔，發(fā)現(xiàn)出現(xiàn)了一個(gè)url 為https://wvjb_queue_message/ 的變化
那可以猜想是不是告訴app端 js 正在調(diào)用你的方法呢速侈，但是很奇怪的是，斷點(diǎn)在app方法回調(diào)的部分卻沒有執(zhí)行迫卢，這是為啥倚搬，那我們在看看 那段注入的js 做了什么
[self.bridge registerHandler:@"xxx" handler:^(id data, WVJBResponseCallback responseCallback) {
responseCallback(@"xxx");
}];
我們看到注入的js里面有一個(gè)iframe 同樣也設(shè)置了src 代碼如下
messagingIframe = document.createElement('iframe');
messagingIframe.style.display = 'none';
messagingIframe.src = CUSTOM_PROTOCOL_SCHEME + '://' + QUEUE_HAS_MESSAGE;
document.documentElement.appendChild(messagingIframe);
那為什么他設(shè)置src,這樣調(diào)試有啥用，是不是為了初始化什么呢,那接著調(diào)試看看乾蛤，他調(diào)用了WKFlushMessageQueue這個(gè)方法每界，調(diào)用js WebViewJavascriptBridge._fetchQueue()的方法,那我們在來看看注入js 有沒有_fetchQueue這個(gè)方法，
function _fetchQueue() {
var messageQueueString = JSON.stringify(sendMessageQueue);
sendMessageQueue = [];
return messageQueueString;
}
他是返回了messageQueueString 幻捏，并且清空sendMessageQueue 這個(gè)數(shù)組,可以猜測他估計(jì)這一次只是為了重新初始化sendMessageQueue 這個(gè)數(shù)組盆犁，那么這么說下一次就應(yīng)該是響應(yīng)js 調(diào)用 app的方法了，那么耐著性子繼續(xù)來下一步篡九，果然WKFlushMessageQueue 注入js 的回調(diào)了handelName 和參數(shù)
接著在[_base flushMessageQueue:result]谐岁； 這個(gè)方法將result字符串轉(zhuǎn)換成字典 并且在messageHandlers這個(gè)全局變量獲取到對應(yīng)handlerName 的 hanlder 回調(diào)給app 注冊的回調(diào)中
ps: app 端注冊hanler 就會把這個(gè)hanler 添加messageHandlers這個(gè)可變字典中
- (void)registerHandler:(NSString *)handlerName handler:(WVJBHandler)handler {
_base.messageHandlers[handlerName] = [handler copy];
}
說到這里大概知道他是根據(jù)代理判斷url 變化來截獲到j(luò)s 調(diào)用app 這個(gè)事件，那到這里還有一個(gè)很大疑問就是他的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 方法了要繞回去沛善，下面我會畫一個(gè)流程圖梳理一下整個(gè)流程航揉，那我們來看看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;
}
原來在這個(gè)時(shí)候callHandler 方法message 這個(gè)字典塞入sendMessageQueue數(shù)組里面金刁，并且設(shè)置src 為https://wvjb_queue_message/ 通知app 端將發(fā)送消息帅涂，當(dāng)代理攔截到這段url 便調(diào)用WKFlushMessageQueue 方法調(diào)用WebViewJavascriptBridge._fetchQueue() 這個(gè)方法去sendMessageQueue這個(gè)數(shù)組獲取消息內(nèi)容字典议薪，大致流程已經(jīng)解析完，最后在來看看流程圖媳友，梳理下流程吧
最后總結(jié)下原來這個(gè)庫原來很簡單只是通過iframe 設(shè)置src變化去觸發(fā)app 的webView 的代理回調(diào),但是使用這個(gè)庫卻察覺不到這個(gè)痕跡斯议，使用十分簡單，代碼邏輯也十分整潔醇锚，還是十分推薦的哼御。
