超级应用和混合应用的热更新技术解析原创

我们都知道，传统原生APP，它的开发成本、发布周期长，对于需要频繁迭代业务内容的企业来说，无论是更新功能模还是修复有缺陷的版本，都需要重新测试、重新发版，重新提交第三方应用商店审核上架，还要用户配合安装新的版本，才能把旧版本覆盖。采用HTML5加原生代码的应用开发技术应运而生。业务内容，尤其是经常变更、有业务运营属性的内容，最好以HTML页面的方式实现融合在原生APP中。通常的做法是在原生APP里预先基于界面设计挖好一些洞，然后利用web view在这些洞里面渲染由标签语言描述的内容，无缝呈现在APP里。这些内容从哪里来呢？他们通常预埋在APP代码包，并且通过互联网从服务器端获得更新。这就是大部分的APP开发者所最关注的所谓热更新。它的工作原理是这样的，通常APP的服务器端要监测这些内容的更新，然后向设备端的APP以某种技术手段发送内容更新的通知。然后APP里的一些组件需要向客户端通过网络同步一些页面内容，并且把这些下载的内容通常是HTML和javascript注入到之前挖好的这些洞洞里。

网络同步的技术方案有很多，例如通过双向的web，或者通过http poing，或者通过SSE，或者通过po，或者其他自定义的技术手段，例如CMS去实现。设备端通常通过HR热模替换和代码注入等方式让更新的代码在本地生效展示，避免APP重启。有些APP因为有了热更新HTML碎片的能力，他们就把这些碎片称之为小程序，或者认为与小程序技术等价。实际上是这样吗？这里恐怕有很大的误解，小程序技术并不仅是为了解决热更新问题，或者HTML碎片加载时的白屏等性能问题的。

事实上，这两个小问题对于小程序技术来说都是细枝末节，是隐含被解决的点，但绝对不是小程序技术的目标，我们接下来看看什么才是真正的小程序技术。假设你打造了自己的APP热更新机制，我们就围绕热更新来展开讨论吧。首先，你的HTML代码是由谁负责开发和发布的呢？如果这些内容仅仅供APP的开发团队自行负责，那么你实际上并不具备一个开放的平台。你可能无法允许多个与APP开发团队无关的业务小组内外部团队互不干扰的进行并行开发。此外，你的APP发版之后，有没有可能发布此前完全没有预见到规划过的业务内容？如果对这两个问题的回答是否定的，那么你的APP并不具备真正的小程序能力。类比云计算里面的容器镜像，我们也可以把所谓热更新的HTML代码碎片内容称之为镜像。那么你的团队所开发的这些镜像，他们是否遵循一定的开放标准呢？

例如p waw、3c mini APP等格式标准，或者腾讯微信小程序规范小程序是规范的技术载体，我们可以把它是作为业务内容代码镜像的容器。此外，这些所谓热更新的资源发布在服务器上，你有没有提供检索和发现他们，并从而定位他们的网络地址的标准机制呢？最后，这些下载更新到设备端APP里的镜像或者说资源包，他们是如何被安全的解包和解释执行的呢？这几个问题，相信任何自研的APP都可以土法炼钢自行解决，但是这不能让你的方案自动变成小程序技术，而且你的自研APP的目的是解决业务问题，而不是自己去实现与维护这么一套比较复杂、比较难做好的底层框架，重新发明车轮。用HTML5开发的业务内容应该有独立于原生APP的生命周期，在生产阶段，这些代码应该与APP本身的开发、测试、发布无关，甚至和APP的技术开发团队无关。

在上架被更新到设备端APP里的时候，这些代码也有其加载就显示、隐藏、卸载等不同阶段的处理。但无论如何，这些代码自身的上下架的业务决定和宿主APP的发版是毫无关系的。如果没有做到生命周期独立，那么你的APP也并不是真正具备小程序的运行能力。理论上说，任何从网上下载更新的源代码都是不能假设安全可信的。当这些代码被注入到你的APP里运行的时候，如何检测其安全性和保护设备端本地应用、本地数据的安全呢？小程序类技术的解决方案是在云端检测审核，在设备端则以安全沙箱的技术机制，把下载更新的代码关在笼子里隔离运行。如果你的技术体系不具备这样的能力，那么你的APP也并不具备真正意义上的小程序技术能力。如果一个APP里包含丰富的业务内容，来自于不同的业务部门甚至外部合作伙伴的HTML代码包之间彼此是否可见？能否互相调用一段由A部门发布的代码，是否影响B部门相关代码的稳定性？

小程序技术通常对这些代码之间做了严格的隔离，他们彼此不可见，不知道彼此的存在，一个小程序的稳定性绝对无法影响其他小程序。这是为什么一些互联网公共平台能支撑数百万个小程序，形成无上限的规模效应的根本原因。企业虽然可能不会有数百万个小程序运行在APP里，但是类似的隔离能力依然是非常重要、非常需要的。有了标准与规范的HTML代码资源，还需要统一的上下架管理机制，需要搜索、发现和定位这些资源包的统一服务。而且这种管理能力往往并不是由企业it开发人员掌握的，他可能更应该有企业的运营人员去负责。在这里我们可以看到，小程序技术不仅面向开发人员，他重点解决以小程序为技术载体的数字化内容的上架、审核、出版、分发、传播问题。

这就不仅仅是从所谓热更新这样一个技术点出发能比较的。发布更新的HTML内容能否在必要时被下架，从而让运营人员实现实时风控，把一些内容及时从用户的设备撤回取消。真正的小程序有这样的技术能力，因为它通常在设备端APP里有安全沙箱的配合。安全沙箱听命于服务器的指令。在网上发布的HTML内容。它的镜像虽然能被及时更新同步到设备端APP，但是它在被运行的时候可能会涉及到访问用户在设备端、在APP里的数据和资源。尤其是在建立开放生态的时候，这些代码可能都不是APP的开发团队开发提供的，而是来源于第三方。刚才我们看到这些从网络下载的代码内容要关在安全沙箱里才能运行，但这样还不够，我们还需要知会当前APP用户对这些代码的执行进行授权。你的热更新框架又考虑到这个因素了吗？

如果你的技术体系并没有实现或者完全解决前面这八点，那么你可能应该考虑采用更完善、更专业的技术来打造更优方案，而不是基于一些开源的所谓热更新技术框架去重新发明车轮。小程序容器技术现在已经进入企业，凡泰极科的clip产品就是这样的技术，它帮你将现有的APP改造成下一代的数字化超级APP。越来越多的传统APP会被小程序化，演变为以高度可运营的super edge形态出现。大家不妨以这里列出的思维框架去重新思考自己的APP的技术实现能否满足数字化时代的需要。我相信超级ABB加小程序的生态化、平台化技术架构，对很多行业的数字化转型来说是一个更优解。