Hybrid App技术解析 -- 原理篇

时间  2021-08-12 标签 javascript 前端 java git github web 小程序 安全 服务器 微信

引言

随着 Web 技术和移动设备的快速发展，Hybrid 技术已经成为一种最主流最多见的方案。一套好的 Hybrid架构方案 能让 App 既能拥有极致的体验和性能，同时也能拥有 Web技术 灵活的开发模式、跨平台能力以及热更新机制，想一想是否是都鸡冻不已。。😄。本系列文章是公司在这方面实践的一个总结，包含了原理解析、方案选型与实现、实践优化等方面。javascript

你们能够到github上和我进行讨论哈！前端

第二篇实战篇java

现有混合方案

Hybrid App，俗称混合应用，即混合了 Native技术 与 Web技术 进行开发的移动应用。如今比较流行的混合方案主要有三种，主要是在UI渲染机制上的不一样：git

  1. 基于 WebView UI 的基础方案，市面上大部分主流 App 都有采用，例如微信JS-SDK，经过 JSBridge 完成 H5 与 Native 的双向通信，从而赋予H5必定程度的原生能力。github

  2. 基于 Native UI 的方案，例如 React-Native、Weex。在赋予 H5 原生API能力的基础上，进一步经过 JSBridge 将js解析成的虚拟节点树(Virtual DOM)传递到 Native 并使用原生渲染。web

  3. 另外还有近期比较流行的小程序方案，也是经过更加定制化的 JSBridge，并使用双 WebView 双线程的模式隔离了JS逻辑与UI渲染，造成了特殊的开发模式，增强了 H5 与 Native 混合程度，提升了页面性能及开发体验。小程序

以上的三种方案，其实一样都是基于 JSBridge 完成的通信层，第二三种方案，其实能够看作是在方案一的基础上，继续经过不一样的新技术进一步提升了应用的混合程度。所以，JSBridge 也是整个混合应用最关键的部分，例如咱们在设置微信分享时用到的 JS-SDK，wx对象 即是咱们最多见的 JSBridge:安全

方案选型

任何技术方案的选型，其实都应该基于使用场景和现有条件。基于公司现有状况的几点考虑，在方案一上进一步优化，更加适合咱们的需求。服务器

  • 需求 Web技术 快速迭代、灵活开发的特色和线上热更新的机制。微信

  • 产品的核心能力是强大的拍照与底层图片处理能力，所以单纯的 H5技术能作的事很是有限，不能知足需求，经过 Hybrid 技术来强化H5，即是一种必需。

  • 公司业务上，并无很是复杂的UI渲染需求，并且 App 中的一系列原生 UI组件 已经很是成熟，所以咱们并不强需相似 RN 这样的方案。

所以，如何既能利用 H5 强大的开发和迭代能力，又能赋予 H5 强大的底层能力和用户体验，同时能复用现有的成熟 Native组件，便成为了咱们最大的需求点 -- 一套完整又强大的 Hybrid技术架构方案。😠

Hybrid技术原理

Hybrid App的本质，实际上是在原生的 App 中，使用 WebView 做为容器直接承载 Web页面。所以，最核心的点就是 Native端 与 H5端 之间的双向通信层，其实这里也能够理解为咱们须要一套跨语言通信方案，来完成 Native(Java/Objective-c/...) 与 JavaScript 的通信。这个方案就是咱们所说的 JSBridge，而实现的关键即是做为容器的 WebView，一切的原理都是基于 WebView 的机制。

(一) JavaScript 通知 Native

基于 WebView 的机制和开放的 API, 实现这个功能有三种常见的方案：

  • API注入，原理其实就是 Native 获取 JavaScript环境上下文，并直接在上面挂载对象或者方法，使 js 能够直接调用，Android 与 IOS 分别拥有对应的挂载方式。

  • WebView 中的 prompt/console/alert 拦截，一般使用 prompt，由于这个方法在前端中使用频率低，比较不会出现冲突；

  • WebView URL Scheme 跳转拦截；

第二三种机制的原理是相似的，都是经过对 WebView 信息冒泡传递的拦截，从而达到通信的，接下来咱们主要从 原理-定制协议-拦截协议-参数传递-回调机制 5个方面详细阐述下第三种方案 -- URL拦截方案。

