内容共6300字。预计读完需要10分钟。您也可以保存并稍后阅读。

本文不是一篇纯粹的技术文章。我想和IT、电商、互金、网络金融、数字化运营部门的同事一起讨论App的数字化建设。

您的应用程序是否变得越来越“重”？

应该说，到今年为止，银行和证券行业机构在智能手机上开发应用程序已经有十年了。

在过去的十年里，我相信许多组织的应用程序都经历了几次“彻骨”的重大变革。一开始，一些技术是外包的，然后要求开发人员进行定制和修补。但他们发现自己无法应对市场变化、业务创新需求、监管规则变化，于是要么购买源代码，组建自己的研发团队来接手。完成自研，或者从头开始，使用新的技术框架重新开发。我相信许多组织都经历过维护旧应用程序或构建新应用程序的困境，以及同时操作和维护两个甚至更多旧应用程序的痛苦。

即使最终稳定在一个相对干净整洁的架构上，随着功能的不断堆叠和不同阶段的开发者不断的接手和改造，它很可能会变得更加复杂和繁琐，比如个人的技术水平工程师。导致App内模块划分不明确，功能耦合度较高。说到底，改变任何事情都可能“牵一发而动全身”；更糟糕的是，负责人离开后，可能没有人愿意做某些部分的代码。或者他们不敢碰它，它逐渐成为App中的一个黑匣子。

应用程序功能随着时间的推移而积累，开发团队成员来来去去。应用程序变得越来越“脆弱”。每个版本需要更长的时间并且需要更多的功能点来进行回归测试。由此可见，“敏捷迭代”形同虚设。开发团队正忙于开发新功能、填补安全漏洞、实施监管机构要求的一些合规性要求以及消除客户投诉的应用程序功能。

创新变得越来越困难。

现有技术能否让应用变得“轻”？

首先，我们简单回顾一下App技术的发展轨迹。

在古代，每个人开发应用程序时都必须维护两个团队——一个负责版本，一个负责版本。这两类人的知识结构、使用的编程语言、掌握的技术概念都是不兼容的。如果产品经理想要实现相同的业务功能，他必须告诉两组人一次。而且，两个阵营的版本功能经常不同步。这类App称为App（原生应用）

后来，有人开始疑惑，我是否可以只开发一次业务逻辑代码，并在两个世界中无缝运行？于是我开始发明应用页面的开发，通过“反向代理、远程加载、本地渲染”来运行它们，并通过一种叫做JS的“桥接”技术连接到手机上的原生代码。这种类型的App称为App（混合应用程序）。这类应用一开始的性能并不是很好，但经过多年的优化（尤其是浏览器内核的优化）以及手机硬件的升级，性能普遍有所提升。截至目前，大多数金融应用程序估计都属于这一类。不过，通过这个方案，我们还是要维护iOS的“两个团队”和“两个团队”，分别负责各自平台的一些原生部分。

后来我也开始思考这个问题。 “让开发者用类似的语法写出接近原生的性能效果”、“让企业只维护一个团队”——于是一种叫做RN的技术就被发明了。越来越多的公司在市场上采用它。一开始就遇到了很多陷阱。经过多年的训练，RN也填补了很多坑。在金融领域，也有一些采用者。

近年来，我也一直在思考这个问题。 “开发者必须学习像Dart这样更强大的语言，编写高性能的应用程序”、“企业必须只有一个团队”、“同样的代码必须强大到不仅可以运行在而且还可以运行在个人电脑上”计算机”——因此发明了一种称为“计算机”的技术。越来越多的公司开始在市场上采用它。当然，作为一个新生事物，仍然存在很多陷阱。在金融行业，有机构开始采用吗？可能还没有，或者可能很少。

无论如何，开发应用程序的技术正在进步，至少在这三个方面：

1）越来越不需要维护“两套团队”，节省人力成本

2）开发门槛较低。至少在iOS上，掌握-C这样的古老语言并不是那么令人愉快。分别使用 -C 和 Java 在 iOS 和 上实现了相同的功能。无法保证它们能够持续运行。现在业务逻辑开发一次或者语法类似于Dart，就可以在两个移动端运行，真是方便。

3）业务逻辑可以“热更新”。想想看，每次修复一个小bug，你都要重新编译、打包、回归测试整个应用程序，向各个应用商店申请上架，等待几天才能获得批准，甚至面临被拒绝的风险。这个过程有多痛苦？绕过应用市场（尤其是 ）允许App本身远程加载和更新一些业务逻辑代码。这对于经常有业务或者监管需求，需要紧急迭代升级的金融机构来说是非常有必要的。

然而，以上技术是否让我们的App变得“轻”了呢？恐怕不是。

无论手机银行还是手机证券APP，本质上都是银行和证券公司放置在用户手中的移动门户。一个App可以处理很多业务、很多部门、很多场景、很多金融产品品类。只要东西与App是耦合的，不能由不同的团队、不同的时间节奏相对自由地发布到​​App上，App就不可能真正做到“轻”。

