HybridApp手艺剖析原理篇

弁言

跟着 Web 手艺和挪动装备的疾速生长，Hybrid 手艺已成为一种最主流最罕见的计划。一套好的 Hybrid架构计划 能让 App 既能具有极致的体验和机能，同时也能具有 Web手艺 天真的开辟形式、跨平台才能以及热更新机制，想一想是否是都鸡冻不已。。&＃x1f604;。本系列文章是公司在这方面实践的一个总结，包含了道理剖析、计划选型与完成、实践优化等方面。

人人能够到github上和我举行议论哈！

第二篇实战篇 也已完成了哈~~

现有夹杂计划

Hybrid App，俗称夹杂运用，即夹杂了 Native手艺 与 Web手艺 举行开辟的挪动运用。如今比较盛行的夹杂计划重要有三种，主假如在UI衬着机制上的差别：

1. 基于 WebView UI 的基本计划，市面上大部份主流 App 都有采纳，比方微信JS-SDK，经由历程 JSBridge 完成 H5 与 Native 的双向通信，从而给予H5肯定水平的原生才能。
2. 基于 Native UI 的计划，比方 React-Native、Weex。在给予 H5 原生API才能的基本上，进一步经由历程 JSBridge 将js剖析成的假造节点树(Virtual DOM)通报到 Native 并运用原生衬着。
3. 别的另有近期比较盛行的小顺序计划，也是经由历程越发定制化的 JSBridge，并运用双 WebView 双线程的形式隔离了JS逻辑与UI衬着，形成了特别的开辟形式，加强了 H5 与 Native 夹杂水平，提高了页面机能及开辟体验。

以上的三种计划，实在一样都是基于 JSBridge 完成的通信层，第二三种计划，实在能够看作是在计划一的基本上，继承经由历程差别的新手艺进一步提高了运用的夹杂水平。因而，JSBridge 也是全部夹杂运用最症结的部份，比方我们在设置微信分享时用到的 JS-SDK，wx对象 就是我们最罕见的 JSBridge:

计划选型

任何手艺计划的选型，实在都应当基于运用场景和现有前提。基于公司现有状况的几点斟酌，在计划一上进一步优化，越发合适我们的需求。

• 需求 Web手艺 疾速迭代、天真开辟的特性和线上热更新的机制。
• 产物的中心才能是壮大的照相与底层图片处置惩罚才能，因而纯真的 H5手艺能做的事异常有限，不能满足需求，经由历程 Hybrid 手艺来强化H5，就是一种必须。
• 公司营业上，并没有异常庞杂的UI衬着需求，而且 App 中的一系列原生 UI组件 已异常成熟，因而我们并不强需相似 RN 如许的计划。

因而，怎样既能应用 H5 壮大的开辟和迭代才能，又能给予 H5 壮大的底层才能和用户体验，同时能复用现有的成熟 Native组件，便成为了我们最大的需求点 &＃8212; 一套完整又壮大的 Hybrid手艺架构计划。&＃x1f620;

Hybrid手艺道理

Hybrid App的实质，实际上是在原生的 App 中，运用 WebView 作为容器直接承载 Web页面。因而，最中心的点就是 Native端 与 H5端 之间的双向通信层，实在这里也能够理解为我们须要一套跨言语通信计划，来完成 Native(Java/Objective-c/&＃8230;) 与 Javascript 的通信。这个计划就是我们所说的 JSBridge，而完成的症结，就是作为容器的 WebView，一切的道理都是基于 WebView 的机制。

(一) Javascript 关照 Native

基于 WebView 的机制和开放的 API, 完成这个功用有三种罕见的计划：

• API注入，道理实在就是 Native 猎取 Javascript环境上下文，并直接在上面挂载对象或许要领，使 js 能够直接挪用，Android 与 IOS 离别具有对应的挂载体式格局。
• WebView 中的 prompt/console/alert 阻拦，一般运用 prompt，因为这个要领在前端中运用频次低，比较不会涌现争执；
• WebView URL Scheme 跳转阻拦；

第二三种机制的道理是相似的，都是经由历程对 WebView 信息冒泡通报的阻拦，从而到达通信的，接下来我们重要从 道理-定制协定-阻拦协定-参数通报-回调机制 5个方面细致论述下第三种计划 &＃8212; URL阻拦计划。

1. 完成道理

在 WebView 中发出的收集要求，客户端都能举行监听和捕获

2. 协定的定制

我们须要制订一套URL Scheme划定规矩，一般我们的要求会带有对应的协定开首，比方罕见的 https://xxx.com 或许 file://1.jpg，代表着差别的寄义。我们这里能够将协定范例的要求定制为:

xxcommand://xxxx?param1=1¶m2=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. 发送协定时，经由历程协定的唯一标识注册自定义事宜，并将回调绑定到对应的事宜上。
• 1. 客户端完成对应的功用后，挪用 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() {
@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。谢谢！&＃x1f60a;