随着 Web 技术和移动设备的快速发展,Hybrid 技术已经成为一种最主流最多见的方案。一套好的 Hybrid架构方案 能让 App 既能拥有极致的体验和性能,同时也能拥有 Web技术 灵活的开发模式、跨平台能力以及热更新机制。javascript
Hybrid App,俗称混合应用,即混合了 Native技术 与 Web技术 进行开发的移动应用。如今比较流行的混合方案主要有三种,主要是在UI渲染机制上的不一样:前端
以上的三种方案,其实一样都是基于 JSBridge 完成的通信层,第二三种方案,其实能够看作是在方案一的基础上,继续经过不一样的新技术进一步提升了应用的混合程度。所以,JSBridge 也是整个混合应用最关键的部分。java
Hybrid App的本质,实际上是在原生的 App 中,使用 WebView 做为容器直接承载 Web页面。所以,最核心的点就是 Native端 与 H5端 之间的双向通信层,其实这里也能够理解为咱们须要一套跨语言通信方案,来完成 Native(Java/Objective-c/...) 与 JavaScript 的通信。这个方案就是咱们所说的 JSBridge,而实现的关键即是做为容器的 WebView,一切的原理都是基于 WebView 的机制。web
基于 WebView 的机制和开放的 API, 实现这个功能有三种常见的方案:小程序
第二三种机制的原理是相似的,都是经过对 WebView 信息冒泡传递的拦截,从而达到通信的,接下来咱们主要从 原理-定制协议-拦截协议-参数传递-回调机制 5个方面详细阐述下第三种方案 -- URL拦截方案。安全
在 WebView 中发出的网络请求,客户端都能进行监听和捕获服务器
咱们须要制定一套URL Scheme规则,一般咱们的请求会带有对应的协议开头,例如常见的 https://xxx.com 或者 file://1.jpg,表明着不一样的含义。咱们这里能够将协议类型的请求定制为:微信
xxcommand://xxxx?param1=1¶m2=2
这里有几个须要注意点的是:网络
(1) xxcommand:// 只是一种规则,能够根据业务进行制定,使其具备含义架构
不一样的协议头表明着不一样的含义,这样便能清楚知道每一个协议的适用范围。
(2) 这里不要使用 location.href 发送,由于其自身机制有个问题是同时并发屡次请求会被合并成为一次,致使协议被忽略,而并发协议实际上是很是常见的功能。
(3) 一般考虑到安全性,须要在客户端中设置域名白名单或者限制。
客户端能够经过 API 对 WebView 发出的请求进行拦截:
当解析到请求 URL 头为制定的协议时,便不发起对应的资源请求,而是解析参数,并进行相关功能或者方法的调用,完成协议功能的映射。
因为协议的本质实际上是发送请求,这属于一个异步的过程,所以咱们便须要处理对应的回调机制。这里咱们采用的方式是JS的事件系统,这里咱们会用到 window.addEventListener
和 window.dispatchEvent
这两个基础API;
因为 WebView 对 URL 会有长度的限制,所以常规的经过 search参数 进行传递的方式便具备一个问题,既 当须要传递的参数过长时,可能会致使被截断,例如传递base64或者传递大量数据时。
所以咱们须要制定新的参数传递规则,咱们使用的是函数调用的方式。这里的原理主要是基于:
Native 能够直接调用 JS 方法并直接获取函数的返回值。
咱们只须要对每条协议标记一个惟一标识,并把参数存入参数池中,到时客户端再经过该惟一标识从参数池中获取对应的参数便可。
因为 Native 能够算做 H5 的宿主,所以拥有更大的权限,上面也提到了 Native 能够经过 WebView API直接执行 Js 代码。这样的权限也就让这个方向的通信变得十分的便捷。
// Swift webview.stringByEvaluatingJavaScriptFromString("alert('NativeCall')")
// 调用js中的JSBridge.trigger方法 // 该方法的弊端是没法获取函数返回值; webView.loadUrl("javascript:JSBridge.trigger('NativeCall')")
基于上面的原理,咱们已经明白 JSBridge 最基础的原理,而且能实现 Native <=> H5 的双向通信机制了。
接下来,咱们来理下代码上须要的资源。实现这套方案,从上图能够看出,其实能够分为两个部分:
咱们这里的作法是,将这两部分一块儿封装成一个 Native SDK,由客户端统一引入。客户端在初始化一个 WebView 打开页面时,若是页面地址在白名单中,会直接在 HTML 的头部注入对应的 bridge.js。这样的作法有如下的好处:
这里有一点须要注意的是,协议的调用,必定是须要确保执行在bridge.js 成功注入后。因为客户端的注入行为属于一个附加的异步行为,从H5方很难去捕捉准确的完成时机,所以这里须要经过客户端监听页面完成后,基于上面的事件回调机制通知 H5端,页面中便可经过window.addEventListener('bridgeReady', e => {})
进行初始化。
将 H5 接入 App 中一般有两种方式:
(1) 在线H5,这是最多见的一种方式。咱们只须要将H5代码部署到服务器上,只要把对应的 URL地址 给到客户端,用 WebView 打开该URL,便可嵌入。该方式的好处在于:
但相对的,这种方式也有对应的缺点:
一般,这种方式更适用在一些比较轻量级的页面上,例如一些帮助页、提示页、使用攻略等页面。这些页面的特色是功能性不强,不太须要复杂的功能协议,且不须要离线使用。在一些第三方页面接入上,也会使用这种方式,例如咱们的页面调用微信JS-SDK。
(2) 内置包H5,这是一种本地化的嵌入方式,咱们须要将代码进行打包后下发到客户端,并由客户端直接解压到本地储存中。一般咱们运用在一些比较大和比较重要的模块上。其优势是:
但同时,它的劣势也十分明显:
这两种接入方式均有本身的优缺点,应该根据不一样场景进行选择。