决战下半场：小程序技术助力金融 APP 重回 C 位

本文不是一篇纯技术文章，想与IT、电商、互金、网金以及负责数字化运营的部门同侪们一起探讨一下App的数字化建设。

你们家的App是不是越来越“重”？

银行、证券业机构在智能手机上发展App，到今年应该说有十年时间了。

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

即便是好不容易稳定在一个比较干净利索的架构上，随着功能的不断堆叠、不同阶段的开发人员的不断接手改造，很有可能越来越复杂、越来越笨重，例如个别工程师的技术水平导致了App里的模块划分不清晰、功能高度耦合，最后导致改什么东西都可能“牵一发而动全身”；更糟糕的是，有些部分的代码在负责人员离开后，可能谁都不愿意或者不敢碰，逐渐变成App里的一个黑箱所在。

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

现有的技术能让App变“轻”吗？

先稍稍回顾一下App技术历史的轨迹。

古时候，开发App大家要养两个团队 – 一支负责iPhone版本、一支负责Android版本。这两拨人具备的知识结构、采用的编程语言、掌握的技术概念都是不兼容的。产品经理想实现同一个业务功能，必须跟这两拨人都说一次。并且，两个阵营的版本功能经常性不同步。这种类型的App叫做Native App（原生应用）

后来，开始有人琢磨，我能不能让业务逻辑代码只开发一次而无缝跑在iPhone和Android两个世界呢？于是开始发明出用HTML5开发应用页面，通过“反向代理、远程加载、本地渲染”的办法进行运行，并通过一种叫JS Bridge的“桥接”技术对接到手机上的原生代码，这种类型的App叫做Hybrid App（混合型应用）。开始的时候这类应用性能不大好，但经过多年的优化（尤其是在Android上对浏览器内核的优化）以及手机硬件的升级，性能也总体得到提高。到今天为止，大部分的金融类应用估计属于这个类型。但是采用这种方案，我们还是得养着iOS和Android“两套班子”，分别负责各自平台上的一些原生部分的工作。

再后来，Facebook也开始琢磨这事情。“要让开发人员用类似JavaScript的语法，写出接近原生的性能效果”、“要让企业只养一套班子” - 于是Facebook发明了一种技术叫React Native，简称RN。市场上有越来越多的企业采用，开始的时候坑不少，经过多年的磨练，现在的RN也填了不少的坑。在金融领域，也有一些采用者。

近年来，Google也在琢磨这事情。“要让开发人员学习Dart这种更牛逼的语言，写出高性能的App”、“要让企业只养一套班子”、“要让同样的代码牛逼到不仅仅跑在iPhone和Android上，还可以跑在个人电脑上” – 于是Google发明了一种技术叫Flutter。市场上也开始有越来越多的企业采用，当然，作为新生事物，坑还不少。在金融业，有没有机构在开始采用？可能还没有，或者有也是极少数。

无论如何，开发App的技术是在进步的，起码在这三个方面：

1）越来越不需要养“两套班子”了，节省人力成本

2）开发门槛低了些，起码在iOS上，掌握Objective-C这种古代语言不是一种那么令人愉快的事情。同样的功能用Objective-C和Java分别在iOS和Android上实现一次，还无法保障它们运行起来是否表现一致。现在业务逻辑用JavaScript或者语法与JavaScript有相似性的Dart，开发一次，在两种移动端都可以运行，确实便利

3）业务逻辑可以“热更新”了。想一想每次修个小bug也要对整个App重新编译、打包、回归测试、向各应用商店申请上架、等上几天才获得批准，甚至有被驳回的危险，这个过程多痛苦？绕开应用市场（尤其是苹果商店）让一些业务逻辑的代码能被App自身进行远程加载更新，对于经常有业务或监管需求不得不紧急迭代升级的金融机构来说，是非常必要的

可是，上述这些技术，有让我们的App变“轻”吗？恐怕不见得。

无论手机银行还是手机证券类App，实质上都是银行、券商放在用户手里的移动门户，一个App后面对接着很多的业务、很多的部门、很多的场景、很多的金融产品类别，这些东西只要耦合在App上，无法由不同的团队、按不同的时间节奏相对自由的发布到App中，这个App就无法真正的“轻”起来。

就会导致牵一发动全身、就需要整个App的回归测试；开发模式上，就需要有项目经理、产品经理去协调企业内各部门的需求，排优先级，把功能实现排个优先级，进入App开发团队那资源有限的管道中排队。

