在政务移动门户的项目里，永远会遇到一个非技术，但需要技术来解决的问题：单纯的 APP 开发没有太多的技术门槛，原生页面、接口联调、上架发版，这些事任何一家成熟的开发团队都能做，但需要花费大量的时间去做跨部门、跨供应商的对接工作。 一个政务移动门户APP要整合十几个甚至几十个部门的服务。这些服务可能由不同供应商建设，形态也不一样：有的是微信小程序，有的是 H5 页面，有的还挂在公众号菜单里。对接的成本大头不在写代码，更重要的是对齐：排期要对齐，接口规范要对齐，账号体系要对齐，验收标准也要对齐。每接进来一个部门，都要重新走一遍流程。/ 今天分享一套基于小程序运行底座的解法，将"逐个对接"怎么变成"统一接入"。 对接成本主要有哪些 按照传统的开发方式，如果需要引入一个部门的服务进入APP，通常需要考虑三个部分： 首先是逐家联调，每家供应商一套接口风格、一套鉴权方式，门户团队要分别做技术评估、安全审查和联调测试，再各自走一轮验收。部门越多，这部分工作量越是线性上涨。 然后是形态不一，小程序、H5、原生页面混在一个 APP

近日，以“新智联·新未来”为主题的鸿蒙生态大会2026在深圳举行。大会汇聚政府部门、产业组织、科研机构、高校、行业企业及生态伙伴代表，围绕技术创新、标准建设、产业协同与规模化应用展开交流。 大会表明，鸿蒙生态正从技术验证和生态共建，走向更广泛的行业应用。对金融机构和大型企业而言，既有APP承载着大量成熟业务，如何在控制成本和风险的前提下适配新生态，并把AI带入业务办理流程，成为新的现实问题。 深圳凡泰极客科技有限责任公司受邀参与大会，凡泰极客战略与业务增长副总裁彭肖镝围绕“APP非重构的AI智能化升级”展开分享，介绍了基于FinClip SDK与FinClaw Agent引擎的应用升级路径：通过轻量化接入，将对话式AI、生成式卡片和小程序化业务能力融入现有APP，在尽量减少原有业务代码改造的情况下，让用户能够以自然语言发起需求，并在当前应用内完成查询、确认和办理。 01从“适配一个新系统”转向“建设可持续演进的应用底座” 传统移动应用升级往往牵涉原生开发、多端适配、测试验证和应用商店审核。随着终端类型增加，如果继续为不同平台分别维护完整技术栈，交付周期、版本管理和安全治理都

近日，由上海金融信息行业协会指导的CIFS 2026第九届中国金融数智峰会在上海举行。凡泰极客携FinClip超级应用智能平台、FinClaw企业级自主Agent中台和FinDesk企业级AI桌面亮相数智技术展区，与金融机构及产业伙伴共同关注超级App建设、AI应用治理与金融业务落地。 FinClip：让金融App从功能入口，走向可持续运营的超级App 对金融机构而言，App已经不只是查询和交易入口。投教资讯、营销活动、生活权益、客户服务、企业金融及生态合作等场景持续增加，多团队开发、多版本并行和多终端适配也随之成为常态。若所有能力都与主App紧密绑定，一次业务更新往往需要跨团队协调并等待整包发版，影响市场响应速度，也增加版本管理和生态治理的复杂度。 FinClip以小程序容器技术和小程序开放平台为基础，为金融机构提供端云一体的业务承载与运营能力。端侧SDK负责小程序的安全运行与多终端适配，云侧平台统一管理小程序、应用、开发组织、代码、版本和发布流程；同时支持私有化及信创环境部署，便于机构在自有技术和安全体系内建设开放生态。 在银行、证券、保险等场景中，核心交易能力可以继续保

