【quickhybrid】JSBridge的實現

前言

本文介紹quick hybrid框架的核心JSBridge的實現

由于在最新版本中，已經沒有考慮iOS7等低版本，因此在選用方案時沒有采用url scheme方式，而是直接基于WKWebView實現

交互原理

具體H5和Native的交互原理可以參考前文的H5和Native交互原理

交互原理圖如下：

預計的最終效果

如果一步一步來分析，最后再看效果，可能會很枯燥，甚至還有點化簡為繁的樣子。（感覺直接看代碼應該是最簡單的，奈何每次寫成文章時都得加一大堆的描述）

因此，先來看看最終完成后應該是什么樣的。

// 調用ui中alert的示例
callHandler({// 模塊名，本文中的API劃分了模塊module: 'ui',// 方法名name: 'alert',// 需要傳遞給native的請求參數data: {message: 'hello',},callback: function(res) {/*** 調用后的回調，接收原生傳遞的回調數據* alert如果成功，可以點擊后再回調{// 1成功/0失敗code: 1,message: '描述',// 數據data: {},}*/}
});

架構

從頭開始實現一個JSBridge，很容易兩眼一抹黑，無從下手。

因此我們需要先從大方向上把功能交互確定好，然后再開始構建細節，編碼實現

功能分析與確認

根據核心架構，規劃需要實現的功能：

H5橋接對象的設計（JSBridge）
- 短期回調池，需自動回收
- 長期回調池，可多次使用
- 調用Native方法的通道，橋接對象上原生注冊的接收方法
- 接收Native調用的通道，橋接對象上H5注冊的接收方法
- H5可以注冊主動給原生調用的方法
原生橋接對象的設計
- 長期方法池，每一個長期調用都會存儲在回調池中，可以多次使用
- 短期立即執行，每一個短期調用都是立即執行
- 調用H5方法的通道，橋接對象上H5注冊的接收方法
- 接收H5調用的通道，橋接對象上原生注冊的接收方法，底層自動解析，然后執行對應API
- 回調對象，底層基于調用H5的通道，每次執行完畢后都通過回調對象回調給H5
- 主動調用H5，不同于回調對象只能被動響應，這個可以主動調用H5中注冊的方法
API的設計
- H5中的API，供前端調用，底層通過調用Native方法的通道，然后將預處理后的參數發送給原生
- Native中的API，真正的功能實現

接下來就是JSBridge的實現

全局通信對象的確認

最重要的，是先把H5和Native通信時的幾個全局橋接對象確定：

JSBridge，H5端的橋接對象，對象中綁定了接收原生調用的方法_handleMessageFromNative，以及內部有對回調函數等進行管理
webkit.messageHandlers.WKWebViewJavascriptBridge.postMessage，iOS端的橋接對象，這個方法接收H5的調用
prompt，Android端的橋接對象，為了方便，直接重寫了WebChromeClient中的onJsPrompt

// H5端的內部邏輯處理
window.JSBridge = {...}// 接收原生的調用，有回調以及主動調用兩種
JSBridge._handleMessageFromNative = function() {...}

// H5主動調用原生
if (os.ios) {// ios采用window.webkit.messageHandlers.WKWebViewJavascriptBridge.postMessage(...);
} else {window.top.prompt(...);
}

JSBridge對象的實現

H5就依靠這個對象與Native通信，這里僅介紹核心的邏輯

JSBridge = {// 本地注冊的方法集合,原生只能主動調用本地注冊的方法messageHandlers: {},// 短期回調函數集合，在原生調用完對應的方法后會自動刪除回收responseCallbacks: {},// 長期存在的回調集合，可以多次調用responseCallbacksLongTerm: {},_handleMessageFromNative: function(messageJSON) {// 內部的處理：／**如果是回調函數：如果是短期回調responseCallbacks中查詢回調id，并執行，執行后自動銷毀如果是短期回調responseCallbacksLongTerm中查詢回調id，并執行*／／**如果是Native的主動調用：去本地注冊的方法池messageHandlers中搜索，并執行*／},callHandler: function(...) {// 底層分別調用Android或iOS的原生接收方法// 如果是短期回調，會將回調添加到responseCallbacks中// 如果是長期回調，會將回調添加到responseCallbacksLongTerm中// 省略若干邏輯...if (os.ios) {// ios采用window.webkit.messageHandlers.WKWebViewJavascriptBridge.postMessage(...);} else {window.top.prompt(...);}},registerHandler: function(handlerName, handler) {// H5在本地注冊可供原生調用的方法},...
};

