在移动互联网爆发的黄金年代，几乎所有前端和客户端同学都吵过一个架：运营要改个大促活动的规则、换个 banner 位，前端改完代码刷新页面就上线了，客户端却要走「打包→提审→等苹果 / 安卓商店审核→用户下载更新」的完整流程，顺利的话 3 天，遇到审核被打回，一周都搞不定 —— 等功能上线，活动都快结束了。

原生开发的静态化短板，和业务对「动态化、快迭代」的强需求，形成了不可调和的矛盾。也正是在这个背景下，Hybrid 混合开发架构成了行业的标准答案：用原生做 App 外壳和底层能力底座，用 Web 承载高频迭代的业务 UI 和逻辑，兼顾原生的能力边界和 Web 的动态灵活性。

而能让两个完全隔离、语言不通的运行环境顺畅对话的核心纽带，就是我们这一节要拆解的主角 ——JSBridge。它不是什么复杂的黑科技，却是整个混合开发时代最核心的底层基建，哪怕到了今天的小程序、跨端框架时代，它的核心设计思想依然在被沿用。

1. 为什么我们必须要有 JSBridge？

搞懂 JSBridge 的前提，是先理解 Hybrid 架构里「两个世界的绝对隔离」。

在 Hybrid 架构中，所有 Web 页面都运行在原生提供的 WebView 容器里，而 Web 的 JavaScript 运行环境，和原生的 Java/Kotlin（安卓）/Objective-C/Swift（iOS）运行环境，是两个完全独立、相互隔离的沙箱：

• Web 端（JS） ：天生自带极致的动态化能力，代码改完实时生效，不用发版不用审核；但被浏览器沙箱牢牢限制，无法直接访问设备底层硬件（摄像头、蓝牙、陀螺仪、本地文件系统），也无法调用系统级的原生 UI 组件和能力，能做的事被死死框在浏览器的能力边界里。
• Native 端：手握设备的所有权限，能调用所有系统 API，渲染性能拉满；但代码是静态编译的，只要改一行逻辑，就必须走完整的发版审核流程，完全跟不上业务的快节奏迭代。

一边是动态性拉满但能力受限的 Web，一边是能力拉满但动态性为零的 Native，想要让两者结合发挥最大价值，就必须在两个隔离的沙箱之间，架起一座能双向通行、能翻译两端语言的桥梁 —— 这就是 JSBridge 的核心价值：打通 Web 与 Native 的通信壁垒，实现双向的方法调用和数据传递。

2. JSBridge 的核心通信原理

JSBridge 的双向通信，本质上就是两个方向的问题拆解：Native 调用 JS，以及 JS 调用 Native。所有 Hybrid 架构的底层逻辑，都绕不开这两个核心方向的实现。

2.1 Native 调用 JavaScript：简单直接的代码执行

这个方向的实现逻辑非常朴素，甚至可以说没有什么技术门槛：Native 作为 WebView 的宿主，本身就拥有直接在 WebView 的 JS 上下文里执行代码的权限，本质就是「原生拼接一段 JS 代码字符串，交给 WebView 去执行」。

只是随着系统版本的迭代，有了更高效、更完善的实现方案：

• 安卓端：早期安卓 API 19 之前，只能用webView.loadUrl("javascript:methodName(params)")实现。这个方案坑非常多：不仅会触发页面刷新，还无法获取 JS 方法的返回值，多次高频调用还会出现阻塞和丢消息的问题，踩过这个坑的老安卓开发应该深有体会。从 API 19（安卓 4.4）开始，官方推出了webView.evaluateJavascript("methodName(params)", callback)，不仅执行效率大幅提升，还能通过回调异步获取 JS 执行后的返回值，成了现在的主流方案。
• iOS 端：早期的 UIWebView 性能差、内存泄漏问题严重，早已被淘汰；目前主流的 WKWebView，通过evaluateJavaScript:completionHandler:方法执行 JS 代码，同样支持异步获取执行结果，稳定性和性能都有质的提升。