每个省市都有自己政务APP门户化建设的需求，核心还是希望让市民需要一个入口，就能办完各个部门的事情。 但现实情况是，市民希望入口集中，不用在小程序、公众号和H5页面之间来回切换、反复登录；而各个业务部门那边却各有各的现实，服务由不同供应商开发，迭代节奏也不一样，有的事项一年只改几次，有的专区每周都在调整。如果把几十项服务全部收进 APP 主工程，所有部门的页面变更都得排队等客户端版本，改一个表单字段也要等发版窗口。 难的不只是APP开发，更需要关注如何资源整合 如果只是客户端开发，做一个政务 APP 并不难。难的是建成以后，怎么长期容纳多个部门的服务而不失控。 通过原生方式集成，各部门的业务代码会持续汇入主工程。一方面APP包会越来越大，但更麻烦的在协作上：任何部门改一个页面，都要经过主工程的合并、构建和回归测试，再走应用市场上架；一个部门的服务延期，可能拖累整个版本；某次更新出了问题，受影响的也不止那一家。 同时供应商关系也会遇到管理问题，统一身份是一家单位建的，事项系统来自另一家厂商，部门小程序还有各自的服务商在维护。谁能提交代码，谁负责审核，线上跑的是哪一版，出故障怎

其实国内不少地方的政务服务，最早一批入口其实建在微信、支付宝的小程序里面的，预约取号、事项查询、材料预审、缴费、办件进度，这些服务在微信端跑了几年，页面和接口都经过多轮打磨，业务部门和建设单位对这套开发、提审、发布的节奏也已经熟悉。 等到要建设或者升级自有政务 APP，这些已有服务怎么处理，就摆上了桌面。常见的做法是把清单逐项排进客户端需求池，页面按原生重写一遍，接口重新联调，再跟着 APP 版本走测试和上架。几十项服务排下来，工期和预算都很可观，而且微信小程序那边还得继续维护，同一项服务从此有了两套实现。 今日分享另一种解决方案，是否可以复用这些小程序代码，因为这些小程序代码本身就是一份成熟的业务资产。如果自有 APP 也能提供小程序的运行环境，存量代码就有机会直接复用，二次开发集中在少数绕不开的差异上。 小程序为什么一定要在微信上运行 一个微信小程序工程，拆开看是 WXML 页面结构、WXSS 样式、JavaScript 业务逻辑和 JSON 配置。这些文件自己并不会运行，它们能变成用户看到的服务，靠的是微信客户端在背后提供的运行环境。 以小程序容器技术的一般实现来看，

过去几年，企业建设 APP 的逻辑很明确：把更多业务、更多服务和更多用户场景放进同一个入口。银行 APP 从账户查询延伸到理财、信用卡、贷款、缴费和生活服务；城市服务 APP 从信息查询扩展到预约、办事、支付和公共服务；企业级 APP 也在不断整合内部工具、业务流程和第三方服务。 能力变多以后，另一个问题也随之出现：用户知道自己要办什么事，却未必知道对应的入口在哪。首页宫格、频道页、搜索框、运营位和多级菜单能承载大量功能，但用户仍要先理解产品如何分类，再沿着页面路径找到服务。功能规模小的时候，这种方式足够直接；当业务模块越来越多，找入口本身就成了任务的一部分。 AI 带来的变化，是让用户可以先表达需求。例如，用户说“帮我查一下本月账单”“我想预约明天的业务办理”，APP 先理解这句话，再把用户带到可继续操作的服务页面或卡片中。AI 不替代原有业务系统，业务办理、权限校验和交易确认仍由原有流程承担；它增加的是一个更接近用户意图的服务入口。

已有微信小程序，想在自有 APP 里继续使用，通常不需要把所有页面重新做成原生页面。迁移的重点不在于“把代码包上传一次”，而在于把原来依赖微信环境的能力梳理清楚，再接入宿主 APP 和小程序管理平台。 FinClip 在其中承担两部分工作：小程序容器负责让小程序在 APP 内加载和运行；小程序管理平台负责版本上传、体验测试、审核、发布、灰度和下架。原有的订单、会员、内容等业务系统仍然沿用，不需要重建。 整套流程可以按七步推进。 第一步：确定迁移范围 先确定首个迁移版本要覆盖哪些业务，不要一开始把全部页面都纳入范围。通常优先选择访问频率高、业务流程相对完整、对微信专属能力依赖较少的模块，例如服务查询、内容浏览、预约提交或会员服务。 准备材料时，至少要有： * 当前稳定的小程序代码分支和构建配置； * 页面清单，标出首页、登录页、提交页、结果页和异常页； * 微信侧能力使用清单，例如登录、支付、分享、订阅消息、扫码、

