如果你的 App 要实现一个功能，你最先考虑的承载方式是什么？
原生？H5？
之前我们要在 App 实现一个功能的时候，一般是优先考虑把功能放在 H5 里实现，如果不行的时候再考虑用客户端来实现。
之所以按这个优先级来做决策，是因为客户端和 H5 相比起来劣势太多了。
随便举几个例子。
-
增大安装包体积。 安装包体积增加有不少弊端，首先就是带宽成本高。每次发版都消耗你一大推的流量。还有就是拉新困难，在推广的时候，你让用户下载十分钟，用户直接就点取消就走了。
-
升级版本困难。 用 H5 开发一个新功能，一发布，全网就都生效了。而用客户端，你等去吧，没个几个月根本就覆盖不全。
-
多次开发。 在一家公司里，往往 iOS 和 Android 都是不同的团队。一旦放在客户端，就意味着得实现两遍。虽然现在有了 Flutter，但是覆盖还是全。
碰着这些情况，功能就必须得放在客户端组去搞。即使是有上述困难也得硬着头皮上。
再来说下我们团队之前遇到的现实问题。
由于众多的原因，一直以来我们的功能都搅在客户端里实现，经常被领导说发版太慢（关键我们也根本快不了啊），每次发版还得把多个团队的功能合并进来，你也不知道哪个组的代码有问题，所以测试得非常严谨才行。
不光是测试，还得经过过各种小流量的灰度。根本不敢快，否则一旦有问题的包放出去，收都收不回来。
后面组里的一位大神提到：这种问题在服务器端也曾经存在，这个问题的根源就是软件行业工程里面的“高耦合”。过多的功能都耦合在一个 App 里出现各种各样的问题是必然的。在过去服务器端也是所有功能都用单体的方式来实现，也是大量的功能都耦合在一起。一旦某个代码有问题，可能全网就都崩溃了。但现在已经很好地解决了。
早在十多年前，腾讯内部就秉承大服务小做的方式来对服务进行拆分。在今天，更是有了微服务以及各种配套的基础设施来 对服务器端进行解耦。所以现在服务器端无论是发版速度，还是稳定程度都比十年前要好了很多。
整个团队瞬间就被点醒。
在客户端上，这个问题确实不好解决。但是忽然转念一想，哎， 迭代频率特别高的功能是不是用小程序就能实现呀？像微信支付宝那样，把各种外围的功能都以小程序的方式来提供。
一部分是稳定的、最常用的、也是久经考验的功能，其他功能可以是敏捷变化的小程序。小程序可以由不同的团队独立开发，自由发布，不会影响核心功能
这样，就既能享受客户端的高权限，就又能拥有快速的发版速度。但仔细一想，这个思路挺不错，但是想实现一个小程序平台，估计投入不少，性价比太低了。
后面经过技术调研，其实业界早就有例如 FinClip 这样的产品做了小程序容器，也就是通过集成 SDK 的方式让 App 拥有小程序运行能力。
方案部署了以后，确实新功能的发版的速度有了明显提升。
一来大量外围的功能都可以小程序化了，不再需要等待主版发版。
第二就是天然支持 iOS、Android、Windows、Mac多个平台，一次开发，四处部署。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/70013942/viewspace-2855867/ ，如需转载，请注明出处，否则将追究法律责任。
