小程序容器解决App频繁发版问题

如果你的 App 要实现一个功能，你最先考虑的承载方式是什么？

原生？H5？

之前我们要在 App 实现一个功能的时候，一般是优先考虑把功能放在 H5 里实现，如果不行的时候再考虑用客户端来实现。

之所以按这个优先级来做决策，是因为客户端和 H5 相比起来劣势太多了。随便举几个例子。

增大安装包体积。安装包体积增加有不少弊端，首先就是带宽成本高。每次发版都消耗你一大推的流量。还有就是拉新困难，在推广的时候，你让用户-十分钟，用户直接就点取消就走了。 升级版本困难。用 H5 开发一个新功能，一发布，全网就都生效了。而用客户端，你等去吧，没个几个月根本就覆盖不全。 多次开发。在一家公司里，往往 iOS 和 Android 都是不同的团队。一旦放在客户端，就意味着得实现两遍。虽然现在有了 Flutter，但是覆盖还是全。

但是有些功能又必须得放在客户端里实现，比如需要很强的缓存能力、需要访问通讯录、调用硬件、访问蓝牙啥的，再或者比如想要流畅的体验。这些功能 H5 都是无法支持的。

碰着这些情况，功能就必须得放在客户端组去搞。即使是有上述困难也得硬着头皮上。

再来说下我们团队之前遇到的现实问题。

由于众多的原因，一直以来我们的功能都搅在客户端里实现，经常被领导说发版太慢（关键我们页根本快不了啊），每次发版还得把多个团队的功能合并进来，你也不知道哪个组的代码有问题，所以测试得非常严谨才行。

不光是测试，还得经过过各种小流量的灰度。根本不敢快，否则一旦有问题的包放出去，收都收不回来。

后面组里的一位大神提到：这种问题在服务器端也曾经存在，这个问题的根源就是软件行业工程里面的“高耦合”。过多的功能都耦合在一个 App 里出现各种各样的问题是必然的。在过去服务器端也是所有功能都用单体的方式来实现，也是大量的功能都耦合在一起。一旦某个代码有问题，可能全网就都崩溃了。但现在已经很好地解决了。

整个团队瞬间就被点醒。

早在十多年前，腾讯内部就秉承大服务小做的方式来对服务进行拆分。在今天，更是有了微服务以及各种配套的基础设施来 对服务器端进行解耦。所以现在服务器端无论是发版速度，还是稳定程度都比十年前要好了很多。

在客户端上，这个问题确实不好解决。但是忽然转念一想，哎，迭代频率特别高的功能是不是用小程序就能实现呀？像微信支付宝那样，把各种外围的功能都以小程序的方式来提供。

一部分是稳定的、最常用的、也是久经考验的功能，其他功能可以是敏捷变化的小程序。小程序可以由不同的团队独立开发，自由发布，不会影响核心功能

这样，就既能享受客户端的高权限，就又能拥有快速的发版速度。但仔细一想，这个思路挺不错，但是想实现一个小程序平台，估计投入不少，性价比太低了。

后面经过技术调研，其实业界早就有公司做了小程序容器，也就是通过集成 SDK 的方式让 App 拥有小程序运行能力。

这里必须有 FinClip 的名字，经过 POC 对比了其他平台，发现产品还是有很明显的优势，性能、操作性、便捷性都要好很多，看得出来是花了心思。

FinClip 的方案部署了以后，确实新功能的发版的速度有了明显提升。

一来大量外围的功能都可以小程序化了，不再需要等待主版发版。

第二就是天然支持 iOS、Android、Windows、Mac多个平台，一次开发，四处部署。

而且还有个优点，天然兼容微信小程序，这样公司客户的微信小程序也都能迁移过来，帮助加强 App 的能力。