自己的APP想要引入AI能力，不知道该如何去引入？达到什么样的效果，先看看微信是怎么做的： 今年 6 月，微信“小微”开启小范围内测，用户可以用语音或文字提出需求，由 AI 调起小程序完成挂号、购买咖啡等生活服务，用户不用先翻菜单，先把想办的事说出来。 其实现在很多App已经碰到相同的问题。服务一年年增加，首页却没有无限的空间。预约、账单、订单、发票、权益、活动、客服、内容专区都要有入口，用户要办一件事，要去一层层菜单去找到自己的需求，熟悉App 的人还好，低频服务一多，很多人连入口是否存在都不确定。 微信里的小微值得借鉴的是：它把对话接到了后面的服务上。用户说“帮我预约明天的服务”之后，AI 能把服务接着办下去。对企业 App 而言，已经上线的小程序、H5 页面、原生功能和合作方服务，同样可以被组织成可调用的服务网络。AI

一个运行多年的 APP，很少还保持着最初那套干净的页面结构。首页和交易流程可能是原生页面，活动专区、帮助中心和部分业务办理已经放进 WebView，消息、搜索、扫码和外部链接又分别维护着自己的跳转规则。新功能能持续上线，背后通常也积累了不少兼容逻辑。 准备引入小程序容器时，SDK 通常接得进去，团队更担心 APP 里从此多了一种页面类型。原生、H5、小程序各有路由和生命周期，如果登录、支付、返回、错误提示、埋点仍由业务团队分别处理，页面越多，线上问题越难判断由谁负责。 这种担心有道理。小程序容器只是提供一套新的业务运行环境，它不会自动整理存量 APP 里已经分散的公共能力。改造的重点也因此落在公共层：三种承载方式怎样分工，以及它们怎样共用同一套路由、身份、能力和监控规则。 存量APP的复杂度通常早已存在 很多项目在引入小程序之前，原生和 H5 已经各自形成了一套连接宿主的方式。某个 H5 页面通过 URL 参数拿登录信息，另一个页面通过 JavaScript

很多APP第一次接入合作伙伴时，SDK 往往是最省事的选择。对方已经准备好 iOS 和安卓版本，客户端团队照着文档加依赖、申请权限、处理登录和回调，联调完成后跟随下一个 APP 版本上线。一两项能力这样做，通常推进得很顺。 但是随着会员权益、内容频道、短剧、营销活动、生活服务陆续进入APP，每家合作方都带着自己的依赖、初始化方式和升级节奏。单独看，每个 SDK 都能正常运行；放进同一个主工程里，依赖冲突、权限变化、包体增长和兼容测试开始互相影响。合作方只改了一个业务页面，APP 团队仍可能要重新打包、回归和上架。 为什么APP会越做越大？ SDK 的优势很明确。地图导航、音视频、设备连接、崩溃监控等功能需要深入调用操作系统能力，放在原生环境里更合适，性能和生命周期也更容易控制。 同样因为接得深，后续成本会留在客户端工程中。每增加一家 SDK，主工程里可能就会多出一组依赖库、编译配置、权限声明、初始化逻辑和回调。

很多APP在引入第三方服务的早期，处理方式都很直接：新接入一项权益、内容或生活服务，就在首页增加一个图标；合作方希望获得更多曝光，再补一个轮播图或频道入口。当服务只有几项时，用户还能顺着首页找到，但随着接入数量增加后，首页会越来越长，频道越分越细，运营人员也开始争抢有限的入口位置。 小程序容器的技术架构让第三方服务进入APP变得更灵活，合作方可以按小程序方式交付业务页面，APP 不必为每项服务分别集成一套原生 SDK，页面更新也不必总跟着客户端主包发版。服务接得更快以后，入口很快就跟不上了：几十项服务已经在线，用户应该去哪里找？ 继续增加图标只能暂时解决曝光，APP 需要从“页面入口管理”转向“服务发现”，让首页、分类、搜索、最近使用和用户权限共同决定服务怎样出现。 小程序容器如何让第三方服务运行在自有APP中 简单来说，小程序容器是集成在宿主APP 内的一套运行环境。iOS、安卓或鸿蒙客户端接入对应的小程序 SDK后，运行时负责获取和加载小程序代码包，处理页面渲染、路由、生命周期、缓存，以及小程序与宿主能力之间的交互。用户看到的页面直接运行在自有APP内，无需跳到微信或其他