这将导致需要对整个App进行回归测试。在开发模式中，需要项目经理和产品经理协调企业内部各部门的需求，优先实现功能，进入App开发团队在资源有限的管道中排队。

领导说App是我们的“金融科技”（虽然不是），我们要全力投入，给你100个工程师……但这100个人中的大部分人很可能都是坐在板凳上，因为现有的技术架构不能让你投入使用。人们并行使用它。

金融类APP的特点

许多金融机构都有一个或多个所谓的“C 侧”和一个或多个所谓的“B”侧。前者是移动互联网发展初期造成的。可能是不同的业务部门有自己的想法和发展，逐渐形成了多个承载不同业务线的App；在某些情况下，还存在不同制造商提供的商业用途。相同且内部竞争的应用程序——这在经纪公司中并不罕见。

后者往往是由于企业层面缺乏协调造成的。有时是构建移动应用程序来为零售员工赋能，有时是购买移动OA来解决远程工作问题，有时是公司推出某种CRM的移动版本……总之，我们来了。后来，出现了各种各样的应用程序，允许员工安装一堆应用程序。这些应用程序在同一部手机上显然彼此无关，形成信息孤岛，迫使用户来回切换。最后大部分app都用了。起不来。例如，一家大型银行为员工提供了十多个应用程序，占据了他们的一部手机屏幕。根据类似的图标很难选择哪个用于什么目的。

金融类APP实际上具有以下特点：

可以说，不少银行、证券、保险类App都是碎片化功能的“集散地”。理想的解决方案是每个“片段”都独立开发、测试、灰度发布。它具有独立的生命周期，App运行在“宿主”上，但不能影响“宿主”的稳定性和安全性。

从伟大之路到简单之路

“碎片化”与“托管化”——有没有这样的应用架构值得我们借鉴？当然有，大家都熟悉的就是微信。

微信App本身比较纯粹，功能设计非常内敛，遵循着比较简约的设计逻辑（当然，这要看你和谁比较，在海外市场，可能是一个更纯粹、以功能为主、用途单一的应用）我是）。但上面运行着数以百万计的小程序。这些小程序是场景化、功能化的“碎片”，用户可以按需使用，用完就离开。微信本身就是支撑这些“碎片”运行的“宿主”（宿主这个比喻可能不是最贴切，但它让小程序可以在里面生存，通过分享、转发的方式传播出去）。

小程序的性能缺陷不会影响微信App本身，小程序的安全漏洞理论上也不会导致微信本身的信息安全问题。上千个小程序由不同机构拥有和开发，它们的升级和迭代从来不影响微信App本身的稳定性。微信App本身在应用市场的发布和更新也不会影响各种小程序的存在。微信App及其中运行的小程序具有独立的生命周期，彼此之间松散耦合。

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

金融App能否梳理出一个稳定的“内核”，可以作为“宿主”来运行、共享、传播各种频繁变化、快速迭代的功能片段？

金融应用程序是时候考虑新架构了

基于金融类APP的特点，“主机”+“分片”的架构非常适合：

首先，金融类APP，比如手机证券软件，非常注重稳定性。如果他们能够维护一个在生产环境中打磨多年的App“内核”，那就更理想了。这个“内核”仅以原生（）的方式实现了最关键、最稳定的市场和交易相关的基本功能，并不轻易做任何改动。当前的股市，需要一个稳定可靠的交易核心来承受黑天鹅事件频发带来的突发客流和交易量。换句话说，应用程序本身分为几个部分。券商IT人喜欢说“稳态”和“敏感态”。

其次，大部分业务功能都是以“碎片化”的方式实现，具有完全独立的生命周期，独立于App进行灰度开发、测试和发布。 “碎片”最理想的技术载体是类似“微信小程序”的形式。想象一下，业务功能点被开发为小程序。经过IT内测、业务部门UAT、合规审核、运维，整个发布流程完全数字化、线上化。发布后，业务功能小程序通过灰度控制逐步向有限人群发布。这一切在App端都是不可见的。如果出现问题，可以立即删除。

第三，兼容微信小程序的“标准”。开发者只要了解微信平台的小程序规范和框架就可以进行开发。这样，市场上就能找到大量的技术人才，从大学毕业生到经验丰富的工程师，人才资源更加丰富。目前，百度、阿里巴巴、美团、京东、字节跳动等各大互联网公司都拥有类似微信小程序的技术，但无论哪家厂商都必须接受微信小程序作为微信小程序的巨大先发优势。 “既成事实”的制定标准。虽然我们可以基于RN、RN等技术重新发明“碎片化”的技术载体，但在设计技术方案时需要关注市场上是否存在大量能够低成本掌控这些技术的人才。

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

这可能会带来新的IT研发团队组织结构（例如，小程序开发人员可能负责“业务IT”，与App研发团队解耦）和更友好的开发模式（PaaS与技术相结合）。

App从信息化到数字化的跨越

