关于 JSBridge,绝大多数同学最早遇到的是微信的 WeiXinJSBridge(现在被封装成 JSSDK),各种 Web 页面可以通过 Bridge 调用微信提供的一些原生功能,为用户提供相关的功能。其实,JSBridge很早就出现在软件开发中,在一些桌面软件中很早就运用了这样的形式,多用在通知、产品详情、广告等模块中,然后这些模块中,使用的是 WebUI,而相关按钮点击后,调用的是Native功能。现在移动端盛行,不管是Hybrid应用,还是React-Native都离不开JSBridge,当然也包括在国内举足轻重的微信小程序。那么,JSBridge到底是什么?它的出现是为了什么?它究竟是怎么实现的?在这篇文章中,会在移动混合开发的范畴内,将给大家带来 JSBridge 的深入剖析。
1 前言
有些童鞋听到JSBridge这个名词,就是觉得非常高上大,有了它Web和Native可以进行交互,就像『进化药水』,让Web摇身一变,成为移动战场的『上将一名』。其实并非如此,JSBridge 其实真是一个很简单的东西,更多的是一种形式、一种思想。
2 JSBridge 的起源
为什么是 JSBridge ?而不是 PythonBridge 或是 RubyBridge ?
当然不是因为 JavaScript 语言高人一等(虽然斯坦福大学已经把算法导论的语言从 Java 改成 JavaScript,小得意一下,嘻嘻),主要的原因还是因为 JavaScript 主要载体 Web 是当前世界上的最易编写、最易维护、最易部署的UI构建方式。工程师可以用很简单的HTML标签和CSS样式快速的构建出一个页面,并且在服务端部署后,用户不需要主动更新,就能看到最新的 UI 展现。
因此,开发维护成本和 更新成本较低的 Web 技术成为混合开发中几乎不二的选择,而作为Web技术逻辑核心的JavaScript也理所应当肩负起与其他技术『桥接』的职责,并且作为移动不可缺少的一部分,任何一个移动操作系统中都包含可运行JavaScript的容器,例如WebView和JSCore。所以,运行JavaScript不用像运行其他语言时,要额外添加运行环境。因此,基于上面种种原因,JSBridge 应运而生。PhoneGap(Codova 的前身)作为 Hybrid 鼻祖框架,应该是最先被开发者广泛认知的 JSBridge 的应用场景;而对于 JSBridge的应用在国内真正兴盛起来,则是因为杀手级应用微信的出现,主要用途是在网页中通过JSBridge设置分享内容。移动端混合开发中的JSBridge,主要被应用在两种形式的技术方案上:
- 基于 Web 的 Hybrid 解决方案:例如微信浏览器、各公司的 Hybrid 方案
- 非基于 Web UI 但业务逻辑基于 JavaScript 的解决方案:例如 React-Native
【注】:微信小程序基于 Web UI,但是为了追求运行效率,对 UI 展现逻辑和业务逻辑的 JavaScript 进行了隔离。因此小程序的技术方案介于上面描述的两种方式之间。
3 JSBridge 的用途
JSBridge 简单来讲,主要是 给 JavaScript 提供调用 Native 功能的接口,让混合开发中的『前端部分』可以方便地使用地址位置、摄像头甚至支付等 Native 功能。
既然是『简单来讲』,那么 JSBridge 的用途肯定不只『调用 Native 功能』这么简单宽泛。实际上,JSBridge 就像其名称中的『Bridge』的意义一样,是 Native 和非 Native 之间的桥梁,它的核心是 构建 Native 和非 Native 间消息通信的通道,而且是 双向通信的通道。
所谓 双向通信的通道:
- JS 向 Native 发送消息 : 调用相关功能、通知 Native 当前 JS 的相关状态等。
- Native 向 JS 发送消息 : 回溯调用结果、消息推送、通知 JS 当前 Native 的状态等。
这里有些同学有疑问了:消息都是单向的,那么调用 Native 功能时 Callback 怎么实现的?对于这个问题,在下一节里会给出解释。