Hi,先问问大家你们的 App 都是采用什么开发架构模式呢？Native 还是 Hybrid？

如果是 Native ，对研发团队的配置和能力要求自然不会太低，毕竟开发者需要根据不同平台撰写不同代码（Object-C、Java），同时，Native 过于标准化的流程，容易导致 App 发版周期长，无法跟上产品更新节奏，灵活性动态性比较欠缺，包体积还容易过大。

如果是 Hybrid ，想必多数是「Native + HTML5」模式，H5 既不占用存储，也可以轻易地移植到各终端，最重要的是支持热更新，能够快速满足高频的营销诉求。不过 H5 的体验也是大幅落后于Native ，比如 H5 页面的加载显示强依赖于Dom渲染，卡顿问题频发，而且很多系统权限 H5 也无法获取（例如蓝牙、陀螺仪、OCR、摄像头、TCP等等。）

那你们有没有想过通过深度结合「原生应用 + 小程序」，来实现 App 的动态化、提升 App 的性能，小程序拥有强大的 Web 渲染引擎、提供丰富的组件，而且可以获取系统多类权限。

虽然互联网大厂并未将这部分小程序技术能力开放出来，只能在他们的自有生态去运转，但是我们也不必望而生羡，因为小程序技术不再是 BAT 的专属，市面上已经推出了类似技术能力，我们一般称之为小程序容器技术，或许也有很多读者已经熟知。

借此机会，给大家分享目前在 Github 很热门的前端容器技术 —— FinClip，一个可以让任何APP都能具备小程序运行能力的前端容器技术，只需简单集成 FinClip SDK ,即可在 iPhone、Android、Windows、Linux、macOS、统信、麒麟等平台下的应用中运行你的小程序，这意味着，移动端、PC 端、车载设备、智能电视、智能手表都能运行小程序了。

FinClip 天然支持微信小程序语法 WXML，无需使用第三方跨端跨框架解决方案，即可编译运行已有微信小程序代码。自有 App 可快速、低成本引入微信生态中的小程序，降低运营成本。

FinClip 除了SDK 以外，还自研了一个小程序 IDE 开发工具，界面与微信小程序的开发工具类似，自带调试和真机预览，简单易上手。

你可以在这个 FIDE 里面，对现有项目进行二次开发，扩展功能和接口，同时它们还支持「小程序一键转换成App」，可以将已有小程序代码导出为 IOS 与 Android 中可用的工程文件。

由于导出的工程文件已经集成了 FinClip SDK ，所以直接拥有小程序的运行能力，后续可在这个 App 上直接上架更多小程序，自建自己的小程序生态。

那当我们拥有了这类小程序容器技术可以怎么结合运用呢，简答归纳几点：

（1）新业务功能以小程序的形式替代，可单独测试单独发布，不影响基础App的稳定性，也无需对App进行全回归测试。

（2）业务功能开发可以高度并行 – 只要有人手，人多好办事（想想微信让全互联网的开发者都可以同时互不影响为它提供海量应用场景），而在传统原生App的技术体系下，这是不可能的。

（3）容易蓝绿测试、灰度发布 – 粒度细到碎片级（例如一个小程序是可以仅在测试白名单的范围内试点）。

（4）形成技术生态 。一家企业如果掌握了微信这样的技术，它也可以成为一个技术生态中心，让外部开发者、合作伙伴们将自己开发好的小程序直接上架至自身 App，然后企业运营人员对这些小程序进行审核，这样在一个企业 App 内可覆盖多数服务场景。

在这个讲究快速敏捷迭代的时代，企业应该需要考虑对自己的 App 进行瘦身，把新旧功能剥离，以独立生命周期、独立开发测试团队的方式进行开发 – 有用的场景继续深入、无效的尝试即时废弃。

总体技术架构必须让基础 App 保持稳定、让频繁增删变更业务功能成为可能，同时最大程度降低开发门槛、减少试错成本、实现敏捷迭代。

移动开发的终局一定是走向更开放、更快速、更稳定。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。