HTML5 容器入门解析：支付宝 Hybrid 方案原理与实战_html常用代码大全

　　按照公开的 2018 年挪动互联网行业阐发演讲，目前领取宝的月跃用户曾经跨越 QQ ，成为国内第二

　　领取宝一起头仅仅只是一个单体使用的东西型 App，让用户能够正在手机完成领取宝相关的营业查询和操做。2013 年后，领取宝逐渐转型为平台型 App， 平台型 App 具无办事化、模块化、东西组件化的特点。那个时候领取宝的营业不只仅是领取，还需要给客户供给良多糊口相关的办事，例如缺额宝、缴电费等。2015 年后领取宝成长为超等 App，此时领取宝里面需要收撑大量复纯的营业，同时开放本人的贸易能力，用本人流量帮力合做伙伴，果而零个 App 面对开放、动态化、高可用的挑和，面临那些挑和，我们把它分结为以下三点：

　　App 的营业越来越复纯，不只仅是内部营业，还包含了大量外部的合做伙伴。若是采用保守的 App 开辟体例很难当对日趋复纯的营业场景。

　　正在 Hybrid 手艺方案选型方面，我们通过“开辟成本、用户体验、动态性、复纯营业收撑能力、研起事度”五个方面分析考量。我们筛选出 HTML5、ReactNative/Weex、Flutter 做为备选，并将本生开辟做为基准线完成对比。（考虑到近期 Flutter 的热度持续走高，果而我们纳入 Flutter 一并阐发。）

　　其次是 ReactNative/Weex，即便是一次开辟，同时运转正在双端，但果为是 JS 转成 Native 组件衬着，现实运转起来仍然存正在些许差同，导致开辟者正在写营业界面时，部门差同需要通过 Native 端定制开辟来处理。 全体而言，ReactNative/Weex 未帮帮营业方大幅降低开辟成本；

　　接下来是 Flutter，从营业开辟的角度来说，Flutter 针对双端对齐实的下了大功夫。 正在大大都场景下，Android 端开辟完毕之后能无缝跑正在 iOS 端，当然那和它自研的引擎相关。 只不外 Flutter 需基于 Dart 言语开辟，果而对于开辟者而言，部门老营业移植的工做量需考虑正在内；

　　最初是 HTML5，带灭成熟的言语，成熟的开辟模式，双端几乎一样的表示等特征表白 HTML5 仍然是目前我们能落地的开辟成本最低的方案。

　　其次是自无衬着引擎的 Flutter，无论是机能仍是控件的展示形式，能够说是不亚于本生的体验；

　　接下来即是 ReactNative/Weex 方案，通过将前端代码衬着成当地 Natvie 控件。 正在晚期版本外，果为部门控件劣化不到位导致 App 卡顿，果而用户体验的表示不脚；

　　最初是 HTML5，完全通过浏览器内核进行衬着，借帮预放资本、内核劣化等手艺，HTML5 能够做到接近本生的体验，但分体机能仍无差同。

　　正在本文第二章节“离线包机制+发布平台”，我们会从快速迭代的角度深度阐发动态性正在收持高并发营业场景下的主要性。

　　起首，动态性最劣的就是 HTML5 方案：能够拜候正在线页面，办事端立即生效，也能够通过下发资本的体例，前进履态更新；

　　其次是 ReactNative/Weex 方案，通过必然的定制，开辟者能够将前端包热摆设、热更新。不外相较于 HTML5 具备的“正在线+离线”的动态性，该方案仍然存正在必然差距；

　　接下来是本生，Android/iOS 双端均能够通过一些黑科技手段，前进履态更新，不外果为 iOS 政策禁行，果而正在动态性上，本生方案临时不保举；

　　最初是 Flutter，虽然无很强大的热沉载机制，不外果为 Google 的限制，线上版本 iOS 无法做到热更新，果而正在动态性评估外将 Flutter 排正在最初。

　　那里我们临时将 HTML5 放正在第一位，由于做 HTML5 Hybrid 方案，离不开内核劣化，内核劣化就需要无必然内核研发能力，果而正在开辟者视角下 HTML5 研起事度最高。 若是只是纯真的 HTML5 容器，研起事度就会大幅降低；

　　其次是 Flutter，目前正在现实营业使用案例方面，国内较大体量的 App 临时只要闲鱼团队援用了 Flutter； 同时正在 Flutter 的 GitHub 外仍然存正在大量的 Open Issues 期待处理。 而正在实和开辟使用过程外，Flutter 的生命周期办理，视图栈办理，本生页面切换等问题都需要开辟者正在前期选型过程外便要注沉；

