从数字化角度理解凡泰小程序

这十年来，相信很多机构的App都经历过数次的“伤筋动骨”的大改造。开始的时候外购了一些技术，然后让开发商在上面订制、修修补补，但是发现无法响应市场变化、业务创新需求、监管规则变化，于是要么是购买源代码、组建自己的研发团队接手彻底自研，要么是另起炉灶采用新的技术框架重新开发。相信很多机构都经历过维持旧的App还是自建新App的困扰、以及同时运营和维护两个甚至更多历史遗留App的痛苦。

App功能随着时间的积累而越堆越多，开发团队人员也进进出出，App变得越来越“脆弱”，每次发版的时间更长、需要回归测试的功能点更多。随之而来的是“敏捷迭代”名存实亡。开发团队在开发新功能、填补安全漏洞、实现监管机构所需的一些合规要求、救火被客户投诉的应用功能之间疲于奔命。

创新变得越来越难，现有的技术能让金融类App变“轻”吗？
金融类App，其实天然有以下的特点：

都是“赋能型”的，不是向客户提供各种功能供其在App里针对不同的业务进行自助服务，就是向员工提供各种工具供其进行营销展业、办公、汇报、查看报表等等。无论是C端还是B端，本质上都是一个前端集成的“移动端门户”- 镶嵌着各种工具、服务入口。工具之间从业务角度、功能角度看，并没有太多的耦合关系，它们为了处理不同的事情、面向不同的场景、由不同的部门负责。大家不过是在移动端分别埋些“模块”、“入口”而已

迭代升级的诉求明显。对于C端来说，它需要的是一个灵活多变、有强烈的“可运营性”、便于创新的能力，并且因为金融市场本身的敏感性，任何时候在App端出现技术缺陷、信息安全问题、技术稳定性问题、资讯内容问题，金融机构必须有能力“实时”的进行处理，否则面临监管问责、客户投诉、经济损失。对于B端来说，它需要的是一个可以持续不断发布新赋能工具的能力，快速响应企业内部领导、业务部门、经营管理人员及一线员工的各种诉求 – 想到就做、做好就上、有反馈就优化。通常在公司内部推广一个新App并不容易，而废弃失败的可能性却很高。要让B端App有生命力，需要很多技巧，其中一个，必定是向全员展示不断推出新功能、快速响应使用者反馈的能力，呈现出“论持久战”的决心而不是给员工传递一个“玩票”性质的感觉

对是否采用所谓“原生”（Native）的技术来开发应用，并不重要。和手机游戏、办公套件（例如Microsoft Office）、即时通讯工具等等相比，金融类App的界面其实都是表单为主。其实用HTML5开发是合适的，至于RN、Flutter等技术，对于金融机构的开发人员，有新的学习成本，尤其是采用Flutter的学习曲线并不平滑（需要掌握一门新的语言，以及适应一个新的编程模型）

可以这么说，很多银行、证券、保险的App，都是碎片化功能的“集散地”，最理想的方案是，各个“碎片”单独研发、测试、灰度发布，有独立的生命周期，运行在App这个“宿主”上但是无法影响“宿主”的稳定性、安全性。

终归，大道至简
“碎片化”和“宿主”- 有没有这样的应用架构可以借鉴？当然有，而且是大家都熟悉的，就是微信。

微信App，本身较为纯粹，功能设计非常克制，遵循着较为简约主义的设计逻辑（当然，这要看跟谁比，在海外市场里，Whatsapp可能是一个更加纯粹、功能聚焦、目标单一的IM），但是在它上面运行着数以百万计的小程序。这些小程序就是场景化、功能化的“碎片”，使用者随需随用、用完即走。而微信本身，就是支撑这些“碎片”运行的“宿主”（宿主这个比喻，也许不是最恰当，但是它就是让小程序们寄生在其中，并且可以通过分享、转发进行传播）。

小程序的性能缺陷不能影响微信App本身、小程序的安全漏洞也理论上不能导致微信本身的信息安全问题，成千上万小程序由不同的机构拥有、开发者开发，它们的升级迭代也从来不影响微信App自身的稳定性。微信App本身在应用市场的发版更新，也同样不影响各种小程序的存在。微信App与运行在其中的小程序们，各自的生命周期独立、彼此耦合关系非常松散。

在微信App内部，可以理解为两个基础技术的结合，一个是即时通讯 –提供了交流、通讯、社交的功能；一个是小程序的运行引擎，提供了远程加载小程序代码并把它运行在安全沙箱里呈现给用户的能力。

金融类App，能否整理出一个稳定的“内核”，作为“宿主”去运行、分享、传播各种变化频繁、敏捷迭代的功能碎片？同时通过集成小程序运行引擎是实现各种功能碎片，我们也看到越来越多的“大厂”诸如腾讯、百度、支付宝等等。最近通过多年的深入研发，能实现完整私有化部署的凡泰小程序非常热门，通过这样的小程序方案提供商结合一个“宿主”，这样就形成了私有化的强大的超级金融App的能力。