APP 热更新技术最优解，不只是支持热更新...

热更新是一种 App 软件开发者常用的更新方式。简单来说，就是在用户下载安装 App 之后，打开 App 时遇到的即时更新。

在 2017 年苹果 App Store 针对热更新的下架事件以后，开发者们也在不断的探索及尝试最优技术解决方案。其中「App+小程序容器技术」的热更新解决方案脱颖而出，成为了近年来 App 热更新领域，最热门的技术解决方案，没有之一：一码多端运行（跨平台），体验优于 H5（松散耦合），避免 DOM 泄露（安全容器）等，都是该方案的核心优势。

背景是什么

早在 2017 年，App Store 审核团队便针对 App Store 中“热更新”的 App 开发者发送邮件，要求移除所有相关的代码、框架或 SDK，并重新提交审核，否则就会在 AppStore 中下架该软件。由于软件热更新绕过了苹果的审核，黑客开发者有可能会通过提交正常的版本之后，通过热更新的方式修改 APP 导致安全隐患，利用这个“后门”来窃取用户设备中的隐私信息。

与此同时，各行各业的业绩却需要应对千变万化的市场需求背景下加速增长。移动互联网背景下，APP 这个主流触达用户的工具，变成为了商家流量竞争的主战场。技术作为业务的市场触达及活跃的保障手段，对于业务应用，尤其是高频引流及活跃的应用需要保持快速迭代更新。基于这个背景，可以说开发者们从未放弃探索及寻找热更新的最优技术解决方案。

App 热更新技术方案

市面上 App 热更新技术方案可归纳为两大类：纯原生（Native）的，以及 Hybird（混合开发）模式下的技术方案。

纯原生（Native）的热更新技术解决方案典型的有 Dexposed、AndFix、KKFix.....很多且应用也不错，但随着市场上“敏捷开发”，“一端开发，多端上架”等研发概念探索成型并有一些成功实践被广而告之以后，Hybird（混合开发）的移动研发模式便开始流行起来。

因此，我们在本文中重点探讨一下混合式 App 开发模式下的热更新方案。

混合 App 开发模式之「Native+小程序」

介绍混合 App 的热更新方案前，还得先介绍一下混合 App 开发模式都有哪些。

在微信把小程序带火之前，H5 在微信中“漫山遍野”。这些在类似微信的社交中心化平台上生存的业务应用，主要目的是给企业主的业务做引流和活跃。既然已经开发了一套应用在微信上，为什么不能应用于 App 的研发管理上呢？这样是不是更服务敏捷开发的理念？

于是，混合 App 开发模式--「Native+H5」诞生了。

如今，微信全网小程序数量超过 700 万，微信小程序日活超过 4.5 亿，真正进入了业务应用小程序流行的年代，于是开始有人研究「Native+小程序」的 App 开发模式。

相比于「Native+H5」，「Native+小程序」的 App 开发模式优势在哪里呢？关键在于小程序相比于 H5，有其自身的优势：

1、开发成本更低：小程序技术是前端容器技术的一种应用，其组件及 UI 都有明确的规范，开发者不用考虑兼容性及类似 H5 开发时复杂工具及框架的选择。

2、加载速度更快：小程序是基于 App 端实现的应用，自身对于 App 有一定的亲和度，使用时不像 H5 的网页加载方式，用户主观感觉会更流畅。 

3、与宿主环境结合更紧密： 如上所述，小程序是基于 App 端实现的应用，故只能在特定的平台内运行，可想而知其获取系统(App)的权限也会多于 H5（H5 是网页,只要有浏览器就可以使用）。

4、用户体验更佳： H5 网页是在浏览器内使用，如果网速不佳或者网页加载东西过多就会出现卡顿。 小程序只需在首次使用时是加载，也不会太精准，初次加载后页面再加载就会很流畅了。另外，组件及 UI 都是有预设组件，展示体验也会更佳。

基于上述信息，小程序应用能火起来，或者说各大平台竞相“弃 H5 从小程序”也不是没有其道理所在。

上述说的只是说了小程序自身比 H5 具备更优的技术解决方案，那么放到混合 App 开发模式下比较，「Native+小程序」的 App 混合开发模式的优势可以总结为：

• 远超过 H5 的体验（支持本地缓存，Webview，有丰富的组件与支持库）；

• 能获取更多系统权限，完成更加丰富的产品设计；

• 可以避免 DOM 泄露（不使用常用的 window 对象与 document 对象）；

• 包尺寸有效减少，节省流量和存储

「Native+小程序」的 App 混合开发模式有许多优势

「Native+小程序」的 App 热更新技术方案