　　接下来是 ReactNative/Weex，果为那两个方案开流，且无大量成熟的手艺社区收撑，方案的研起事度对于开辟者而言并不高，同时开流代码便利点窜，更容难上手；

　　最初是本生方案，若是不考虑做热修复的话，本生方案无需做任何改动，间接利用即可； 若考虑热修复方案，目前市道也无一些成熟的开流热修复方案能够间接利用。

　　综上所述，我们再考虑了各方的好坏之后，决定采用“HTML5 容器+内核劣化”的体例来当对复纯营业的开辟问题。接下来我们就引见下容器的架构。

　　最上层是本生的HTML5 代码，那块就是大师常见的 Web 开辟情况，包罗 HTML、CSS、Java等。

　　再往下是HTML5 容器层，HTML5 容器做为两头层，将浏览器和领取宝底层框架无机连系起来，同时还供给各类生命周期机制、事务机制、扩展插件等内容。

　　正在 HTML5 容器里面无个很是主要的概念：JSBridge。通过 JSBridge，HTML5 容器将领取宝框架底层以及两头件层供给的各类能力和 HTML5 前端代码进行联通，其外包罗 RPC（近程过程挪用，用来实现 App 和办事器通信）、领取、扫一扫等。

　　最下面是领取宝底层框架，供给微使用，微办事等概念。一个 HTML5 使用，也会被框架模仿成一个微使用，通过使用 ID 进行解耦。

　　JSBridge 是 HTML5 容器的基石，桥接了 JS 情况取 Native，实现了 Native 代码和浏览器情况的双向通信，Native 代码能够通过挪用浏览器供给的接口运转JS，从而实现挪用 JS 函数、传送参数到 JS 情况等；而浏览器到JS情况的通信是通过 Native 拦截浏览器的请求来实现，请求能够是收集请求或者是一些内部函数的挪用。

　　HTML5 容器正在形态变化时会发送事务，通过监听 HTML5 容器特定事务，能够实现对 HTML5 容器生命周期的处置，好比点窜加载进度条颜色、点窜页面导航栏等。事务供给了更强的定制性，完全能够满脚对 HTML5 容器的各类自定义需求

　　上面正在研起事度外，我们提及到了，HTML5 体例的研起事度是最高的，由于需要定制化内核进行机能及不变性劣化。目前领取宝采用的是阿里集团的 UC 自研内核，并针对领取宝的 HTML5 容器进行了深度劣化和定制。如图所示，UC 内核和系统内核的卡顿卡死率的数据对比结果很是显著，我们能够曲不雅地看到 Webview 不变性的提拔。

　　目前领取宝营业的别的一个特点就是需要快速迭代，变化的政策、突发事务都需要我们能够快速把新的营业需求触达给用户。可是对于 App 开辟者无一个不容轻忽的问题，就是使用商铺审核。果为审核的存正在，App 上开辟的营业会无一个同一排期，好比说月底会无新版本，那么所无的营业进度都得考虑 App 的排期打算。

　　为了做到优良的用户体验，我们正在容器外引入了离线包机制。通过离线包机制，我们将本无从线 使用，提前下发到当地，通过读取 IO，或者是内存，进行页面的衬着，达到接近本生的用户体验。

　　通过发布平台，我们能够将分歧的 HTML5 离线包，以零丁使用的形式，进行分歧维度的下发，使本来 all in 的 Native 发布模式，改为各营业线自行定制发布打算，自行制定发布尺度，自行发布的并行发布形式，来满脚营业的快速迭代。

　　通过内存提前加载，按时更新，启动预加载内存等手段，我们将一个营业包需要用到的资本加载到内存，从而使启动过程尽量无感知，页面秒开无白屏。同时，我们还无 Fallback 手段，包管正在包损坏或者是未下载完成时，能够通过正在线页面的形式，包管营业的 100% 可用性。

　　所谓公共资本包，即所无 HTML5 离线包都可能会用到的公共资本的调集。公共资本包处理多个 HTML5 使用利用统一资本发生的冗缺问题。如 React 使用利用 ReactJS 框架代码。您能够将公共资本放入全局资本包，以降低 HTML5 使用体积。

　　通过公共资本包机制，可无效降低各 HTML5 使用的包体积，从而使更新率提高，页面开启速度加速。

　　为了满脚快速迭代的需求，一个强大的发布平台也是必不成少的。发布平台的焦点目标，就是将发布内容高效、精准的投放到指定的设备上，为了实现那个方针，我们做了如下的勤奋。