不少APP团队原来只维护iOS和安卓两套客户端，协作方式已经比较稳定，现在也需要开发鸿蒙客户端，加入以后，同一项需求开始需要三个团队来实现：三个团队分别做页面、接接口、处理登录和权限，再各自测试、构建和发布。 如果需求是会员查询、活动专区或售后办理，三端背后的业务流程通常没有太大区别。产品改一个字段，三个工程都要跟着修改；接口增加一种状态，三端分别补页面和异常处理；其中一端排期晚几天，功能就很难同时上线。团队表面上在维护三个客户端，很多时间却花在重复实现同一项业务。 小程序容器提供了一种全新的解决方案：iOS、安卓和鸿蒙仍然保留自己的宿主 APP，系统相关能力继续按平台建设；页面、路由、表单、接口调用和业务规则放进一套小程序工程，由三个客户端中的小程序运行时共同承载，大幅度降低二次开发的成本。 重复开发的主要是业务的频繁迭代 iOS、安卓和鸿蒙有各自的应用生命周期、权限模型、导航方式和工程工具。APP 启动、账号安全、消息、支付编排、系统权限以及设备能力，通常都要留在原生宿主中处理。三个客户端分别维护这些底层代码是合理的，因为它们直接连接操作系统，差异无法靠复制一份页面代码消

随着小程序生态的普及，很多团队都希望将H5升级为小程序，来承载APP内的业务和第三方的服务生态，前期很多团队的注意力都会先放在客户端：SDK要改多少代码，包体会增加多少，iOS、Android、鸿蒙能不能接，已有小程序能不能直接打开。 可一旦准备上线，问题就变了。开发人员发来两个代码包，一个叫“正式版”，另一个叫“正式版改”；测试人员手里还有一份上午验证过的版本。运营准备晚上八点发布，却没人能确认哪个包已经审核、哪个版本关联了生产 APP。上线后发现登录页有问题，团队又开始在群文件里找上一个稳定版本。活动临时结束，还要请客户端同事关闭入口，已经打开的小程序该怎么处理也没有约定。 客户端SDK没有出问题，只是它负责的范围到“加载和运行”就结束了。业务长期在线，还要管理小程序身份、代码版本、宿主范围、审核记录和发布状态。小程序只有一两个时，这些工作可以靠群消息和表格勉强维持；接入的团队和版本逐渐增多，管理平台就成了小程序容器架构中的另一半。 端侧运行和云端管理如何定位 小程序容器位于宿主APP内，负责代码包加载、页面渲染、生命周期、缓存、沙箱隔离，以及小程序与原生能力之间的交互。

其实现在很多团队都有自己的小程序，只是大部分还运行在微信上。不过新的项目需求出现时，业务团队往往会问：既然页面和功能已经做好了，能不能在自己的 APP 里继续使用？ 从技术角度来看，自有APP也能运行小程序，整体的思路就是：在APP内集成小程序容器，由容器提供代码加载、页面渲染、路由、生命周期和端能力调用等运行环境。原有微信小程序项目无需二次开发，只要有代码，就可以作为业务小程序运行在企业自己的APP中。 小程序代码、运行时与宿主APP的关系 小程序页面能够正常展示和交互，需要小程序代码、运行时与宿主 APP 共同工作。 小程序项目承载页面结构、样式、JavaScript 业务逻辑、组件和网络请求。业务功能如何展示、用户如何操作，大都由小程序项目中的代码决定。 小程序代码无法脱离运行时单独执行。页面创建、路由跳转、存储、网络、权限和原生端通信，都由运行时承接。微信已经把运行时集成在客户端里，因此用户和小程序开发者很少需要关注它的存在。 宿主 APP 提供小程序的运行入口。微信是一种宿主，企业自有 APP 也可以成为宿主。

随着APP流量进入存量竞争时代，现在的APP很少只承载自己开发的功能，今天分享一下如何在自有APP中如何进入第三方服务业态。现在主流的方式就是SDK嵌入、H5页面和小程序三种方式。 SDK 把第三方代码和依赖直接带进客户端工程； H5 主要把网页入口带进 APP，业务页面仍然运行在远程 Web 环境中； 小程序则把业务交付为独立代码包，由 APP 内的小程序容器加载和运行。 接入一个服务时，三种方式都可能很快。接入数量增加、合作关系持续变化以后，架构差异才会逐渐显现。 三种接入方式改变的是业务边界 评估第三方服务时，只比较页面效果并不够。一项完整服务通常包含前端页面、服务端接口、登录状态、设备能力、版本更新和异常处理。它还会不断变化：页面改版、接口升级、权限调整、活动结束，甚至服务方退出。 因此，选型真正要回答的是几个长期问题：第三方代码是否进入 APP 主工程，功能更新是否依赖客户端发版，服务能够调用哪些宿主能力，线上版本由谁控制，故障发生后能否只影响当前服务。 SDK、H5 和小程序没有固定的优劣顺序。它们分别适合不同的集成深度和运营周期。把边界看清楚，