领导说，App是我们的“金融科技”（虽然并不是），必须全面投入，给你100个工程师… 可是这100号人估计大部分坐冷板凳，因为现有的技术架构没办法让你把人并行的用起来。

金融类App的特点

很多金融机构都有1到多个所谓的“C端”，以及1到多个所谓的“B”端。前者是在移动互联网发展早期导致的，可能是不同的业务部门各有想法、各自发展，逐渐形成了多个承载不同业务线的App；有些情况下，也出现不同厂家为其提供的、商业目的一样的、内部竞争的App – 券商里存在这种情况的不在少数。

后者则往往是因为缺乏企业级的统筹，一会儿是建设一个赋能零售人员的移动应用，一会儿是采购一个解决远程办公问题的移动OA，一会儿是公司引入了某个CRM的移动版… 总之到了后来，出现五花八门的各种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是时候考虑新的架构

基于金融类App的特点，“宿主”+ ”碎片”的架构是非常适合的：

首先，金融类App如手机证券软件，非常强调稳定性，如果能保持一个已经在生产环境打磨过多年的App“内核”，则是最为理想的。这个“内核”仅以原生（native）方式实现最关键、最需要稳定的行情与交易相关基础功能，轻易不作改动。在当下的股市，能扛的住黑天鹅事件频发的所引起的突发性客流量、交易量，需要一个稳定、可靠的交易核心，也就是说，把App本身也分成券商IT们喜欢说的“稳态”和“敏态”。

其次，大部分的业务功能，以“碎片”的方式实现，拥有完全独立的生命周期，独立于App之外进行开发、测试、灰度发布。“碎片”最理想的技术载体，是类似“微信小程序”那样的形式。想象业务功能点以小程序开发，经过IT内测、业务部门UAT、合规审核、运维上架，整个发布流程完全数字化、在线。发布之后，依然通过灰度控制，让该业务功能小程序在有限人群范围逐渐放开，这一切在App侧是无感的，万一有问题，可以瞬间下架。

第三，兼容微信小程序的“标准”。开发人员只要懂微信平台上的小程序规范与框架，就能够开发。这样，在市场上能找到大量的技术人员，从大学毕业生到有经验的工程师，人才资源更加丰富。当前百度、阿里、美团、京东、字节跳动等互联网大厂均有类似于微信小程序的技术，但是无论哪家厂都不得不接受有巨大先发优势的微信小程序作为“既成事实”的开发标准。虽然我们可以基于Flutter、RN等技术重新发明“碎片化”的技术载体，可是市场上有无大量可驾驭这些技术且成本较低的人才也是我们在设计技术方案时需要关注的。

第四，金融机构（券商、银行、保险、基金等）自己扮演了腾讯的角色，在自己的机房运行自己的小程序中心，让内部的工程师、外部的外包商技术人员、合作伙伴的IT都可以申请获得“开发者账户”，申请把自己开发的小程序进行上架和灰度发布。这个能力一旦建立，金融机构各条业务线就有可能通过自己的IT团队或者临时招募的合同工程师，针对自己的业务场景开发小程序并申请上架到公司的App（也是面向所有客户的移动门店）。

这有可能导致一种新的IT研发团队组织结构（例如小程序开发人员可能由“业务IT”负责，与App研发团队解耦）、一种更加DevOps友好的开发模式（结合PaaS和Serverless技术）。

App从信息化到数字化的跳跃

技术人员在评估选择App开发技术的时候，往往只考虑解决跨平台问题、热更新问题、开发语言问题、开发框架问题，在RN、WeeX、Flutter或原生与Hybrid型技术的选型之间纠结。但就金融这个领域来看，这些技术都只是底层的实现手段，它们是战术性、技巧性的、从信息化角度看的。着眼点还是提高内部开发效率、降低一点开发成本。这还是把App的实现看成是一个信息化过程，和20年前开发网站把企业内部的一些技术系统集成输出以便于客户在网上自服务，是一个思维。

移动互联网改变了这个格局，带来了数字化时代。移动端App是数字化的开端。新一代金融类App，起码需要做到以下几点。

具有传播能力。传播的不仅是信息，还有工具和场景。目前最普及、最容易为大众所接受的，就是小程序这种载体。想一下，现在连七八十岁的老人，都知道微信里的小程序这么个东西，知道用它打开健康码出入小区。子女替父母购买电商产品，把一个小程序转发过去，老人即可打开购物车看到是否自己要的东西。这种在终极用户层面的感知，不是RN、Flutter纯粹技术实现层面所能达到的。