Android中橋接對象的實現

Android中的核心就是JSBridge，其余都是圍繞這個來的，以下是偽代碼，列舉主要的邏輯

public class JSBridge {// 緩存所有的API模塊（注冊時添加進去）static exposedAPIModlues =  new HashMap<>();static register(String apiModelName, Class<? extends IBridgeImpl> clazz) {// 注冊時會自動尋找所有的框架API模塊，然后添加到緩存exposedAPIModlues，每一個模塊中可以有若干API// 每一個模塊都需要實現IBridgeImpl接口...}static callAPI(...) {// 首先會解析參數（H5中傳遞的），解析出調用了哪一個API，傳遞了些什么，解析結果包括如下// port:H5傳遞的回調id，是responseCallbacks或responseCallbacksLongTerm中的key// moduleName:調用的API的模塊名，用來檢索exposedAPIModlues中注冊的模塊// name:調用的API的方法名，在對于找到的模塊中去查找API// 其他:包括傳遞的參數等等// 然后會根據H5的回調端口號，生成一個回調對象（用來回調通知H5）Callback callback = new Callback(port);// 之后，根據解析的參數尋找API方法// java.lang.reflect.Method;Method method = searchMethodBy(moduleName, name);// 沒有找到方法會回調對于錯誤信息// 否則執行對于的method，傳遞解析出的參數// 并且在method內部執行完畢后主動回調給H5對于信息method.invoke(..., callback);}
}

callback類偽代碼如下：

