iframe 与 webview ，记录一次使用 jsBridge 遇到的 bug 解决过程

最新推荐文章于 2025-06-30 11:22:55 发布

转载

最新推荐文章于 2025-06-30 11:22:55 发布 · 2.8k 阅读

1 ·

CC 4.0 BY-SA版权

原文链接：https://juejin.im/post/5ce4b9b6e51d455d877e0c94

文章标签：

#移动开发 #前端 #json #ViewUI

在Android 9上，使用link jsBridge时遇到连续调用原生方法回调失败的bug。原因是jsBridge利用iframe.src变化和shouldOverrideUrlLoading进行通信。分析发现，iframe.src变化次数与shouldOverrideUrlLoading调用次数不一致导致问题。解决方案包括修改_fetchQueue函数以节流处理，以及在js层面封装callHandler函数以限制调用频率。整个过程揭示了网络协议的原理，寻找问题核心是关键。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

前提-出现场景

使用机型为 Android 9，API 28
使用的 jsBridge 为 link

bug 描述

在页面加载前后如果连续多次调用原生的方法，会遇到回调参数未被调用的情况。

// 多次调用如下函数， 部分 callback 将不会被调用
window.WebViewJavascriptBridge.callHandler(api, parameter, callback);

复制代码

bug 的稳定复现方式

在页面加载时通过jsBridge和原生进行10次以上的数据交换。

出现的原因

查询所得

在多篇文章(1,2)中看到是因为 jsBridge 使用 iframe 的 src 变化和 shouldOverrideUrlLoading 来实现原生与js的沟通导致的问题，而刷新 iframe 并不能保证 shouldOverrideUrlLoading 会被调用。

于是我们以此为假设进行验证

验证1： jsBridge 是否使用 iframe.src 的变化来进行js与原生的通讯

我们可以直接看看进行一次完整的通讯的调用过程。

 //依据调用链 
 window.WebViewJavascriptBridge.callHandler(api, parameter, callback);
 
 function callHandler(handlerName, data, responseCallback) {
   _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);
   //改变html内的iframe的src
   messagingIframe.src = CUSTOM_PROTOCOL_SCHEME + "://" + QUEUE_HAS_MESSAGE;
 }
 
  // 此时步骤转到原生层面
复制代码