技术人员在评估和选择App开发技术时，往往只考虑解决跨平台问题、热更新问题、开发语言问题、开发框架问题，在选择RN、WeeX，还是原生和传统技术之间纠结。但就金融领域而言，这些技术只是底层的实现手段。它们是战术、技术和信息角度的。重点仍然是提高内部开发效率，降低开发成本。这还是把App的实施看成是一个信息化的过程，和20年前开发网站时的思路是一样的，把企业内部的一些技术系统集成输出，让客户在线上为自己服务。

移动互联网改变了这一格局，带来了数字时代。移动应用程序是数字化的开始。新一代的金融应用至少需要做以下几件事。

有传播能力。传播的不仅仅是信息，还有工具和场景。目前最流行、最容易被大众接受的载体就是小程序。想一想，现在连70、80多岁的人都知道了微信小程序，知道如何用它打开健康码进出社区。孩子给父母购买电商产品时，转发一个小程序，老人就可以打开购物车，看看是否想要自己想要的东西。这种最终用户层面的感知是RN或者纯技术实现层面无法实现的。

具有连接功能。平台型App和纯粹工具型App的区别在于，前者天然具有社交属性，这也是移动互联网给我们带来的产物。目前银行、证券、保险类APP大多缺乏平台思维，被做成高度同质化、以客户服务为主、工具化的东西。然而，许多金融服务的性质自然决定了它们应该是一个连接多方——外部客户、合作伙伴以及内部各种业务线和工作职能的平台。连接多方并允许他们在共同的场景和环境中进行沟通和交互是数字化的另一个要素。小程序只是一个技术载体，可以场景化的方式促进连接。

具备生态能力。我们知道，互联网巨头逐渐形成了所谓的Apps（超级应用）。他们控制公共领域的流量，并允许大量第三方“驻扎”在自己的平台上，让他们的客户在一个App中获得所有工具和应用程序。服务通过丰富的生态圈住用户，同时也牢牢绑定了合作伙伴。对于App能否出现在金融行业，存在不同的看法。但国内一些大型银行的APP显然是在试图成为APP，玩生态游戏。那么对于中小金融机构来说没有参考价值吗？显然不是。在数字世界中，一切都是生态的。难以想象，我们这个时代任何一家金融机构不需要外部合作——信息内容提供商、新媒体合作伙伴、金融产品销售机构、专业培训。组织……未来有可能通过强大的合规审核后端，将合作伙伴的小程序“上架”在自己的应用上，并利用外部资源，共同服务客户。以保险公司为例，可以搭建这样一个数字化生态平台，引入更多的合作伙伴来服务客户，把静态的“保险账户”变成“用户”。

拥有最简单、最好的用户体验。很多金融业务其实都是低频的，不需要期望所谓的用户粘性和活跃度。在App中堆砌大量的功能，并不一定能有很好的投入产出比。通过推送优质、个性化、定制化的信息内容来吸引和转化用户，并为他们提供干净、简单、易用的自助服务功能，是一个更好的方向。

应用程序越简单，它的功能就越强大。结合On-AI（设备端智能），App的操作界面变得越来越简单，越来越回归人类的感官本能。就像很多父母那一代的长辈一样，别说他们不会操作电脑，就是连打字机都没接触过。然而，智能手机出现后，他们开始熟练使用即时通讯工具进行社交、阅读和分享新闻、进行电子商务购物。随着软件越来越多地融入人工智能，界面只能进一步简化。了解用户个人资料并能够预测用户行为偏好的人工智能将最大限度地降低应用程序人机交互的复杂性。让用户通过一个极简的App“宿主”，获取智能算法推荐的各种“碎片化”功能（小程序），并根据需要使用并深入服务入口定位某些功能。

泛太极客希望以迄今为止只有互联网巨头具备的小程序技术能力，以“白卡”的方式赋能传统金融行业。

我们已将“小程序运行时”实现为可私有部署的iOS及版本SDK。任何金融机构的App都可以嵌入该组件，立即获得运行小程序的能力；我们还提供“小程序开放平台”解决方案，供任何金融机构或行业组织运行自己的小程序生态系统，统一管理自身及合作伙伴的业务场景。

与互联网巨头的解决方案不同，我们的解决方案不仅更加开放（提供API接口，支持二次开发），而且还关注金融行业在合规监管方面的特殊行业需求。已在多家银行、保险、证券及相关行业机构实施，可在自有机房独立部署和运行。不仅如此，“幻想小程序技术”的语法结构兼容微信小程序。可以一次开发，多次上架，可以降低开发成本，提高研发效率。

泛泰小程序目前已具备一键部署功能，现在您可以免费试用。只需 5 行代码，30 分钟即可将“小程序运行时”集成到您的应用程序中。点击【阅读原文】通过手机号进入官网完成注册体验

如果您想了解更多关于“泛泰小程序技术”解决方案，或者您有任何疑问？欢迎打开下方小程序进行在线咨询

过去的选择