4、JSBridge原理：通信机制、URL Scheme拦截、JavaScript注入与回调处理

说到混合开发，JSBridge 是绕不开的核心。说白了，它就是一座桥——连接 Native 和 JavaScript 的通信桥梁。我刚开始做混合开发时，总觉得这玩意儿很神秘，后来亲手搭过几套方案后才发现，原理其实并不复杂。

今天我们就来拆解 JSBridge 的四大核心：通信机制、URL Scheme 拦截、JavaScript 注入、回调处理。嗯，每个点我都会结合项目中的实际踩坑经历来讲。

4.1 通信机制：双向通道怎么建立？

JSBridge 要解决的核心问题就两个：

  • JS 调用 Native：比如点击按钮调起相机
  • Native 调用 JS：比如 Native 把定位数据传给前端

你想想看，这两边是隔离的，一个在 WebView 里跑，一个在系统层跑。怎么打通？

我个人习惯把通信机制分为两类：

方向 实现方式 典型场景
JS → Native URL Scheme 拦截 / 注入 API 调用系统功能、获取设备信息
Native → JS WebView 执行 JS 方法 传递数据、触发前端回调

这里有个关键点：通信是异步的。JS 调用 Native 后不能立即拿到结果，必须通过回调机制来处理。我在早期项目里就犯过这个错——直接写同步调用，结果 UI 卡死，用户疯狂投诉。

核心原则：JSBridge 通信必须设计为异步模型。Native 处理完任务后，通过回调把结果传回 JS。

4.2 URL Scheme 拦截：最经典的方案

URL Scheme 拦截是早期 JSBridge 的主流方案。原理很简单：

  1. JS 创建一个隐藏的 iframe，src 设置为自定义协议（如 jsbridge://action?params=xxx）
  2. Native 端拦截 WebView 的 shouldOverrideUrlLoading 方法
  3. 解析 URL，提取 action 和参数，执行对应操作

代码示例（JS 端）：

// 创建隐藏 iframe 发送请求
function callNative(action, params, callback) {
  const iframe = document.createElement('iframe');
  iframe.style.display = 'none';
  iframe.src = `jsbridge://${action}?data=${encodeURIComponent(JSON.stringify(params))}`;
  
  // 存储回调
  window._bridgeCallback = callback;
  
  document.body.appendChild(iframe);
  setTimeout(() => {
    document.body.removeChild(iframe);
  }, 100);
}

Native 端（Android 示例）：

@Override
public boolean shouldOverrideUrlLoading(WebView view, String url) {
    if (url.startsWith("jsbridge://")) {
        Uri uri = Uri.parse(url);
        String action = uri.getHost();
        String data = uri.getQueryParameter("data");
        // 执行 Native 操作
        handleAction(action, data);
        return true;
    }
    return false;
}

注意：URL Scheme 方案有性能问题。每次调用都要创建 iframe、触发 WebView 的 URL 拦截，频繁调用时会有明显延迟。我曾经在一个扫码项目中用了这个方案，结果扫码枪连续触发时，页面直接卡死。后来换成了注入方案。

4.3 JavaScript 注入：更高效的方案

相比 URL Scheme，JavaScript 注入方案更直接。Native 端在 WebView 初始化时，把一组 API 注入到 JS 全局对象中。

Android 端使用 addJavascriptInterface：

webView.addJavascriptInterface(new JSBridge(), "NativeBridge");

public class JSBridge {
    @JavascriptInterface
    public void callCamera(String params, String callbackId) {
        // 调起相机
        // 完成后通过 callbackId 回调
    }
}

iOS 端使用 WKUserContentController：

WKUserContentController *controller = [[WKUserContentController alloc] init];
[controller addScriptMessageHandler:self name:@"NativeBridge"];

// JS 端调用
window.webkit.messageHandlers.NativeBridge.postMessage({
    action: 'callCamera',
    params: {},
    callbackId: 'cb_001'
});

JS 端使用方式：

// 注入后的全局对象
window.NativeBridge.callCamera({}, function(result) {
    console.log('相机返回:', result);
});

我的建议：如果项目对性能要求高，优先选择注入方案。它省去了 URL 解析的开销，调用速度能提升 3-5 倍。但要注意 Android 4.2 以下版本有安全漏洞，需要做兼容处理。

4.4 回调处理：如何优雅地管理异步？

回调处理是 JSBridge 中最容易出问题的环节。我见过太多项目因为回调管理混乱，导致内存泄漏或回调丢失。

核心思路：维护一个全局回调池。

// 回调管理器
const BridgeCallback = {
  _callbacks: {},
  _id: 0,
  
  // 注册回调，返回唯一 ID
  register(callback) {
    const id = 'cb_' + (++this._id);
    this._callbacks[id] = callback;
    return id;
  },
  
  // Native 调用此方法触发回调
  execute(id, data) {
    const cb = this._callbacks[id];
    if (cb) {
      cb(JSON.parse(data));
      delete this._callbacks[id]; // 执行后清理
    }
  },
  
  // 超时清理
  clean() {
    this._callbacks = {};
  }
};

// JS 调用 Native
function callNative(action, params, callback) {
  const callbackId = BridgeCallback.register(callback);
  
  // 通过注入 API 或 URL Scheme 发送
  window.NativeBridge.call(action, JSON.stringify(params), callbackId);
}

// Native 处理完成后
// 调用 window.BridgeCallback.execute(callbackId, resultData)

关键点：

  • 每个回调必须有唯一 ID
  • 回调执行后立即删除，防止内存泄漏
  • 设置超时机制，防止回调永远不触发
  • Native 端和 JS 端都要做异常处理

我曾经在一个金融项目中，因为回调池没有做超时清理，导致用户反复调用某个功能后，内存飙升到 200MB。嗯，那次被运维大哥骂得不轻。后来加了个 30 秒超时自动清理的逻辑，问题就解决了。

4.5 整体架构图

下面这张图展示了 JSBridge 的完整通信流程，我把它画成了 SVG，方便你理解：

JavaScript 侧 (WebView) 调用 NativeBridge.call() 回调池注册 callbackId 超时清理机制 URL Scheme / 注入 API Native 侧 (Android/iOS) 拦截/接收调用请求 执行 Native 操作 执行回调 window.BridgeCallback.execute(callbackId, data) 执行回调函数 通信流程总结 1. JS 调用 NativeBridge.call()，注册回调到回调池 2. 通过 URL Scheme 或注入 API 将请求发送到 Native 3. Native 执行操作后，通过 callbackId 回调 JS

4.6 避坑指南

最后，分享几个我在项目中踩过的坑：

  • URL Scheme 长度限制：iOS 的 URL Scheme 有长度限制，传大数据时会截断。我建议超过 2KB 的数据改用注入方案。
  • Android 4.2 安全漏洞：addJavascriptInterface 在 4.2 以下版本有远程执行漏洞。如果还要兼容老设备，记得加 @JavascriptInterface 注解。
  • 回调 ID 冲突：多页面场景下，回调 ID 可能重复。我习惯在 ID 前面加上页面标识，比如 page1_cb_001。
  • WebView 销毁时未清理：页面关闭时一定要调用 BridgeCallback.clean()，否则回调函数还在内存里，造成泄漏。

小技巧：调试 JSBridge 时，可以在 JS 端加一个日志队列，把所有调用记录存起来。Native 端通过注入 API 读取这个队列，就能看到完整的调用链路。这个技巧帮我解决过很多诡异的 Bug。

好了，JSBridge 的原理就讲到这里。记住一句话：通信是异步的，回调要管理好，内存泄漏要防住。把这三点做到位，你的 JSBridge 就稳了。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →