前言

本文介紹quick hybrid框架的核心JSBridge的實現(xiàn)

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

交互原理

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

交互原理圖如下：

預計的最終效果

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

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

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

架構

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

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

功能分析與確認

根據(jù)核心架構，規(guī)劃需要實現(xiàn)的功能：

• H5橋接對象的設計（JSBridge）

  • 短期回調池，需自動回收

  • 長期回調池，可多次使用

  • 調用Native方法的通道，橋接對象上原生注冊的接收方法

  • 接收Native調用的通道，橋接對象上H5注冊的接收方法

  • H5可以注冊主動給原生調用的方法

• 原生橋接對象的設計

  • 長期方法池，每一個長期調用都會存儲在回調池中，可以多次使用

  • 短期立即執(zhí)行，每一個短期調用都是立即執(zhí)行

  • 調用H5方法的通道，橋接對象上H5注冊的接收方法

  • 接收H5調用的通道，橋接對象上原生注冊的接收方法，底層自動解析，然后執(zhí)行對應API

  • 回調對象，底層基于調用H5的通道，每次執(zhí)行完畢后都通過回調對象回調給H5

  • 主動調用H5，不同于回調對象只能被動響應，這個可以主動調用H5中注冊的方法

• API的設計

  • H5中的API，供前端調用，底層通過調用Native方法的通道，然后將預處理后的參數(shù)發(fā)送給原生

  • Native中的API，真正的功能實現(xiàn)

接下來就是JSBridge的實現(xiàn)

全局通信對象的確認

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

• JSBridge，H5端的橋接對象，對象中綁定了接收原生調用的方法_handleMessageFromNative，以及內部有對回調函數(shù)等進行管理

• 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對象的實現(xiàn)

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

JSBridge = {// 本地注冊的方法集合,原生只能主動調用本地注冊的方法messageHandlers: {},// 短期回調函數(shù)集合，在原生調用完對應的方法后會自動刪除回收responseCallbacks: {},// 長期存在的回調集合，可以多次調用responseCallbacksLongTerm: {},_handleMessageFromNative: function(messageJSON) {// 內部的處理：／**如果是回調函數(shù)：如果是短期回調responseCallbacks中查詢回調id，并執(zhí)行，執(zhí)行后自動銷毀如果是短期回調responseCallbacksLongTerm中查詢回調id，并執(zhí)行*／／**如果是Native的主動調用：去本地注冊的方法池messageHandlers中搜索，并執(zhí)行*／},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中橋接對象的實現(xiàn)

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

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

callback類偽代碼如下：

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

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

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

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

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

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

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

iOS中橋接對象的實現(xiàn)

這里仍然是OC實現(xiàn)的，主要參考的marcuswestin/WebViewJavascriptBridge實現(xiàn)

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

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

然后看看它基類WebViewJavascriptBridgeBase的實現(xiàn)

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

接下來是API的定義

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

@implementation RegisterBaseClass #pragma mark - 注冊api的統(tǒng)一方法 - (void)registerHandlers {// 子類重寫改方法實現(xiàn)自定義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) {// 同樣，在接收到數(shù)據(jù)，并處理后，通過responseCallback通知H5...responseCallback(...);} }

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

然后在webview創(chuàng)建時，會進行監(jiān)聽，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，多數(shù)情況下我們認為它就是方法名。 [self.wv.configuration.userContentController addScriptMessageHandler: self.bridge name: @"WKWebViewJavascriptBridge"];

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

API的設計

按照上述的實現(xiàn)，可以構建出一個完整的JSBridge交互流程，H5和Native的交互已經(jīng)通了

接下來就是設計API真正給外界調用

準確的來說，API的設計已經(jīng)脫離了JSBridge交互內容，屬于混合框架框架應用層次，因此后續(xù)會有單獨的章節(jié)介紹quick hybrid中的API

API如何實現(xiàn)？可以參考上文中Android的繼承IBridgeImpl法以及iOS的繼承RegisterBaseClass然后重寫registerHandlers

至于該規(guī)劃些什么API，這與實際的需求有關，不過一般情況下，像ui.alert等等一般都是必須的

更多詳情請待后續(xù)章節(jié)

結束語

最后再來一張圖鞏固下把

至此，整個JSBridge交互就已經(jīng)完成了

其實在總結文章時，考慮過很多種形式，發(fā)現(xiàn)，
如果是全文字描述，十分枯燥，很難堅持讀下來，
如果是各種原理都用繪圖+描述，發(fā)現(xiàn)會化簡為繁，硬生生把難度提高了幾個level，
所以最終采用的是偽代碼（半偽半真）展示形式（剔除一些無效信息，提取關鍵，而且還不和最終的代碼沖突）

雖然說，這整套流程都沒有特別難的地方，涉及的知識點都不是特別深。但是卻包含了前端，Android，iOS三個領域。
因此如果要將整套工作做的比較好的化最好還是有分工的好，比較一個人的精力有限，真正專精多個領域的人還是比較少的，
而且后續(xù)各個優(yōu)化的內容也不少（API，優(yōu)化，等等...）

返回根目錄

• 【quickhybrid】如何實現(xiàn)一個Hybrid框架

源碼

github上這個框架的實現(xiàn)

quickhybrid/quickhybrid

附錄

參考資料

• marcuswestin/WebViewJavascriptBridge

轉載于:https://www.cnblogs.com/dailc/p/8098597.html

總結

以上是生活随笔為你收集整理的【quickhybrid】JSBridge的实现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。