「Native+H5」的 App，其热更新的机制大致是：把需要频繁发版的业务应用 H5 化，并内嵌至 App 中。当含有页面链接的 App 版本过审以后，这些 H5 页面可以随时远程热更新，用户在不更新 App 版本的基础上，就能使用最新版的业务应用。

那么「Native+小程序」的 App，其热更新方案好在哪里呢？其好处并不在于热更新本身，而是在于「Native+小程序」给企业技术和业务的价值更优，所发挥的作用更大。

首先，说说技术层面

小程序技术作为前端容器技术的技术实践之一，天生与云原生的理念亲和，且具备容器技术的优势：容器安全。

小程序技术的核心功能是视图层与逻辑层分离，这种分离有很多好处：

1、方便多个小程序页面之间的数据共享和交互。在小程序的生命周期中具有相同的上下文可以为具备原生应用程序开发背景的开发人员提供熟悉的编码体验；

2、Service 和 View 的分离和并行实现可以防止 JS 执行影响或减慢页面渲染，这有助于提高渲染性能；

3、因为 JS 在 Service 层执行，所以 JS 里面操作的 DOM 将不会对 View 层产生影响，所以小程序是不能操作 DOM 结构的，这也就使得小程序的性能比传统的 H5 更好。

小程序技术的核心功能：视图层与逻辑层分离

其次，说说业务层面

“容器化”就是将容器中的每个部分（应用、流程等等）都打包在自己的容器中，这有助于提升复用性、透明度以及改善资源隔离。

小程序作为容器技术之一，具备将业务应用打散再重整的能力，即应用松散耦合。产品经理、业务大大们，试想一下，原先的几十个业务模块，可以单独拆分出来，互不影响的运行，不同类型的业务模块，还可以嵌入到你所需要的兄弟 App 中进行引流或业务承接。

​

最后小结一下，市面上热更新技术解决方案有很多，如何能够兼顾技术实现且最大限度的支撑高性能技术架构及业务发展，也是需要我们综合考虑的。

技术产品实践案例

FinClip小程序开放平台，为企业提供“小程序运行能力”，它作为小程序运行的环境，为小程序提供安全沙箱、代码解析和渲染等服务。 为了让更多 APP 轻松拥有“小程序运行能力”。凡泰极客将“小程序运行时”实现成一个可私有化部署的 iOS 和 Android 版本的 SDK，可以被第三方集成。也就是说，任何 APP 通过嵌入 FinClip 小程序 SDK 即可瞬间获得运行小程序的能力。

仅需 5 行代码，即可让你的 APP 快速启动和运行小程序，而且小程序运行时 SDK，Android 端 1.3 兆，iOS 端 1.8 兆，轻量无感，同时 SDK 采用多线程运行方式，极端情况下也不影响宿主 APP 的安全稳定运行，现在注册，即可免费上架 99 个小程序。

​

行业实践案例

券商：合规安全下的内联外引，助力财富管理数字化转型

背景：

券商 App 中通常集成的业务功能繁多，传统技术实现方式是紧耦合，相对独立的业务功能也无法独立开发测试、独立发布；此外，券商 App 本身可运营能力弱，明明用户就在 App 上活跃着，也无法在线向其进行产品营销，无法通过活动进行触达

解决方案:

1、在 App 中集成 FinClip 小程序运行时 SDK，从而获得小程序运行能力，逐步把传统紧耦合的功能小程序化，独立可上下架管理，和 App 载体松绑。

2、利用 FinClip 兼容微信小程序的特性，App 各类功能进行小程序改造后部分也在合规前提下能够被分享至微信，并引导客户回流至 App，提升 App 的活跃度。

3、小程序轻量、便捷，并能灵活的“上下架”发布，满足高频的营销活动需求，并能够针对不同客群推荐不同的营销活动，实现千人千面营销，促进业务办理。

银行：加速生态融合，打造开放银行

背景：

数字化时代的信用卡，既需要满足传统线下消费场景，更需要关注日益上涨的线上消费需求。过去是用户带信用卡到线下消费，现在是银行将商户引进到 App 中，通过营销活动引导用户使用信用卡。银行数字信用卡如何低成本吸引商家进驻、如何在线运营促进用户消费?

解决方案:

1、银行 App 通过集成 FinClip 小程序运行时 SDK，可引入外部优质的商家服务小程序，结合自身的金融服务能力，打造特色化金融服务，且丰富 App 使用场景，从而达到提升 App 用户活跃的效果。同时，可利用 FinClip 兼容微信小程序语法的特性，银行可快速、低成本引入微信生态中的小程序商家，降低运营成本。

2、银行 App 可根据已有用户画像对用户进行精细化管理，灵活呈现不同小程序给用户使用，轻易实现对用户的个性化服务;

3、"用完即扔”的营销活动类代码可以快速发布，满足高频运营活动要求。

​