JSBridge 原理与通信链路分析
说到混合开发，JSBridge 是个绕不开的话题。我刚开始做混合开发那会儿，总觉得这东西挺玄乎的——JS 和原生代码，一个在浏览器沙箱里，一个在系统层，它们到底是怎么「对话」的？
其实说白了，JSBridge 就是一座桥。这座桥的一端是 JavaScript，另一端是 Objective-C、Java 或者 Kotlin。它的核心任务就两个：让 JS 能调用原生能力，让原生能回调 JS 方法。
通信链路：消息是怎么传过去的？
我们先看一条完整的调用链路。假设 JS 想获取用户的相册权限：
// JS 端发起调用
window.WebViewJavascriptBridge.callHandler(
'getAlbumPermission',
{ source: 'camera' },
function(response) {
console.log('权限结果:', response)
}
)这条消息会经历以下步骤：
- JS 封装请求：生成一个唯一 callbackId，把方法名和参数打包成 JSON
- 注入到 WebView：通过 iframe 的 src 或 location.href 触发 URL Scheme
- 原生拦截：WebView 的 shouldOverrideUrlLoading 捕获请求
- 解析与执行：原生解析 JSON，调用对应 API
- 回调返回：原生通过 evaluateJavascript 执行 JS 回调函数
核心要点：整个通信是异步的。JS 不会阻塞等待原生返回结果，而是通过回调函数处理响应。
我在项目中遇到过一个问题：某个页面频繁调用 JSBridge，导致 WebView 卡顿。后来发现是每次调用都创建了新的 iframe，触发了多次 URL 拦截。嗯，这里要注意——复用同一个 iframe 能显著减少开销。
引用传递的陷阱
这块是内存泄漏的重灾区。你想想看，JS 和原生各自管理自己的内存，但 JSBridge 让它们互相持有对方的引用。一旦引用链没断开，泄漏就来了。
常见的陷阱有这几个：
| 陷阱类型 | 表现 | 后果 |
|---|---|---|
| 回调函数未释放 | JS 注册了回调，但页面销毁时没清理 | 原生持有 JS 回调引用，导致 JS 对象无法 GC |
| 原生对象被 JS 长期持有 | JS 把原生返回的对象存到了全局变量 | 原生对象无法释放，Activity/Fragment 泄漏 |
| 循环引用 | 原生持有 WebView，WebView 持有 JS 上下文，JS 又持有原生对象 | 整个 WebView 无法销毁 |
我曾经排查过一个线上问题：用户反复进入某个页面，内存一直涨。最后发现是 JS 端把原生返回的「图片选择器」对象存到了 window 上。页面关了，window 还在，原生对象就永远释放不了。
避坑指南：我曾经在项目里加了一条硬性规则——所有 JSBridge 回调必须在页面 onHide 或 onUnload 时主动注销。虽然麻烦点，但内存泄漏率直接降了 80%。
JSBridge 的两种实现模式
目前主流的有两种：URL Scheme 拦截和 JavaScript 注入。我个人的习惯是：
- URL Scheme 模式：兼容性好，但每次调用都有 URL 解析开销。适合低频调用，比如分享、登录
- JavaScript 注入模式：直接注入原生方法到 JS 上下文，调用快。适合高频调用，比如获取定位、传感器数据
但要注意，JavaScript 注入模式有个坑——注入的方法名如果和 JS 内置方法重名，会覆盖掉。我之前就遇到过有人把「alert」给覆盖了，调试时死活弹不出提示框。
内存泄漏的根因分析
为什么会泄漏？说白了就是引用链没断干净。我们画个图看看：
从图上能看出来，泄漏点就在回调返回这条链路上。如果 JS 页面已经销毁，但原生还持有回调引用，那整个 JS 上下文都释放不了。反过来也一样——JS 如果持有了原生对象，原生内存也收不回来。
我的建议：在 JSBridge 的封装层加一个「生命周期管理器」。页面销毁时，自动遍历并清理所有未完成的回调。别指望业务方每次都记得手动注销，那太理想化了。
实战中的排查思路
如果你怀疑 JSBridge 导致内存泄漏，可以按这个顺序查：
- 抓内存快照：用 Chrome DevTools 的 Memory 面板，对比进入页面前后的 JS 对象数量
- 检查回调列表：在 JSBridge 封装层打印当前待处理的回调数量，看页面离开后是否归零
- 原生侧分析：用 Android Studio 的 Memory Profiler 或 Xcode 的 Instruments，看 WebView 相关对象是否释放
- 引用链追踪：找到泄漏对象，看它的 GC Root 是什么。如果是 JSBridge 相关的，基本就定位了
我记得有一次排查了整整两天，最后发现是某个第三方 SDK 在原生侧持有了 WebView 的强引用，而 SDK 本身是个单例。那 WebView 只要创建过就永远释放不了。嗯，这种问题最头疼——不是你代码的问题，但锅得你背。
好了，JSBridge 的原理和陷阱就聊到这儿。核心就一句话：桥建好了，别忘了拆。下一节我们会聊 WebView 的内存管理，到时候会看到更多实战案例。
公众号:蓝海资料掘金营，微信deep3321