JSBridge通信原理

作者：jzcoijawlkmlzkm_307 | 来源：互联网 | 2023-07-22 17:16

前言上一篇介绍了移动端开发的相关技术，这一篇主要是从Hybrid开发的JSBridge通信讲起。顾名思义，JSBridge的意思就是桥，也

前言

上一篇介绍了移动端开发的相关技术&＃xff0c;这一篇主要是从 Hybrid 开发的 JS Bridge 通信讲起。

顾名思义&＃xff0c;JS Bridge 的意思就是桥&＃xff0c;也就是连接 JS 和 Native 的桥梁&＃xff0c;它也是 Hybrid App 里面的核心。一般分为 JS 调用 Native 和 Native 主动调用 JS 两种形式。

URL Scheme

URL Scheme 是一种特殊的 URL&＃xff0c;一般用于在 Web 端唤醒 App&＃xff0c;甚至跳转到 App 的某个页面&＃xff0c;比如在某个手机网站上付款的时候&＃xff0c;可以直接拉起支付宝支付页面。

这里有个小例子&＃xff0c;你可以在浏览器里面直接输入 weixin://&＃xff0c;系统就会提示你是否要打开微信。输入 mqq:// 就会帮你唤起手机 QQ。

这里有个常用 App URL Scheme 汇总&＃xff1a;URL Schemes 收集整理

在手机里面打开这个页面后点击这里&＃xff0c;就会提示你是否要打开微信。

我们常说的 Deeplink 一般也是基于 URL Scheme 来实现的。一个 URI 的组成结构如下&＃xff1a;

URI &＃61; scheme:[//authority]path[?query][#fragment] // scheme &＃61; http // authority &＃61; www.baidu.com // path &＃61; /link // query &＃61; url&＃61;xxxxx authority &＃61; [userinfo&＃64;]host[:port]

除了 http/https 这两个常见的协议&＃xff0c;还可以自定义协议。借用维基百科的一张图&＃xff1a;

通常情况下&＃xff0c;App 安装后会在手机系统上注册一个 Scheme&＃xff0c;比如 weixin:// 这种&＃xff0c;所以我们在手机浏览器里面访问这个 scheme 地址&＃xff0c;系统就会唤起我们的 App。

一般在 Android 里面需要到 AndroidManifest.xml 文件中去注册 Scheme&＃xff1a;

在 iOS 中需要在 Xcode 里面注册&＃xff0c;有一些已经是系统使用的不应该使用&＃xff0c;比如 Maps、YouTube、Music。

具体可以参考苹果开发者官网文档&＃xff1a;Defining a Custom URL Scheme for Your App

JS 调用 Native

在 iOS 里面又需要区分 UIWebView 和 WKWebView 两种 WebView&＃xff1a;

WKWebView 是 iOS8 之后出现的&＃xff0c;目的是取代笨重的 UIWebView&＃xff0c;它占用内存更少&＃xff0c;大概是 UIWebView 的 1/3&＃xff0c;支持更好的 HTML5 特性&＃xff0c;性能更加强大。

但也有一些缺点&＃xff0c;比如不支持缓存&＃xff0c;需要自己注入 COOKIE&＃xff0c;发送 POST 请求的时候带不了参数&＃xff0c;拦截 POST 请求的时候无法解析参数等等。

「题外话&＃xff08;小小吐槽一下&＃xff09;」

我们这边有很多场景是需要客户端和银行交互的&＃xff0c;为了从银行 H5 回调到我们的客户端&＃xff0c;常常是会让银行跳到我们的 H5 中间页&＃xff0c;客户端去拦截并解析银行带来的参数。

以前有些页面是 Python 服务端渲染做的&＃xff0c;支持 POST 请求打开页面。后来 iOS 客户端升级 WKWebView&＃xff0c;导致无法获取银行 POST 带过来的参数。

为了配合客户端发版上线&＃xff0c;曾经连夜修改了我们 App 里面所有相关的绑卡和支付 H5 页面&＃xff0c;还好没有搞出重大线上事故。

JS 调用 Native 通信大致有三种方法&＃xff1a;

拦截 Scheme
弹窗拦截
注入 JS 上下文

这三种方式总体上各有利弊&＃xff0c;下面会一一介绍。

拦截 Scheme

仔细思考一下&＃xff0c;如果是 JS 和 Java 之间传递数据&＃xff0c;我们该怎么做呢&＃xff1f;

对于前端开发来说&＃xff0c;调 Ajax 请求接口是最常见的需求了。不管对方是 Java 还是 Python&＃xff0c;我们都可以通过 http/https 接口来获取数据。实际上这个流程和 JSONP 更加类似。

已知客户端是可以拦截请求的&＃xff0c;那么可不可以在这个上面做文章呢&＃xff1f;

如果我们请求一个不存在的地址&＃xff0c;上面带了一些参数&＃xff0c;通过参数告诉客户端我们需要调用的功能呢&＃xff1f;

比如我要调用扫码功能&＃xff1a;

axios.get(&＃39;http://xxxx?func&＃61;scan&callback_id&＃61;yyyy&＃39;)

客户端可以拦截这个请求&＃xff0c;去解析参数上面的 func 来判断当前需要调起哪个功能。客户端调起扫码功能之后&＃xff0c;会获取 WebView 上面的 callbacks 对象&＃xff0c;根据 callback_id 回调它。

所以基于上面的例子&＃xff0c;我们可以把域名和路径当做通信标识&＃xff0c;参数里面的 func 当做指令&＃xff0c;callback_id 当做回调函数&＃xff0c;其他参数当做数据传递。对于不满足条件的 http 请求不应该拦截。

当然了&＃xff0c;现在主流的方式是前面我们看到的自定义 Scheme 协议&＃xff0c;以这个为通信标识&＃xff0c;域名和路径当做指令。

这种方式的好处就是 iOS6 以前只支持这种方式&＃xff0c;兼容性比较好。

JS 端

我们有很多种方法可以发起请求&＃xff0c;目前使用最广泛的是 iframe 跳转&＃xff1a;

使用 a 标签跳转

点击我打开淘宝

重定向

location.href &＃61; "taobao://"

iframe 跳转

const iframe &＃61; document.createElement("iframe"); iframe.src &＃61; "taobao://" iframe.style.display &＃61; "none" document.body.appendChild(iframe)

Android 端

在 Android 侧可以用 shouldOverrideUrlLoading 来拦截 url 请求。

&＃64;Override public boolean shouldOverrideUrlLoading(WebView view, String url) {if (url.startsWith("taobao")) {// 拿到调用路径后解析调用的指令和参数&＃xff0c;根据这些去调用 Native 方法return true;} }

iOS 端

在 iOS 侧需要区分 UIWebView 和 WKWebView 两种方式。在 UIWebView 中&＃xff1a;

- (BOOL)shouldStartLoadWithRequest:(NSURLRequest *)requestnavigationType:(BPWebViewNavigationType)navigationType {if (xxx) {// 拿到调用路径后解析调用的指令和参数&＃xff0c;根据这些去调用 Native 方法return NO;}return [super shouldStartLoadWithRequest:request navigationType:navigationType]; }

在 WKWebView 中&＃xff1a;

- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(nonnull WKNavigationAction *)navigationAction decisionHandler:(nonnull void (^)(WKNavigationActionPolicy))decisionHandler {if(xxx) {// 拿到调用路径后解析调用的指令和参数&＃xff0c;根据这些去调用 Native 方法BLOCK_EXEC(decisionHandler, WKNavigationActionPolicyCancel);} else {BLOCK_EXEC(decisionHandler, WKNavigationActionPolicyAllow);}[self.webView.URLLoader webView:webView decidedPolicy:policy forNavigationAction:navigationAction]; }

目前不建议只使用拦截 URL Scheme 解析参数的形式&＃xff0c;主要存在几个问题。

连续续调用 location.href 会出现消息丢失&＃xff0c;因为 WebView 限制了连续跳转&＃xff0c;会过滤掉后续的请求。
URL 会有长度限制&＃xff0c;一旦过长就会出现信息丢失因此&＃xff0c;类似 WebViewJavascriptBridge 这类库&＃xff0c;就结合了注入 API 的形式一起使用&＃xff0c;这也是我们这边目前使用的方式&＃xff0c;后面会介绍一下。

弹窗拦截

Android 实现

这种方式是利用弹窗会触发 WebView 相应事件来拦截的。

一般是在 setWebChromeClient 里面的 onJsAlert、onJsConfirm、onJsPrompt 方法拦截并解析他们传来的消息。

// 拦截 Prompt &＃64;Override public boolean onJsPrompt(WebView view, String url, String message, String defaultValue, JsPromptResult result) {if (xxx) {// 解析 message 的值&＃xff0c;调用对应方法}return super.onJsPrompt(view, url, message, defaultValue, result);} // 拦截 Confirm &＃64;Override public boolean onJsConfirm(WebView view, String url, String message, JsResult result) {return super.onJsConfirm(view, url, message, result);} // 拦截 Alert &＃64;Override public boolean onJsAlert(WebView view, String url, String message, JsResult result) {return super.onJsAlert(view, url, message, result);}

iOS 实现

我们以 WKWebView 为例&＃xff1a;

&＃43; (void)webViewRunJavascriptTextInputPanelWithPrompt:(NSString *)promptdefaultText:(NSString *)defaultTextcompletionHandler:(void (^)(NSString * _Nullable))completionHandler {/** Triggered by JS:var person &＃61; prompt("Please enter your name", "Harry Potter");if (person &＃61;&＃61; null || person &＃61;&＃61; "") {txt &＃61; "User cancelled the prompt.";} else {txt &＃61; "Hello " &＃43; person &＃43; "! How are you today?";}*/if (xxx) {BLOCK_EXEC(completionHandler, text);} else {BLOCK_EXEC(completionHandler, nil);}}

这种方式的缺点就是在 iOS 上面 UIWebView 不支持&＃xff0c;虽然 WKWebView 支持&＃xff0c;但它又有更好的 scriptMessageHandler&＃xff0c;比较尴尬。

注入上下文

前面我们有讲过在 iOS 中内置了 JavascriptCore 这个框架&＃xff0c;可以实现执行 JS 以及注入 Native 对象等功能。

这种方式不依赖拦截&＃xff0c;主要是通过 WebView 向 JS 的上下文注入对象和方法&＃xff0c;可以让 JS 直接调用原生。

PS&＃xff1a;iOS 中的 Block 是 OC 对于闭包的实现&＃xff0c;它本质上是个对象&＃xff0c;定义 JS 里面的函数。

iOS UIWebView

iOS 侧代码&＃xff1a;

// 获取 JS 上下文 JSContext *context &＃61; [webview valueForKeyPath:&＃64;"documentView.webView.mainFrame.JavascriptContext"]; // 注入 Block context[&＃64;"callHandler"] &＃61; ^(JSValue * data) {// 处理调用方法和参数// 调用 Native 功能// 回调 JS Callback }

JS 代码&＃xff1a;

window.callHandler(JSON.stringify({type: "scan",data: "",callback: function(data) {} }));

这种方式的牛逼之处在于&＃xff0c;JS 调用是同步的&＃xff0c;可以立马拿到返回值。

我们也不再需要像拦截方式一样&＃xff0c;每次传值都要把对象做 JSON.stringify&＃xff0c;可以直接传 JSON 过去&＃xff0c;也支持直接传一个函数过去。

iOS WKWebView

WKWebView 里面通过 addScriptMessageHandler 来注入对象到 JS 上下文&＃xff0c;可以在 WebView 销毁的时候调用 removeScriptMessageHandler 来销毁这个对象。

前端调用注入的原生方法之后&＃xff0c;可以通过 didReceiveScriptMessage 来接收前端传过来的参数。

WKWebView *wkWebView &＃61; [[WKWebView alloc] init]; WKWebViewConfiguration *configuration &＃61; wkWebView.configuration; WKUserContentController *userCC &＃61; configuration.userContentController;// 注入对象 [userCC addScriptMessageHandler:self name:&＃64;"nativeObj"]; // 清除对象 [userCC removeScriptMessageHandler:self name:&＃64;"nativeObj"];// 客户端处理前端调用 - (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message {// 获取前端传来的参数NSDictionary *msgBody &＃61; message.body;// 如果是 nativeObj 就进行相应处理if (![message.name isEqualToString:&＃64;"nativeObj"]) {// return;} }

使用 addScriptMessageHandler 注入的对象实际上只有一个 postMessage 方法&＃xff0c;无法调用更多自定义方法。前端的调用方式如下&＃xff1a;

window.webkit.messageHandlers.nativeObj.postMessage(data);

需要注意的是&＃xff0c;这种方式要求 iOS8 及以上&＃xff0c;而且返回不是同步的。和 UIWebView 一样的是&＃xff0c;也支持直接传 JSON 对象&＃xff0c;不需要 stringify。

Android addJavascriptInterface

安卓4.2之前注入 JS 一般是使用 addJavascriptInterface &＃xff0c;和前面的 addScriptMessageHandler 有一些类似&＃xff0c;但又没有它的限制。

public void addJavascriptInterface() {mWebView.addJavascriptInterface(new DatePickerJSBridge(), "DatePickerBridge");} private class PickerJSBridge {public void _pick(...) {} }

在 JS 里面调用&＃xff1a;

window.DatePickerBridge._pick(...)

但这种方案有一定风险&＃xff0c;可以参考这篇文章&＃xff1a;WebView中接口隐患与手机挂马利用

在 Android4.2 之后提供了 &＃64;JavascriptInterface 注解&＃xff0c;暴露给 JS 的方法必须要带上这个。

所以前面的 _pick 方法需要带上这个注解。

private class PickerJSBridge {&＃64;JavascriptInterfacepublic void _pick(...) {} }

Native 调用 JS

Native 调用 JS 一般就是直接 JS 代码字符串&＃xff0c;有些类似我们调用 JS 中的 eval 去执行一串代码。一般有 loadUrl、evaluateJavascript 等几种方法&＃xff0c;这里逐一介绍。

但是不管哪种方式&＃xff0c;客户端都只能拿到挂载到 window 对象上面的属性和方法。

Android

在 Android 里面需要区分版本&＃xff0c;在安卓4.4之前的版本支持 loadUrl&＃xff0c;使用方式类似我们在 a 标签的 href 里面写 JS 脚本一样&＃xff0c;都是Javascript:xxx 的形式。

这种方式无法直接获取返回值。

webView.loadUrl("Javascript:foo()")

在安卓4.4以上的版本一般使用 evaluateJavascript 这个 API 来调用。这里需要判断一下版本。

if (Build.VERSION.SDK_INT > 19) //see what wrapper we have {webView.evaluateJavascript("Javascript:foo()", null); } else {webView.loadUrl("Javascript:foo()"); }

UIWebView

在 iOS 的 UIWebView 里面使用 stringByEvaluatingJavascriptFromString 来调用 JS 代码。这种方式是同步的&＃xff0c;会阻塞线程。

results &＃61; [self.webView stringByEvaluatingJavascriptFromString:"foo()"];

WKWebView

WKWebView 可以使用 evaluateJavascript 方法来调用 JS 代码。

[self.webView evaluateJavascript:&＃64;"document.body.offsetHeight;" completionHandler:^(id _Nullable response, NSError * _Nullable error) {// 获取返回值 response}];

JS Bridge 设计

前面讲完了 JS 和 Native 互调的所有方法&＃xff0c;这里来介绍一下我们这边 JS Bridge 的设计吧。

我们这边的 JS Bridge 通信是基于 WebViewJavascriptBridge 这个库来实现的。

主要是结合 Scheme 协议&＃43;上下文注入来做。考虑到 Android 和 iOS 不一样的通信方式&＃xff0c;这里进行了封装&＃xff0c;保证提供给外部的 API 一致。

具体功能的调用我们封装成了 npm 包&＃xff0c;下面的是几个基础 API&＃xff1a;

callHandler(name, params, callback)&＃xff1a;这个是调用 Native 功能的方法&＃xff0c;传模块名、参数、回调函数给 Native。
hasHandler(name)&＃xff1a;这个是检查客户端是否支持某个功能的调用。
registerHandler(name)&＃xff1a;这个是提前注册一个函数&＃xff0c;等待 Native 回调&＃xff0c;比如 pageDidBack 这种场景。

那么这几个 API 又是如何实现的呢&＃xff1f;这里 Android 和 iOS 封装不一致&＃xff0c;应当分开来说。

Android Bridge

前面我们有说过安卓可以通过 &＃64;JavascriptInterface 注解来将对象和方法暴露给 JS。

所以这里的几个方法都是通过注解暴露给 JS 来调用的&＃xff0c;在 JS 层面做了一些兼容处理。

hasHandler

首先最简单的是这个 hasHandler&＃xff0c;就是在客户端里面维护一张表&＃xff08;其实我们是写死的&＃xff09;&＃xff0c;里面有支持的 Bridge 模块信息&＃xff0c;只需要用 switch...case 判断一下就行了。

&＃64;JavascriptInterface public boolean hasHandler(String cmd) {switch (cmd) {case xxx:case yyy:case zzz:return true;}return false;}

callHandler

然后我们来看 callHandler 这个方法&＃xff0c;它是提供 JS 调用 Native 功能的方法。在调用这个方法之前&＃xff0c;我们一般需要先判断一下 Native 是否支持这个功能。

function callHandler(name, params, callback) {if (!window.WebViewJavascriptBridge.hasHandler(name)) {} }

如果 Native 没有支持这个 Bridge&＃xff0c;我们就需要对回调进行兼容性处理。这个兼容性处理包括两个方面&＃xff0c;一个是功能方面&＃xff0c;一个是 callback 的默认回参。

比如我们调用 Native 的弹窗功能&＃xff0c;如果客户端没支持这个 Bridge&＃xff0c;或者我们是在浏览器里面打开的这个页面&＃xff0c;此时应该降级到使用 Web 的 alert 弹窗。

对于 callback&＃xff0c;我们可以默认给传个 0&＃xff0c;表示当前不支持这个功能。

假设这个 alert 的 bridge 接收两个参数&＃xff0c;分别是 title 和 content&＃xff0c;那么此时就应该使用浏览器自带的 alert 展示出来。

function fallback(params, callback) {let content &＃61; &＃96;${params.title}\n{params.content}&＃96;window.alert(content);callback && callback(0) }

这个 fallback 函数我们希望能够更加通用&＃xff0c;每个调用方法都应该有自己的 fallback 函数&＃xff0c;所以前面的 callHandler 应该设计成这样&＃xff1a;

function callHandler(name, params, fallback) {return function(...rest, callback) {const paramsList &＃61; {};for (let i &＃61; 0; i < params.length; i&＃43;&＃43;) {paramsList[params] &＃61; rest[i];}if (!callback) {callback &＃61; function(result) {};}if (fallback && !window.WebViewJavascriptBridge.hasHandler(name))) {fallback(paramsList, callback);} else {window.WebViewJavascriptBridge.callHandler(name, params, callback);}} }

我们可以基于这个函数封装一些功能方法&＃xff0c;比如前面的 alert&＃xff1a;

function fallback(params, callback) {let content &＃61; &＃96;${params.title}\n{params.content}&＃96;window.alert(content);callback && callback(0) }function alert(title,content,cb: any ) {return callHandler(&＃39;alert&＃39;,[&＃39;title&＃39;, &＃39;content&＃39;],fallback)(title, content, cb); } alert(&＃96;this is title&＃96;, &＃96;hahaha&＃96;, function() {console.log(&＃39;success&＃39;) })

具体效果类似下面这种&＃xff0c;这是从 Google 上随便找的一张图&＃xff08;侵删&＃xff09;&＃xff1a;

那么客户端又如何实现回调 callback 函数的呢&＃xff1f;前面说过&＃xff0c;客户端想调用 JS 方法&＃xff0c;只能调用挂载到 window 对象上面的。

因此&＃xff0c;这里使用了一种很巧妙的方法&＃xff0c;实际上 callback 函数依然是 JS 执行的。

在调用 Native 之前&＃xff0c;我们可以先将 callback 函数和一个 uniqueId 映射起来&＃xff0c;然后存在 JS 本地。我们只需要将 callbackId 传给 Native 就行了。

function callHandler(name, data, callback) {const id &＃61; &＃96;cb_${uniqueId&＃43;&＃43;}_${new Date().getTime()}&＃96;;callbacks[id] &＃61; callback;window.bridge.send(name, JSON.stringify(data), callbackId) }

在客户端这里&＃xff0c;当 send 方法接收到参数之后&＃xff0c;会执行相应功能&＃xff0c;然后使用 webView.loadUrl 主动调用前端的一个接收函数。

&＃64;JavascriptInterface public void send(final String cmd, String data, final String callbackId) {// 获取数据&＃xff0c;根据 cmd 来调用对应功能// 调用结束后&＃xff0c;回调前端 callbackString js &＃61; String.format("Javascript: window.bridge.onReceive(\&＃39;%1$s\&＃39;, \&＃39;%2$s\&＃39;);", callbackId, result.toDataString());webView.loadUrl(js); }

所以 JS 需要事前定义好这个 onReceive 方法&＃xff0c;它接收一个 callbackId 和一个 result。

window.bridge.onReceive &＃61; function(callbackId, result) {let params &＃61; {};try {params &＃61; JSON.parse(result)} catch (err) {//}if (callbackId) {const callback &＃61; callbacks[callbackId];callback(params)delete callbacks[callbackId];} }

大致流程如下&＃xff1a;

registerHandler

注册的流程比较简单&＃xff0c;也是我们把 callback 函数事先存到一个 messageHandler 对象里面&＃xff0c;不过这次的 key 不再是一个随机的 id&＃xff0c;而是 name。

function registerHandler(handlerName, callback) {if (!messageHandlers[handlerName]) {messageHandlers[handlerName] &＃61; [handler];} else {// 支持注册多个 handlermessageHandlers[handlerName].push(handler);} } // 检查是否有这个注册可以直接检查 messageHandlers 里面是否有 function hasRegisteredHandler(handlerName) {let has &＃61; false;try {has &＃61; !!messageHandlers[handlerName];} catch (exception) {}return has;}

这里不像 callHandler 需要主动调用 window.bridge.send 去通知客户端&＃xff0c;只需要等客户端到了相应的时机来调用 window.bridge.onReceive 就行了。

所以这里还需要改造一下 onReceive 方法。由于不再会有 callbackId 了&＃xff0c;所以客户端可以传个空值&＃xff0c;然后将 handlerName 放到 result 里面。

这种情况下的流程如下&＃xff0c;可以发现完全不需要 JS 调用 Native&＃xff1a;

iOS Bridge

讲完了 Android&＃xff0c;我们再来讲讲 iOS&＃xff0c;原本 iOS 可以和 Android 设计一致&＃xff0c;可是由于种种原因导致有不少差异。

iOS 和 Android 中最显著的差异就在于这个 window.bridge.send 方法的实现&＃xff0c;Android 里面是直接调用 Native 的方法&＃xff0c;iOS 中是通过 URL Scheme 的形式调用。

协议依然是 WebViewJavascriptBridge 里面的协议&＃xff0c;URL Scheme 本身不会传递数据&＃xff0c;只是告诉 Native 有新的调用。

然后 Native 会去调用 JS 的方法&＃xff0c;获取队列里面所有需要执行的方法。

所以我们需要事先创建好一个 iframe&＃xff0c;插入到 DOM 里面&＃xff0c;方便后续使用。

const CUSTOM_PROTOCOL_SCHEME &＃61; &＃39;wvjbscheme&＃39;; const QUEUE_HAS_MESSAGE &＃61; &＃39;__WVJB_QUEUE_MESSAGE__&＃39;; function _createQueueReadyIframe(doc) {messagingIframe &＃61; doc.createElement(&＃39;iframe&＃39;);messagingIframe.style.display &＃61; &＃39;none&＃39;;messagingIframe.src &＃61; CUSTOM_PROTOCOL_SCHEME &＃43; &＃39;://&＃39; &＃43; QUEUE_HAS_MESSAGE;doc.documentElement.appendChild(messagingIframe);}

callHandler

每次调用的时候只需要复用这个 iframe 就行了。这里是处理 callback 并通知 Native 的代码&＃xff1a;

通知 Native 之后&＃xff0c;它怎么拿到我们的 handlerName 和 data 呢&＃xff1f;我们可以实现一个 fetchQueue 的方法。

function _fetchQueue() {const messageQueueString &＃61; JSON.stringify(sendMessageQueue);sendMessageQueue &＃61; [];return messageQueueString;}

然后将其挂载到 window.WebViewJavascriptBridge 对象上面。

window.WebViewJavascriptBridge &＃61; {_fetchQueue: _fetchQueue};

这样 iOS 就可以使用 evaluateJavascript 轻松拿到这个 messageQueue。

- (void)flushMessageQueue {[_webView evaluateJavascript:&＃64;"WebViewJavascriptBridge._fetchQueue();" completionHandler:^(id _Nullable result, NSError * _Nullable error) {[self _flushMessageQueue:result];}]; } - (void)_flushMessageQueue:(id)messageQueueObj {// 解析 messageQueueString// 根据传入的 handlerName 执行对应操作 }

那么 iOS 又是如何回调 JS 的 callback 函数呢&＃xff1f;这个其实和 Android 的 onReceive 是同样的原理。

这里可以实现一个 _handleMessageFromObjC 方法&＃xff0c;同样挂载到 window.WebViewJavascriptBridge 对象上面&＃xff0c;等待 iOS 回调。

function _dispatchMessageFromObjC(messageJSON) {const message &＃61; JSON.parse(messageJSON);if (message.responseId) {var responseCallback &＃61; callbacks[message.responseId];if (!responseCallback) {return;}responseCallback(message.responseData);delete callbacks[message.responseId];} }

流程如下图&＃xff1a;

registerHandler

registerHandler 和 Android 原理是一模一样的&＃xff0c;都是提前注册一个事件&＃xff0c;等待 iOS 调用&＃xff0c;具体就不多讲了&＃xff0c;这里直接放代码&＃xff1a;

// 注册 function registerHandler(handlerName, handler) {if (typeof messageHandlers[handlerName] &＃61;&＃61;&＃61; &＃39;undefined&＃39;) {messageHandlers[handlerName] &＃61; [handler];} else {messageHandlers[handlerName].push(handler);}} // 回调 function _dispatchMessageFromObjC(messageJSON) {const message &＃61; JSON.parse(messageJSON);if (message.responseId) {var responseCallback &＃61; callbacks[message.responseId];if (!responseCallback) {return;}responseCallback(message.responseData);delete callbacks[message.responseId];} else if (message.handlerName){handlers &＃61; messageHandlers[message.handlerName];for (let i &＃61; 0; i < handlers.length; i&＃43;&＃43;) {try {handlers[i](message.data, responseCallback);} catch (exception) {}}} }

总结

这些就是 Hybrid 里面 JS 和 Native 交互的大致原理&＃xff0c;忽略了不少细节&＃xff0c;比如初始化 WebViewJavascriptBridge 对象等等&＃xff0c;感兴趣的也可以参考一下这个库&＃xff1a;JsBridge

关于奇舞精选

《奇舞精选》是360公司专业前端团队「奇舞团」运营的前端技术社区。关注公众号后&＃xff0c;直接发送链接到后台即可给我们投稿。

奇舞团是360集团最大的大前端团队&＃xff0c;代表集团参与W3C和Ecma会员&＃xff08;TC39&＃xff09;工作。奇舞团非常重视人才培养&＃xff0c;有工程师、讲师、翻译官、业务接口人、团队Leader等多种发展方向供员工选择&＃xff0c;并辅以提供相应的技术力、专业力、通用力、领导力等培训课程。奇舞团以开放和求贤的心态欢迎各种优秀人才关注和加入奇舞团。