public class Callback {apply(...) {// 先解析拼裝參數，然后將參數組裝成javascript代碼，參數中包含Callback對于的port值（回調id）...String js = javascript:JSBridge._handleMessageFromNative(對于的json參數);callJS(js);}callHandler(...) {// 主動調用H5，封裝的參數中不再是回調id，而是handleName...callJS(js);}callJS(js) {// 底層通過loadUrl執行...webviewContext.loadUrl(js);}
}

IBridgeImpl接口是空的，只是一個抽象定義，以下以某個實現這個接口的API為例

// 為了清晰，以ui.alert為例
public class xxxApi implements IBridgeImpl {// 定義一個注冊的模塊別名，方便查找，譬如uistatic RegisterName = "ui";// 模塊中的某個API，譬如alertpublic static void alert(..., Callback callback) {// 接下來就是在這個API中實現對于的邏輯...// 最后，通過觸發callback通知H5即可callback.apply(...);}
}

最后可以看到，在webview中，重新了WebChromeClient的onJsPrompt來接收H5的調用

并且在webview加載時就會調用JSBridge的register

public class XXXWebChromeClient extends WebChromeClient {@Overridepublic boolean onJsPrompt(..., JsPromptResult result) {// 內部觸發JSBridge.callJavaresult.confirm(JSBridge.callJava(...));return true;}
}

以上幾個就是Andorid中JSBridge核心實現，其他的如長期回調，短期回調，細節實現等優化不是核心邏輯，就列舉，詳情可以參考最后的源碼

iOS中橋接對象的實現

這里仍然是OC實現的，主要參考的marcuswestin/WebViewJavascriptBridge實現

核心仍然是WKWebViewJavascriptBridge，其余一切都是通過它來分發代理

@implementation WKWebViewJavascriptBridge {// 內部基于一個WebViewJavascriptBridgeBase基類（基類中定義交互方法）WebViewJavascriptBridgeBase *_base;    
}
/*** API*/
- (void)callHandler:(NSString *)handlerName data:(id)data {// 主動調用H5的方法// 底層調用_base的sendData，發送數據給H5
}- (void)registerModuleFrameAPI {// 注冊模塊API，模塊用到了別名代理[self registerHandlersWithClassName:@"UIApi" moduleName:@"ui"];// 其中registerHandlersWithClassName就是將模塊示例化注冊到全局中的作用，不贅述
}- (void)excuteMessage:(NSString *)message {// 內部執行API的實現，這里會解析API解析出來的數據，如// module.name,port(callbackid)等...// 然后底層調用_base的excuteMsg（它內部會根據注冊的API，找到相對應的，然后執行原生功能，最后通過回調通知H5）
}#pragma mark - WKScriptMessageHandler其實就是一個遵循的協議，它能讓網頁通過JS把消息發送給OC
- (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message {// 監聽到對于API調用時，底層會調用excuteMessageif ([message.name isEqualToString:@"WKWebViewJavascriptBridge"]) {[self excuteMessage:message.body];}
}

然后看看它基類WebViewJavascriptBridgeBase的實現

@implementation WebViewJavascriptBridgeBase- (void)sendData:(id)data responseCallback:(WVJBResponseCallback)responseCallback handlerName:(NSString*)handlerName {// 底層將接收到的數據組裝成js代碼執行...NSString* javascriptCommand = [NSString stringWithFormat:@"JSBridge._handleMessageFromNative('%@');", messageJSON];[_webView evaluateJavaScript:javascriptCommand completionHandler:nil];
}- (void)excuteMsg:(NSString *)messageQueueString moduleName:(NSString *)moduleName {// 底層根據對于的模塊，API名，找到注冊的handler...// 然后創建一個回調對象WVJBResponseCallback responseCallback = (通過sendData通知H5回調數據);// 然后執行這個handlerhandler(message[@"data"], responseCallback);
}

接下來是API的定義

定義API模塊之前，需要先了解RegisterBaseClass，所有模塊必須實現的基類，定義了如何注冊

@implementation RegisterBaseClass
#pragma mark - 注冊api的統一方法
- (void)registerHandlers {// 子類重寫改方法實現自定義API注冊
}#pragma mark - handler存取
- (void)registerHandlerName:(NSString *)handleNamehandler:(WVJBHandler)handler {// 注冊某個模塊下的某個API
}- (WVJBHandler)handler:(NSString *)handlerName {// 通過名稱獲取對應的API
}

要定義一個API模塊，則需繼承RegisterBaseClass然后重寫registerHandlers（為了清晰，以ui.alert為例）

@implementation UIApi
- (void)registerHandlers {[self registerHandlerName:@"alert" handler:^(id data, WVJBResponseCallback responseCallback) {// 同樣，在接收到數據，并處理后，通過responseCallback通知H5...responseCallback(...);}
}

在webview加載時就會調用WKWebViewJavascriptBridge的registerModuleFrameAPI，對于模塊名ui與別名UIApi，可以在注冊時看到，它們之間是有一一對應關系的

然后在webview創建時，會進行監聽，userContentController

WKWebViewConfiguration * webConfig = [[WKWebViewConfiguration alloc] init];
WKUserContentController * userContentVC = [[WKUserContentController alloc] init];
webConfig.userContentController = userContentVC;
WKWebView * wk = [[WKWebView alloc] initWithFrame: CGRectZero configuration: webConfig];self.wv = wk;
...// 代理
self.bridge = [WKWebViewJavascriptBridge bridgeForWebView: self.wv];
[self.bridge setWebViewDelegate: self];// 添加供js調用oc的橋梁。這里的name對應WKScriptMessage中的name，多數情況下我們認為它就是方法名。
[self.wv.configuration.userContentController addScriptMessageHandler: self.bridge name: @"WKWebViewJavascriptBridge"];

同樣，iOS中的長期回調等其它一些非核心內容也暫時隱藏了