1. 实现原理

在 WebView 中发出的网络请求，客户端都能进行监听和捕获

2. 协议的定制

咱们须要制定一套URL Scheme规则，一般咱们的请求会带有对应的协议开头，例如常见的 xxx.com 或者 file://1.jpg，表明着不一样的含义。咱们这里能够将协议类型的请求定制为:

xxcommand://xxxx?param1=1&param2=2

这里有几个须要注意点的是:

(1) xxcommand:// 只是一种规则，能够根据业务进行制定，使其具备含义，例如咱们定义 xxcommand:// 为公司全部App系通用，为通用工具协议：

xxcommand://getProxy?h=1

而定义 xxapp:// 为每一个App单独的业务协议。

xxapp://openCamera?h=2

不一样的协议头表明着不一样的含义，这样便能清楚知道每一个协议的适用范围。

(2) 这里不要使用 location.href 发送，由于其自身机制有个问题是同时并发屡次请求会被合并成为一次，致使协议被忽略，而并发协议实际上是很是常见的功能。咱们会使用建立 iframe 发送请求的方式。

(3) 一般考虑到安全性，须要在客户端中设置域名白名单或者限制，避免公司内部业务协议被第三方直接调用。

3.协议的拦截

客户端能够经过 API 对 WebView 发出的请求进行拦截：

  • IOS上: shouldStartLoadWithRequest

  • Android: shouldOverrideUrlLoading

当解析到请求 URL 头为制定的协议时，便不发起对应的资源请求，而是解析参数，并进行相关功能或者方法的调用，完成协议功能的映射。

4.协议回调

因为协议的本质实际上是发送请求，这属于一个异步的过程，所以咱们便须要处理对应的回调机制。这里咱们采用的方式是JS的事件系统，这里咱们会用到 window.addEventListener 和 window.dispatchEvent这两个基础API；

  • 1.发送协议时，经过协议的惟一标识注册自定义事件，并将回调绑定到对应的事件上。

  • 2.客户端完成对应的功能后，调用 Bridge 的dispatch API，直接携带 data 触发该协议的自定义事件。

经过事件的机制，会让开发更符合咱们前端的习惯，例如当你须要监听客户端的通知时，一样只须要在经过 addEventListener 进行监听便可。

Tips: 这里有一点须要注意的是，应该避免事件的屡次重复绑定，所以当惟一标识重置时，须要removeEventListener对应的事件。

5.参数传递方式

因为 WebView 对 URL 会有长度的限制，所以常规的经过 search参数 进行传递的方式便具备一个问题，既 当须要传递的参数过长时，可能会致使被截断，例如传递base64或者传递大量数据时。

所以咱们须要制定新的参数传递规则，咱们使用的是函数调用的方式。这里的原理主要是基于:

Native 能够直接调用 JS 方法并直接获取函数的返回值。

咱们只须要对每条协议标记一个惟一标识，并把参数存入参数池中，到时客户端再经过该惟一标识从参数池中获取对应的参数便可。

(二) Native 通知 Javascript

因为 Native 能够算做 H5 的宿主，所以拥有更大的权限，上面也提到了 Native 能够经过 WebView API直接执行 Js 代码。这样的权限也就让这个方向的通信变得十分的便捷。

  • IOS: stringByEvaluatingJavaScriptFromString
// Swift
webview.stringByEvaluatingJavaScriptFromString("alert('NativeCall')")
复制代码
  • Android: loadUrl (4.4-)
// 调用js中的JSBridge.trigger方法
// 该方法的弊端是没法获取函数返回值；
webView.loadUrl("javascript:JSBridge.trigger('NativeCall')")
复制代码

Tips: 当系统低于4.4时，evaluateJavascript 是没法使用的，所以单纯的使用 loadUrl 没法获取 JS 返回值，这时咱们须要使用前面提到的 prompt 的方法进行兼容，让 H5端 经过 prompt 进行数据的发送，客户端进行拦截并获取数据。

  • Android: evaluateJavascript (4.4+)