这里要提一个工业级实现里的小细节：Native 调用 JS 时，一定要保证执行时机是在 WebView 的页面加载完成之后（也就是onPageFinished/didFinishNavigation回调之后），否则会出现 JS 上下文还没初始化、方法找不到的问题，这是新手最容易踩的坑之一。

2.2 JavaScript 调用 Native：从兼容到高效的三大方案

和 Native 调 JS 不同，Web 端没有直接执行原生代码的权限，所以这个方向的实现会更复杂。行业里经过多年的迭代，从「兼容优先」到「性能优先」，最终沉淀出了三种主流实现方案，每一种都带着鲜明的时代特征。

方案一：URL Scheme 拦截（早期行业主流，兼容性天花板）

这是 Hybrid 发展早期最经典、兼容性最强的方案，也是当年微信、手淘等超级 App 最早用的方案。

它的核心逻辑非常巧妙：

1. JS 端通过创建隐藏的 iframe，或者直接修改window.location.href，发起一个自定义协议的请求，比如myapp://camera/open?callbackId=123&params={"quality":1080}；
2. Native 端在 WebView 的导航拦截回调里（安卓的shouldOverrideUrlLoading、iOS 的decidePolicyForNavigationAction），捕获到这个请求；
3. 原生端解析这个自定义 URL 的协议、方法名、参数，执行对应的原生能力，再通过回调把结果返回给 JS 端。

这个方案的优势是全版本兼容，哪怕是非常老旧的系统版本，也能完美支持，没有安全风险；但缺点也很明显：URL 有长度限制，参数太长会被截断，而且每次发起请求都有一定的性能开销，高频调用场景下会有明显的延迟。

方案二：拦截 JS 全局弹窗方法（小众补位方案）

这是一个偏门的补位方案，核心原理是：Web 端调用alert()、confirm()、prompt()这三个全局弹窗方法时，Native 端可以通过 WebView 的回调拦截到调用内容和参数，其中prompt()支持字符串返回值，刚好能满足通信的需求。

但这个方案的缺点非常致命：需要侵入浏览器的全局方法，可能会影响页面的正常业务逻辑，而且通信性能一般，所以行业里几乎不会把它作为主力通信方案，只会作为极端场景下的兜底兼容方案。

方案三：API 对象注入（现代主流，性能天花板）

这是目前行业里的绝对主流方案，也是性能最高、开发体验最好的方案。核心逻辑是：Native 端直接向 WebView 的 JS 执行上下文，注入一个挂载在 window 上的全局原生 API 对象，JS 端可以像调用普通 JS 方法一样，直接调用这个对象上的原生能力，几乎没有额外的性能开销。

• 安卓端：通过addJavascriptInterface方法注入全局对象。很多人听说过这个方案有安全漏洞，其实是在 API 17（安卓 4.2）之前，没有严格的方法注解限制，会导致恶意页面通过反射执行任意原生代码，出现严重的安全问题；但在 API 17 之后，官方引入了@JavascriptInterface注解，只有加了注解的方法才能被 JS 调用，安全问题已经被彻底解决。
• iOS 端（WKWebView） ：通过WKScriptMessageHandler协议注入消息处理对象，JS 端通过window.webkit.messageHandlers.<自定义名称>.postMessage()就能把消息发送给原生端，没有安全风险，性能也拉满。

3. 工业级 Hybrid 架构设计：从能用，到稳定好用

搞懂了底层的通信原理，只是跨进了 Hybrid 开发的门槛。在微信、手淘这类亿级用户的超级 App 里，一套成熟的 Hybrid 架构，绝不是简单的方法调用就能搞定的 —— 我们需要设计一套稳定、安全、易扩展、可排查的完整架构体系。

一个经过工业级验证的 Hybrid 架构，从上到下分为 5 个核心层级，每一层都有明确的职责边界和设计考量：

第一层：业务层（Web App）

这一层就是前端开发者最熟悉的部分：基于 Vue/React 等框架开发的业务页面，比如电商的活动页、资讯的详情页。业务代码不需要关心底层的通信细节，只需要引入封装好的 JSBridge SDK，像调用普通前端 API 一样调用原生能力即可。

第二层：JS SDK 封装层（Hybrid 架构的前端核心）

