随着越来越多华为手机升级到 HarmonyOS 5 及以上的原生鸿蒙系统也“纯血鸿蒙”不少省市的政务APP已经开始推进鸿蒙原生适配。接下来需要考虑的是如何快速完成业务的对接引入如果预约、查询、申报、政策服务、便民工具都在鸿蒙端重新开发团队需要重新排建设周期页面、流程和接口也要再联调一遍。等到 APP 上线日常运营还会增加一条发布线。同一项服务调整办理材料或页面规则相当于一个团队在同时维护iOS、安卓、鸿蒙、微信小程序多个终端几个客户端分别修改、测试、审核时间久了版本差异很容易积累下来。而且政务APP的变化又比较频繁。政策专区有明确的上线时间预约服务会调整规则阶段性活动到期后需要及时撤下某个办事入口出现异常时还要快速止损。过去依赖原生 APP 发版的方式在两个客户端上已经有不小的协调成本再增加鸿蒙端业务上线节奏会继续受客户端版本牵制。今天分享一个技术方案可以将已有的微信小程序项目通过小程序容器融入到鸿蒙APP中。鸿蒙 APP 可以仍然采用原生方式建设宿主框架小程序容器负责承载已有的业务页面小程序管理平台统一管理各项业务的版本、发布范围和运行状态。已经在线运行的业务资源得以继续使用iOS、Android、鸿蒙三端也能逐步回到同一套业务运营体系中。从一次性开发投入到长期运营投入完成一次鸿蒙客户端开发只解决了应用能否安装和运行的问题。政务服务上线后的持续维护往往比首个版本更考验团队。一个政务 APP 里可能有几十项甚至更多服务。它们来自不同部门由不同供应商维护更新频率也不一样。有的服务一年只调整几次有的活动专区可能一周内连续改版。若全部与宿主 APP 一起打包每次调整都要经历客户端构建、集成测试、应用审核和用户升级。业务部门已经确认的页面常常还要等待下一个 APP 版本窗口。按客户端分别发版也会增加多端协作的压力。iOS、Android、鸿蒙各自有开发计划和版本进度同一项服务很难保证在同一天更新。临时下架一个入口时团队还要确认三个客户端分别使用了哪个版本、旧入口是否仍然可见、没有升级的用户会看到什么。因此鸿蒙适配需要同时解决两件事宿主 APP 怎样适配新的系统业务服务怎样在新的终端上持续上线和运营。前者属于原生工程建设后者可以通过小程序容器和管理平台重新组织。存量业务的如何快速引入政务项目已经积累了不少可继续使用的资源。统一身份、事项系统、预约系统、办件查询、内容平台和数据分析系统仍然运行在服务端鸿蒙 APP 没有必要再建设一套后台。iOS 和 Android 项目中的导航关系、安全规则、接口约定和测试口径也可以延续到新的宿主工程中。已有微信小程序更接近可以直接迁移的业务载体。页面、路由、表单、组件、网络请求和大部分业务流程经过兼容检查及必要调整后可以作为独立小程序运行在自有 APP 中。团队不必把每一项服务都改写成鸿蒙原生页面也不需要为鸿蒙端复制一份业务后台。复用仍然有边界。依赖微信登录、微信支付、订阅消息、平台插件或云开发的功能需要改接政务 APP 的账号体系和已有业务服务定位、扫码、相册、文件选择等端能力也要按照鸿蒙宿主的权限和能力范围完成验证。小程序容器减少了业务页面和流程的重复开发原有小程序仍需经过兼容检查和端侧验证才能上线。业务迁入后小程序也不再只是一个代码包。每个小程序都需要有清晰的业务名称、责任部门、维护人员、当前版本、适用宿主和上线状态。后续运营能否顺畅很大程度上取决于业务和版本信息能否进入统一的平台管理。宿主、容器与管理平台的架构关系鸿蒙宿主 APP 继续负责用户进入应用后的整体体验包括首页框架、统一登录、原生导航、消息、安全控制、系统权限和必要的设备能力。它保持相对稳定不需要跟随每个业务页面的调整频繁发版。小程序容器集成在宿主 APP 内为预约、查询、申报、政策专区等业务小程序提供加载和运行环境。用户点击服务入口后宿主把目标小程序和页面参数交给容器容器根据已发布版本打开页面再访问原有业务系统完成查询或办理。账号凭据、系统权限和敏感能力仍由宿主按照项目规则提供。小程序管理平台位于服务端管理小程序资产及其运行策略。平台记录一个小程序属于哪个业务、可以运行在哪些宿主中、当前线上版本是什么、哪些人可以提交和审核以及变更何时发生。它还负责体验、审核、灰度、正式发布、回退和下架等版本动作。原有政务业务系统继续保存权威业务数据。预约是否成功、材料是否提交、办件走到哪个环节仍由对应系统判断。管理平台控制的是小程序版本和运行范围不会替代事项、订单、支付或身份系统。四部分各自承担稳定的职责鸿蒙适配便不再等同于把所有服务重新写进一个原生工程。宿主解决端侧接入容器承接业务运行管理平台控制上线过程业务系统处理实际交易和数据。小程序资产的如何实现统一管理小程序数量少时团队可以用文件名和聊天记录确认版本。服务增加以后仅凭文件名和聊天记录很难回答几个基本问题当前线上运行的是哪个包谁提交了版本修改哪个部门已经审核哪些客户端能够打开出现问题后应该回到哪个版本。小程序管理平台把业务资料、版本记录和宿主关系放到同一个控制面中。每项业务都有独立的小程序标识和版本记录并与对应的 iOS、Android、鸿蒙宿主建立关联。开发团队或供应商提交新版本后可以先进入体验状态由业务、测试和安全人员在指定环境检查审核通过后再按照发布策略进入线上。权限也需要跟着业务责任划分。供应商可以提交自己维护的小程序业务部门确认页面和办理规则平台管理员控制宿主关联与正式发布。每次提交、审核、发布、回退和下架都留下操作记录。遇到投诉或线上故障时团队可以沿着版本和操作记录找到对应变更不必在多个群聊中追溯文件来源。讨论“某项服务是否在线”时各方看到的是同一份平台状态。小程序管理平台除了保存代码包还会把分散在不同部门、供应商和客户端之间的发布关系整理成可查看、可审批、可追溯的业务资产。上线、灰度、回退与下架小程序版本通过审核后可以先开放给指定范围验证再逐步扩大。实际项目可以结合平台能力和现有用户分组按照宿主应用、客户端版本或既定发布策略控制范围。鸿蒙端可以先验证新版本iOS 和 Android 继续使用已确认版本三端验证完成后再统一切换。小程序版本发布不需要等待整个鸿蒙 APP 重新上架。政策内容、预约流程、表单字段和普通页面调整可以通过小程序版本独立更新。涉及新增系统权限、修改宿主账号能力、升级原生 SDK 或调整主导航的变化仍然需要进入客户端发版。两条发布通道分开后业务更新不会全部挤到主工程里原生变更也不会被误当作小程序版本能够解决的问题。线上异常出现时平台可以停止继续放量或者将小程序回退到已验证版本。若某项服务需要暂停管理人员可以执行下架并同步调整 APP 内的入口和提示。已经进入办理流程的用户如何处理仍要由业务系统根据事项状态决定不能只靠关闭页面解决。回退与下架也有不同用途。回退用于恢复可用版本用户仍然可以办理下架用于停止新的访问常见于活动结束、政策调整或风险处置。把两种动作分清楚运营人员才能在紧急情况下选择合适的处理方式。一套代码多端业务的统一分发当 iOS、Android 和鸿蒙客户端都接入小程序容器后同一项业务可以维护一份小程序代码和一套版本资产。页面调整经过一次业务确认再分别完成各端运行验证发布平台按照宿主关系把版本分发到对应客户端。统一分发并不会抹平系统差异。三个客户端仍要维护各自的小程序运行时、系统权限和宿主能力旧版 APP 可能也不具备新小程序所需的能力。管理平台需要记录小程序版本与宿主版本的适配关系遇到客户端版本过低时可以限制发布范围、提示用户升级或者打开已经准备好的兼容页面。业务更新的组织方式也随之发生变化。以前同一项服务可能分成三个原生需求现在业务页面和流程集中在小程序中维护各端团队把精力放在宿主稳定性和平台差异上。小程序版本只有一份来源三端何时启用、覆盖哪些用户则由管理平台控制。运行数据与业务数据的衔接业务上线以后运营团队需要知道小程序是否被正常打开、哪些版本仍在运行、不同系统上的访问情况怎样。根据实际部署版本和统计配置小程序管理平台可以提供打开次数、活跃设备、停留时长、版本分布、操作系统或运行环境等数据帮助团队发现某个版本覆盖不足或某一端出现集中异常。部分数据会有统计延迟不能直接当作实时告警使用。办件量、预约成功率、材料提交结果和支付状态属于业务数据仍然保存在政务业务系统或既有数据平台中。小程序管理平台没有必要重复建设同类指标。实际分析时可以通过小程序标识、版本、宿主应用和业务服务标识把运行数据与业务结果关联起来。例如某次预约流程更新后管理平台显示鸿蒙端新版本已经覆盖但预约成功率没有同步变化团队可以继续检查业务接口和办理规则如果新版本打开量很低则要回到入口配置、宿主版本或发布范围中排查。运行数据和业务数据各自说明一部分情况放在一起才有助于判断问题发生在哪一层。有哪些现成的解决方案例如 FinClip小程序容器可以集成到鸿蒙原生宿主中负责业务小程序的加载、运行和端内交互FinClip 小程序管理平台负责小程序资产、宿主关联、版本审核和发布过程。已有微信小程序可以先进行兼容检查再根据账号、渠道能力和鸿蒙端能力完成必要调整。对于政策查询、事项指南、预约办理、进度查询、便民工具、意见反馈和阶段性专区等业务原有页面与流程具备较高的复用空间。统一身份、实名认证、电子签名、支付编排、安全控制和复杂设备能力继续由政务 APP 与业务系统承担。明确的责任划分既保留原生鸿蒙宿主的稳定性也让高频变化的服务拥有独立的上线节奏。政务 APP 适配原生鸿蒙后iOS、Android 和鸿蒙可以共用一批小程序业务资源并通过同一个管理平台维护版本和运行状态。业务部门能够更快安排服务上线、灰度、回退与下架技术团队也能减少多端页面的重复建设。对已经拥有微信小程序和成熟后台的项目来说FinClip 小程序容器可以把业务复用、多端运行和后台治理连接起来支撑存量政务服务在多个客户端中持续更新和统一运营。