今天分享一个政务 APP 移动门户建设项目，作为一个软件集成商，面对的往往是大量已经运行的系统和页面。很多东西从零开发其实并不难，但现实是：身份、事项中心、预约系统、办件查询和消息平台已经使用多年，多个委办局或业务单位还各自维护着微信小程序。甲方希望把常用服务收进自有 APP，同时保留原有建设投入。 按原生页面重新开发，技术上当然能够完成。但是每项服务都要重新整理页面、路由、登录、接口和异常流程，原来的小程序团队又要与 APP 主工程重新联调。服务数量上来后，主工程会快速吸收多个部门的业务代码，一次普通页面调整也要进入客户端版本计划。 除了软件开发本身，更麻烦的是还要解决多家供应商怎样同时接入，谁能提交代码包，谁负责审核，哪个版本正在线上运行，出现故障时怎样停止新的访问。 调研了几个方案后，最终采用了“稳定宿主+小程序容器+管理平台+现有业务系统”的组合。宿主 APP 管统一入口和端侧公共能力，已有小程序经过兼容检查和必要调整后进入自有 APP，小程序管理平台统一管理资产、版本和上下架。这样原有政务业务系统仍然处理预约、申报、查询和办件数据，

这两年，在内容层面最火的题材就是短剧了，红果APP借助短剧的优势，不到三年日活就已经过亿，而且吸引了一大批黏性极强的用户，而且培养了一大批短剧重视用户。那我们自己的APP是否可以像红果APP一样，通过短剧来提升APP的活跃度，增加流量变现的机会。 短剧内容并不难找到，市场上有大量制作方、版权方和运营机构，资源非常多，但难点出现在接入环节。每引入一家内容方，客户端都要重新开发频道页、剧集详情、播放器、账号连接和付费流程；合作方调整接口，APP 还要跟着发版。内容合作原本需要快速试验，落到原生工程里却变成了持续数周甚至更久的开发项目。 微信、抖音的小程序体系让第三方短剧服务能够按照统一规则进入平台。开发者按照小程序规范提交业务，平台提供运行环境、账号和支付等公共能力，同时负责准入、审核、分发和违规处置。短剧内容来自不同机构，用户看到的入口和使用体验仍然处在同一个平台中。 自有 APP 也可以采用类似的技术思路。在 APP 内集成小程序容器，为第三方短剧小程序提供统一运行环境，再建设一套小程序管理平台，管理内容方、代码版本、宿主关联、审核、灰度和上下架。宿主 APP 保留账号、

随着越来越多华为手机升级到 HarmonyOS 5 及以上的原生鸿蒙系统，也“纯血鸿蒙”，不少省市的政务APP已经开始推进鸿蒙原生适配。 接下来需要考虑的是如何快速完成业务的对接引入，如果预约、查询、申报、政策服务、便民工具都在鸿蒙端重新开发，团队需要重新排建设周期，页面、流程和接口也要再联调一遍。 等到 APP 上线，日常运营还会增加一条发布线。同一项服务调整办理材料或页面规则，相当于一个团队在同时维护iOS、安卓、鸿蒙、微信小程序多个终端，几个客户端分别修改、测试、审核，时间久了，版本差异很容易积累下来。 而且政务APP的变化又比较频繁。政策专区有明确的上线时间，预约服务会调整规则，阶段性活动到期后需要及时撤下，某个办事入口出现异常时还要快速止损。过去依赖原生 APP 发版的方式，在两个客户端上已经有不小的协调成本，再增加鸿蒙端，业务上线节奏会继续受客户端版本牵制。 今天分享一个技术方案，可以将已有的微信小程序项目，通过小程序容器融入到鸿蒙APP中。鸿蒙 APP 可以仍然采用原生方式建设宿主框架，小程序容器负责承载已有的业务页面，小程序管理平台统一管理各项业务的版本、发布范