// 4.4+后使用该方法即可调用并获取函数返回值；
mWebView.evaluateJavascript（"javascript:JSBridge.trigger('NativeCall')", 	 new ValueCallback<String>() {
    @Override
    public void onReceiveValue(String value) {
        //此处为 js 返回的结果
    }
});
复制代码

基于上面的原理，咱们已经明白 JSBridge 最基础的原理，而且能实现 Native <=> H5 的双向通信机制了。

(三) JSBridge 的接入

接下来，咱们来理下代码上须要的资源。实现这套方案，从上图能够看出，其实能够分为两个部分:

  • JS部分(bridge): 在JS环境中注入 bridge 的实现代码，包含了协议的拼装/发送/参数池/回调池等一些基础功能。

  • Native部分(SDK): 在客户端中 bridge 的功能映射代码，实现了URL拦截与解析/环境信息的注入/通用功能映射等功能。

咱们这里的作法是，将这两部分一块儿封装成一个 Native SDK，由客户端统一引入。客户端在初始化一个 WebView 打开页面时，若是页面地址在白名单中，会直接在 HTML 的头部注入对应的 bridge.js。这样的作法有如下的好处：

  • 双方的代码统一维护，避免出现版本分裂的状况。有更新时，只要由客户端更新SDK便可，不会出现版本兼容的问题；

  • App的接入十分方便，只须要按文档接入最新版本的SDK，便可直接运行整套Hybrid方案，便于在多个App中快速的落地；

  • H5端无需关注，这样有利于将 bridge 开放给第三方页面使用。

这里有一点须要注意的是，协议的调用，必定是须要确保执行在bridge.js 成功注入后。因为客户端的注入行为属于一个附加的异步行为，从H5方很难去捕捉准确的完成时机，所以这里须要经过客户端监听页面完成后，基于上面的事件回调机制通知 H5端，页面中便可经过window.addEventListener('bridgeReady', e => {})进行初始化。

(四) App中 H5 的接入方式

将 H5 接入 App 中一般有两种方式：

(1) 在线H5，这是最多见的一种方式。咱们只须要将H5代码部署到服务器上，只要把对应的 URL地址 给到客户端，用 WebView 打开该URL，便可嵌入。该方式的好处在于:

  • 独立性强，有很是独立的开发/调试/更新/上线能力；
  • 资源放在服务器上，彻底不会影响客户端的包体积；
  • 接入成本很低，彻底的热更新机制。

但相对的，这种方式也有对应的缺点:

  • 彻底的网络依赖，在离线的状况下没法打开页面；
  • 首屏加载速度依赖于网络，网络较慢时，首屏加载也较慢；

一般，这种方式更适用在一些比较轻量级的页面上，例如一些帮助页、提示页、使用攻略等页面。这些页面的特色是功能性不强，不太须要复杂的功能协议，且不须要离线使用。在一些第三方页面接入上，也会使用这种方式，例如咱们的页面调用微信JS-SDK。

(2) 内置包H5，这是一种本地化的嵌入方式，咱们须要将代码进行打包后下发到客户端，并由客户端直接解压到本地储存中。一般咱们运用在一些比较大和比较重要的模块上。其优势是:

  • 因为其本地化，首屏加载速度快，用户体验更为接近原生；
  • 能够不依赖网络，离线运行；

但同时，它的劣势也十分明显:

  • 开发流程/更新机制复杂化，须要客户端，甚至服务端的共同协做；
  • 会相应的增长 App 包体积；

这两种接入方式均有本身的优缺点，应该根据不一样场景进行选择。

总结

本文主要解析了如今Hybrid App的发展示状和其基础原理，包含了

  • JavaScript 通知 Native
  • Native 通知 Javascript
  • JSBridge 的接入
  • H5 的接入

只有在了解了其最本质的实现原理后，才能对这套方案进行实现以及进一步的优化。接下来，咱们将基于上面的理论，继续探讨如何把这套方案的真正代码实现以及方案优化方案，请继续第二篇实战篇。欢迎你们一块儿讨论！更多文章内容请关注下面公众号或到github。感谢！😊

联系我们 沪ICP备13005482号-10