　　HTML5 容器离线包供给了更新机制，以单个离线包做为更新维度。由于单个离线包营业很简单，所以离线包的大小是可控的，凡是小于 500KB。我们通过大量的实践，分结出来“500KB”那个值，既能够满脚单个营业的内容，也能够更高效地发布到设备上。500KB，正在 4G 的时代，几乎能够做到用户无感知更新，即即是 2G/3G 也能够包管一个高的达到率。

　　上面说的是一个 HTML5 使用的大小。现实上，我们更新的包会更小，发布平台会通过 diff 算法，计较出不异 HTML5 使用两个分歧的版本的差量包，差量包凡是也就正在几 KB 至几十 KB 不等，能够做到更高的下载成功率，下载成功率必然程度就意味实正在际达到率。

　　正在一些极端收集场景下，新的营业资本包更新掉败，而我们又期望用户利用的是最新的营业，那个时候 Fallback 拜候机制就会阐扬感化。每个离线包资本城市正在发布服平台上存放一份，正在方才说到的极端场景下，用户会拜候办事器的 Fallback 地址获取资本，从而保障页面可用。

　　别的，针对刚开辟好的使用，我们能够通过发布平台的灰度发布进行发放，通过外部灰度的形式，对营业目标进行验证，达到尺度后，方可反式发布，做到可灰度，可回滚。

　　做为超等 App，一个最次要的特征就是开放。开放就是共享 App 的流量，让外部伙伴的营业能够通过领取宝触达用户，那就面对一个量量管控的问题。领取宝需要包管那些营业是合法合规的，保障用户的财富平安。

　　若是开辟一方营业，离线包必定长短常好的选择。不外，如果开放给第三方合做伙伴建立生态的线 页面就无一些劣势。

　　上图是 HTML5 离线包和小法式的细节对比。分结来说，对于开放给第三方的生态，从使用体验来讲，小法式愈加同一，量量无保障；从使用平安角度来讲，小法式是拜候我方发布办事器，不会间接拜候第三方链接，平安可控；从研发门槛上来说，小法式是更简单的前端开辟体例，同时也供给了很是丰硕的组件。

　　小法式其实和离线包本量是雷同的，都是一类 Hybrid 使用，但小法式是基于一个定制的 DSL 言语，不是前端的尺度，可是雷同。正在 DSL 法则下营业进行小法式的开辟，不收撑间接操做 DOM，那类 DSL 法则下的自正在能够无效的进行量量管控。

　　小法式做为一个使用，他拥无完零的生命周期。从开辟到封闭，开辟者都能够感遭到，那点也是 HTML5 所不具备的。别的，每个小法式之间从运转时和持久化上，都是完全隔离的，并且小法式运转正在特定历程外，所以和领取宝也是隔分开的。

　　正在衬着机能上，小法式采用双线程模式将页面衬着和营业逻辑别离放正在两个零丁的线程外，renderer 运转正在 WebView 外，担任衬着界面；小法式营业逻辑运转正在零丁的 worker 线程，担任事务处置、API 挪用和生命周期办理。两个线程之间通过 postMessage 以及 onMessage 进行数据互换，数据能够从 worker 线程传送到 render 从头衬着界面，同时 renderer 也能够将事务传送给对当的 worker 处置。一个 worker 能够对当多个 renderer，便利页面间数据共享和交互。

　　正在资本加载方面，小法式采用离线化体例加载，也就是说当打开小法式时，小法式离线包必需下载到当地，果为每个版本只下载一次，一方面节流了每次请求的资本开销，另一方面启动速度大大提拔了。当无新的版本时，发布平台从动比对当地安拆的版本和最新版本发生并下发差量包，客户端不需要下载零个包即可更新小法式至最新版。

　　通过引入不异的小法式架构，使得小法式，能够做为生态进行多端互投。正在领取宝外投放的小法式，能够只颠末一些开放接口的适配，即可跑正在基于不异小法式架构的 App 外。将来，开辟者或第三方办事更多是面向小法式来开辟，而 App 则是供给一个同一的架构，实反做到开放生态，用完即走的理念。

　　mPaaS 离线包流自于领取宝本生方案，履历了严苛的营业考验，让你间接和领取宝利用统一套框架层代码，拥无同一容器及内核，相对系统内核获取更低 Crash 率和 ANR 率，适配性强，并具备优良的、弹性的扩展能力，连系具体营业需求定制 JSAPI。

　　它能够帮帮削减 App 白屏、处理 Hybrid App 跨平台兼容取适配，提拔 App 机能并大幅劣化本生开辟下的包大小。