当AI进入员工日常工作，企业需要管理的已不只是一个聊天入口，而是品牌、插件、智能体、数据、安全与更新。凡泰极客正式发布FinDesk，为企业提供一套可白标、可私有化、可治理，并可持续演进的AI桌面操作系统。 最近几个月，各类AI开始逐步进入员工桌面，企业面临的不再是“能不能用”，而是“敢不敢用”。 * 选用当下通用的、泛化的AI桌面端，数据隐私怎么办？合规治理要求能达到吗？ * 作为一个黑盒子软件，能满足企业专业性定制的需求吗？ * 企业/组织的行业属性、职能的专业性，怎么体现？ * 最关键问题是，企业内部系统和工具，能放心和它们打通吗？ 随着AI编程的不断强化，企业IT只要有源代码，也能利用AI工具进行定制、优化，可是采购回来的大厂软件，企业/组织既没有知识产权、也无法获得源码。 AI时代，业务即代码，代码即业务。源码，是定制的前提，是集成的底气，是数据安全的最后一道闸门，没有它，所谓的企业 AI 入口，

很多APP的运营效率，卡住的地方并不在页面设计，也不在需求排期，而是在“功能已经做好，什么时候才能交到用户手里”。 一个新的会员活动准备周二上线，规则、页面和接口都已完成，但 APP 的下一个版本要到月底才能发布。临近上线，活动入口还要改一次；上线当天，合作方又临时调整了服务时间。业务团队只能继续找客户端团队改配置、重新测试，遇到涉及主包的内容，还得等待应用商店审核。 如果是项目早期，整体功能少，靠群消息、表格和人工确认也能维持。但是随着APP 里逐渐出现会员服务、营销活动、内容专区、问卷、内部工具以及第三方服务，情况会复杂很多：每项业务有不同负责人，上线时间不同，版本节奏不同，能开放的人群也不同。客户端发版通道很快就变成一条拥挤的单行道。 这时需要调整的不只是发布流程，还包括 APP 内业务功能的交付方式。把适合动态运营的功能从主工程中拆出来，以小程序承载，再通过小程序管理平台管理版本、审核、发布、灰度、上下架和运行状态，业务上线便可以从 APP 主包发版中相对独立出来。

现在一个业务同时覆盖 iOS、安卓、鸿蒙和 PC，已经不算少见。客户查询、内容专区、工单处理、员工服务这些功能，在四类客户端里做的事情差不多，背后连接的也是同一套业务系统，但开发时经常会落进四个工程：移动端各写一套，鸿蒙再做适配，PC 端重新处理窗口和键鼠交互。 一两个模块这样做还能推进。业务多起来以后，同步成本会慢慢显出来。后端调整一个字段，几个客户端都要修改；产品新增一个状态，每一端都要补页面、埋点和异常处理；其中一端排期稍晚，用户看到的功能就会不一致。看起来是在维护四个客户端，团队花掉的时间却有很大一部分是在重复同一项业务改动。 小程序多端框架解决的是这类重复建设。页面、路由、表单、接口调用和业务规则保留在一套小程序工程中，iOS、安卓、鸿蒙和 PC 客户端分别接入自己的小程序运行时。系统权限、窗口、进程和设备能力仍由各端处理，上层业务则围绕同一份代码继续迭代。 FinClip 的多端方案也沿着这个思路展开：客户端内集成小程序 SDK，后台管理小程序代码包和版本，各端在自己的运行环境中加载同一项业务。它减少的是业务页面和业务逻辑的重复开发，

其实现在很多团队都有自己的小程序，但这些小程序大部分都是运行在微信上的，今天分享一个新的技术解决方案：借助小程序容器的技术将这些小程序运行在自己的APP里。 特别是商城、预约、会员中心、业务查询，这些服务可能已经在微信里跑了几年，页面和接口都比较成熟，业务人员也已经习惯了小程序的开发和发布方式。 但等企业开始运营自己的APP，就需要看看，如何低成本的把这些服务搬迁到自有的APP中。 一种方案是：直接重写成原生页面，Android和iOS都要投入人力，测试、发版和后续维护也会多出两套工作。换成H5能少写一些界面，但原有小程序的组件、路由、分包和生命周期很难原样搬过来。更麻烦的是，微信小程序还要继续维护。一个需求改动，可能要同时照顾微信、APP原生和H5，业务越多，重复建设越明显。 那还有一个技术方案：在自己的APP里接入小程序容器，让APP先具备运行小程序的能力，再把已有微信小程序迁进来。原来的页面和业务逻辑能复用的继续复用，需要调整的地方集中处理，版本则交给小程序管理平台统一发布。 例如FinClip的小程序管理平台，宿主APP集成小程序运行时SDK，已有小程序代码上传到管理