这一层是整个架构的前端门面，也是保证开发体验和稳定性的关键，绝不是简单的方法透传。一个成熟的 SDK，必须包含这些核心能力：

1. 异步回调管理：JSBridge 通信本质上是异步的，SDK 需要维护一个全局的请求池，每次 JS 调用原生能力时，生成一个唯一的callbackId，把回调函数和 ID 绑定后存入请求池，再把 ID 和参数传给原生；原生执行完毕后，带着callbackId回调 JS，SDK 再通过 ID 找到对应的 Promise，执行 resolve/reject，完美适配前端的异步开发习惯。
2. 消息队列与防抖：在页面初始化、高频操作等场景，会出现短时间内大量调用 Bridge 的情况，为了防止消息丢失、Native 线程阻塞，SDK 会维护一个消息队列，把并发的调用打包成批量消息，在空闲时间统一发送给原生。
3. 超时与错误重试：针对原生调用超时、失败的场景，SDK 需要内置超时机制和重试策略，避免业务 Promise 一直 pending，同时给出明确的错误提示，方便业务做兜底处理。
4. 参数序列化与版本兼容：处理两端的参数类型兼容问题，同时针对不同 App 版本的 Bridge 能力差异，做优雅的降级兼容，避免低版本 App 出现方法找不到的报错。

第三层：Native Bridge 层（Hybrid 架构的原生核心）

这一层是原生侧的调度中心，负责承接 JS 端的所有请求，核心职责有 3 个：

1. 协议解析与分发：接收 JS 端传来的 JSON 格式数据，解析出目标模块、方法名和参数，分发到对应的原生能力模块执行，同时把执行结果封装成统一格式返回给 JS 端。
2. 严格的权限校验：这是整个架构的安全生命线！必须做两层校验：一是校验当前加载的页面域名，是否在 App 的白名单内，防止恶意第三方页面调用 Bridge 能力；二是校验当前页面是否有权限调用对应的 API，比如非核心业务页面，不能调用通讯录、短信等敏感权限，从根源上避免用户隐私泄露。
3. 生命周期管理：和 WebView 的生命周期绑定，页面销毁时，清空对应的回调池和消息队列，防止内存泄漏和无效回调。

第四层：原生能力插件层

这一层是 Hybrid 架构的能力底座，我们会把所有原生能力拆成独立的插件模块：比如设备信息、网络请求、摄像头、文件系统、原生 UI 组件（导航栏、弹窗、Loading）等等。

插件化设计的核心优势是解耦和易扩展：新增一个原生能力，只需要新增一个插件模块，不用修改 Bridge 核心层的代码；同时可以按需加载，避免核心包体积过大，这对超级 App 来说至关重要。

第五层：监控与埋点层

这一层是线上稳定性的保障，也是很多新手会忽略的一层。工业级的架构里，必须内置完整的监控能力：Bridge 调用的成功率、耗时、错误类型、TOP 报错场景，都要做完整的埋点上报。一旦线上出现问题，我们能快速定位是前端参数问题，还是原生执行出错，而不是两眼一抹黑。

4. 总结

JSBridge 从来都不是什么高深的技术，它的核心价值，是用最巧妙的方式，打破了 Web 和 Native 两个隔离世界的壁垒。它就像一个优秀的翻译官，让动态灵活的 Web，和能力强大的 Native，能顺畅对话、各司其职，也让 Hybrid 架构成了移动互联网时代，解决「动态化」需求的最优解。

但 Hybrid 架构从诞生的那天起，就有一个无法逾越的天花板：渲染性能。它的 UI 渲染始终依赖 WebView 浏览器引擎，在长列表滚动、复杂交互动画等场景下，DOM 操作的开销、JS 线程和渲染线程的互斥，导致它的流畅度始终无法和纯原生相提并论。

为了彻底突破 WebView 渲染的性能瓶颈，跨端技术开始向着两个全新的方向演进：一个是以 React Native 为代表的「JS 驱动原生渲染」架构，另一个是以 Flutter 为代表的「自绘引擎」架构。这也是我们下一节要深入探讨的，跨端技术的第二次革命性演进。