具有连接能力。平台型的App和纯工具型的App不同之处在于，前者天然具有社交属性，这也是移动互联网给我们带来的产物。当前无论银行、证券还是保险类的App，绝大部分缺乏平台思维，都是做成高度同质化的、客户自服务为导向的、工具型的东西，可是很多金融服务的性质天然决定它应该是平台型的，是对接多方 – 外部的客户、合作伙伴和内部的各种业务线及岗位职能。连接多方，让他们以共同的场景、上下文进行交流互动，是数字化的另一个要素。而小程序，刚好是能以场景化促进连接的技术载体。

具有生态化能力。我们知道互联网巨头们逐渐形成了所谓的Super App（超级应用），它们手握公域流量，在自己的平台上让大量的第三方“进驻”，让自己的客户在一个Super App里获得所有的工具与服务，通过丰富的生态圈住了用户，同时也把合作伙伴牢牢绑住。金融业能否出现Super App，有不同的观点。但国内一些大型银行的App，显然是在尝试成为Super App，玩生态游戏。那么对中小型的金融机构是否就没有参考价值呢？显然不是，在数字化的世界，一切都是生态化的，无法想象这个时代我们哪家金融机构不需要外部的合作 – 资讯内容的提供商、新媒体的合作伙伴、理财产品的代销机构、专业培训机构… 通过一个强大的合规审核后台，把合作伙伴的小程序“上架”到自家的App，借力外部资源共同服务客户，是未来的一种可能。以保险公司为例，完全可以构建这么一个数字化生态平台，引入更多的合作伙伴服务客户，把一个个静态的“保险账户”变成“用户”。

具有最简最优的用户体验。很多金融业务其实是低频的，不必期望所谓的用户黏着度、活跃度，在App里堆叠大量的功能，不见得有多好的投入产出比。通过推送高质量、个性化、为客户量身定制的资讯内容来吸引和转化用户，在他到来时则给他干净利落、简单好用的自服务功能，是一个更好的方向。

越简单的应用实质上越强大，结合On-Device AI（端侧智能），App的操作界面是越来越简单越来越回归人类感官本能的。正如很多父母辈的老人，不要说驾驭不了PC，连打字机都从不曾触摸过；结果智能手机出现后却能熟练掌握以即时通讯工具进行社交，阅读分享新闻、进行电商购物。越来越结合人工智能的软件，界面只能进一步的简化，了解用户的画像、对用户的行为偏好有预测能力的AI，会把与App的人机交互复杂度降到最低。让用户通过一个极简主义的App“宿主”，获得智能算法推荐过来的各种“碎片化“功能（小程序），随需随用，用完即走，再也不需要在一个App的菜单和服务入口里层层深入的去定位一些功能。

凡泰极客希望把迄今为止只有互联网巨头们才拥有的小程序技术能力，以“白牌”（white label）方式赋能给传统金融业。

我们把“小程序运行时”实现成一个可私有化部署的iOS和Android版本的SDK，任何金融机构的App均可以嵌入该组件而瞬间获得运行小程序的能力；同时也提供了“小程序开放平台”的解决方案，供任何金融机构、行业组织运行自己的小程序生态、统一上下架管理自己以及合作伙伴们的业务场景。

与互联网巨头方案不一样的是，我们的方案不仅更加开放（提供API接口，支持二次开发），也更聚焦金融行业在合规监管方面的特殊行业诉求。目前已在多家银行、保险、证券以及相关行业机构落地，并能够自有机房内独立部署运行。不仅如此，“FinClip小程序技术”语法结构和微信小程序兼容，一次开发，多处上架，可降低开发成本，提升研发效率。

FinClip小程序当前已经开放了一键部署功能，现可免费体验，只需5行代码30分钟，即可在您的应用内集成「小程序运行时」

凡泰极客作为金融行业小程序生态解决方案领航者，致力于以自主研发的基础技术设施，发展金融科技与监管科技，打造金融营销场景服务闭环。其旗下小程序开放平台FinClip已经获得市场的广泛认可、凭借其差异化的产品解决方案及行业领先优势已经在多家银行、券商、保险、互联网等各垂直行业落地实践，且为东吴证券、华西证券、安信证券、广发证券、浦发银行、盈米基金等多家头部企业提供服务。