到了2026年，国内各个行业的APP运营已经从增量市场变成了存量市场，很多APP的用户规模已经逐步稳定下来，从前期的野蛮生长到现在的精细化运行，运营团队也开始会希望加入更多内容和服务：资讯、直播、活动报名、会员权益、票务商城、本地生活、在线预约，甚至合作伙伴提供的专业工具。需求清单很快就能列出几十项，但企业很难把这些服务全部重新开发一遍。 其实不少合作方手里已经有现成的H5页面、微信小程序或原生SDK。单独接入一两个服务时，客户端团队可以逐项处理登录、页面跳转和权限申请，工作量还算可控。但随着接入数量增加后，每家合作方不同的技术栈和上线节奏都会影响宿主APP。一个页面调整可能要重新发版，某个服务出现故障时也缺少统一的关闭和回退手段。 今天方向一个基于小程序技术的解决方案：小程序容器技术可以先在APP内建立统一运行环境，再让第三方业务以小程序代码包的形式接入。例如FinClip 可以通过端侧小程序容器承载业务运行，通过云侧小程序管理平台管理开发者、小程序资产、版本、审核和分发。后续服务沿用同一条接入链路，宿主团队不必为每个合作方重复建设运行、连接和发布机制。 第三方服务如何放进自

很多公司原来只维护 iOS 和 Android 两套客户端，团队之间已经形成了比较稳定的协作方式。但随着要开发鸿蒙客户端之后，同一个需求开始出现三份排期：三端分别设计页面、接入接口、处理权限、联调测试，再各自构建和发布。 很多时候一项查询、预约或会员服务，业务流程没有变化，开发工作却被拆成三条线。产品改一个字段，三个工程都要跟进；某一端进度慢几天，功能就很难同步上线。等版本越来越多，团队还要长期处理页面差异、接口差异和历史版本兼容。 现在市面上有很多跨端开发的技术方案，但更偏向于从零开始构建APP的形式，对于存量APP来说：多端 APP 更实用的做法，是先把业务分层，再为每一层选择合适的技术。账号、安全、消息和系统能力保留在原生宿主；变化较慢、与 APP 生命周期绑定较深的页面，可以继续用原生或现有跨端框架；更新频繁、流程相对独立的业务，则可以通过小程序容器运行。混合架构的价值，也来自这些边界分清以后形成的长期分工。 三端开发中的重复成本 三端重复建设并不只发生在页面开发阶段。一个功能进入原生主工程后，通常会同时进入编译、测试和应用市场发布流程。

大部分APP在运行几年后，主包通常都会一点点变重，可能刚开始只是加一个会员中心，后来又陆续接入商城、客服、活动专区、办事工具和合作方服务。每个需求单独看都不算大，但经过几年之后，图片、组件、第三方依赖和初始化任务全都留在主工程里，安装包体积随之上涨。 包体变大还只是表面现象，更麻烦的是更新，可能一次普通的活动改版，业务侧可能只换了几张图片、调整了两处页面逻辑，客户端团队却要重新拉分支、合并代码、构建安装包、跑集成测试，再等待应用市场审核。改动只发生在一个短期活动里，发布流程却把整套 APP 都带了进来。 图片压缩、无用代码清理和原生模块化当然要做，但它们解决不了业务交付仍然绑在主包里的问题。资源压缩完，新业务还会继续加入；工程模块拆开了，发布时依然要打进同一个安装包。要让 APP 长期保持可维护，除了清理资源，还要重新划分业务的运行和发布边界。 接下来分享一个基于小程序容器的技术方案：是把更新频繁、流程相对完整的业务从主工程拆出，改成小程序代码包，通过小程序容器运行在 APP 内。 宿主 APP 留下稳定的客户端底座，业务团队维护各自的小程序，