很多团队的 APP 增加一个业务模块时，需求往往只描述页面、流程和上线时间，很少关心它最终要进入几套客户端。

特别是需要适配鸿蒙APP的时候，原来只需要处理两端的需求，现在变成三个客户端，而且这个成本不只是前期建设的成本，还有长期的迭代维护成本。

虽然很多功能看起来不复杂，重复工作其实不少，特别是很多页面结构要写三遍，接口异常要处理三遍，测试用例也要在三套工程里各跑一轮。哪怕后续只是调整活动规则或增加一个表单字段，仍可能需要等待三个客户端重新构建、提审和发布。只要某一端进度落后，用户看到的功能就会出现差异。

今天分享一个基于小程序容器的跨端开发解决方案，可以将页面、交互和业务流程被整理成一份小程序代码包，iOS、Android 和鸿蒙 APP 分别集成对应的运行时，再从同一个小程序管理平台获取版本。业务团队维护一份代码，客户端团队维护各自的运行环境，版本上传、审核、宿主关联、灰度和回滚则集中到管理平台处理。

这条路径减少的是业务页面的重复建设，端侧工程并不会因此消失。三套操作系统仍有各自的生命周期、权限模型和原生能力，项目要做的，是把共用部分放进小程序，把系统差异留在宿主 APP 内。

跨端架构的代码复用与职责划分

三端共用的内容包括小程序页面、路由、状态管理、表单校验、业务流程和后台接口。代码编译后形成同一个小程序版本，由管理平台保存并分发。订单查询、工单提交、会员服务等业务逻辑只维护一套，产品规则发生变化时，也从这套代码继续迭代。

iOS、Android 和鸿蒙保留各自的原生工程。每个宿主应用都有独立的应用标识、接入凭据和权限配置，并在管理平台中与目标小程序建立关联。客户端启动小程序时，运行时会根据宿主身份和平台配置判断是否允许加载。没有完成关联的 APP，不能直接取得对应的业务代码包。

通过小程序容器技术，可以分为集成在宿主 APP 内的小程序 SDK 负责加载和运行小程序；小程序开放平台负责管理宿主应用、小程序资产和版本关系。开发工具用于编译、预览、兼容检查和代码上传。端、云、工具各自处理一段职责，业务代码不需要直接介入三个原生工程的构建过程。

这个边界确定后，三端方案也就清楚了：同一份小程序业务，分别运行在三套对应的容器环境中。后续接入和测试都沿着这套分工展开。

iOS、Android 与鸿蒙客户端的运行时接入

iOS 客户端需要在原生工程中引入 iOS SDK，配置应用凭据、初始化时机、生命周期和承载小程序的界面。Android 客户端引入 Android SDK，同时处理工程依赖、进程、Activity 生命周期以及宿主页面之间的跳转。鸿蒙客户端则接入 HarmonyOS NEXT SDK，按照项目使用的页面框架注册 Ability 或 Navigation 入口，并配置网络、相机、位置等系统权限。

这些工作看起来仍是三份，但它们集中在容器接入阶段。运行环境搭好以后，新增查询、预约、表单等业务小程序，不必再为每项业务创建三套原生页面。客户端工程更多是在维护通用入口、运行时版本和宿主能力，业务功能通过小程序版本继续演进。

三个客户端通常连接同一个管理环境，却不能共用宿主凭据。小程序标识、业务后台和待发布的代码版本保持一致；应用标识、SDK 接入凭据、权限声明和工程配置则按平台分别管理。把这两类配置混在一份文件里，很容易在发布时把测试凭据带进生产环境，或者让某一端错误地指向另一套宿主配置。

运行时版本也要单独记录。iOS、Android 和鸿蒙 SDK 的发布节奏并不要求完全同步，只比较版本号无法判断三端能力是否一致。一条可追溯的运行基线应包含 APP 版本、平台 SDK 版本、小程序基础库版本和代码包版本。线上出现问题时，团队才能还原出某台设备当时运行的完整组合。

宿主能力接口与平台差异适配

页面能够共用，登录、支付、分享、文件、相机和消息等能力仍然来自操作系统或宿主 APP。若小程序在业务代码中分别判断 iOS、Android 和鸿蒙，再调用三套接口，平台差异很快会渗入每个页面，跨端复用也会逐渐失去意义。

项目侧通常会在小程序与宿主之间建立一组稳定的能力契约。小程序只使用统一的能力名称、输入字段、返回结构和错误码；三套客户端在各自工程中完成实现。

登录流程很能说明这种分工。小程序向宿主申请短时身份凭证，三端都按相同的数据结构返回。凭证在 iOS 安全存储、Android 安全存储或鸿蒙认证体系中怎样取得，由客户端内部处理。小程序拿到凭证后调用同一套业务后台，不关心当前设备运行哪种系统。

支付、文件选择和消息订阅也遵循相同思路。小程序负责提交业务参数和接收结果，宿主负责校验调用来源、拉起本端能力并返回统一状态。支付结果仍以服务端查询为准；文件操作要限制类型、大小和临时目录；消息能力缺失时，应返回明确的“不支持”，让页面隐藏入口或切换备用流程。调用没有实现却一直等待，比直接返回失败更难排查。

页面布局仍要正视端侧差异，只是这些差异不应扩散成三份业务代码。安全区域、状态栏、底部手势区、系统字体、横竖屏、软键盘遮挡和弹窗尺寸都要进入公共样式规范。需要按系统处理的少量行为，集中在适配组件或宿主接口中，业务页面继续使用统一的组件和流程。

三端兼容测试与版本基线

代码共用降低了维护量，却不会替代兼容测试。一个页面在三端都能打开，只能说明基本渲染链路已经接通。前后台切换、系统回收、来电打断、账号变化、网络切换和返回手势，才更容易暴露页面栈、缓存和未完成请求的问题。

项目开始测试前，先把小程序用到的组件和 API 整理成能力矩阵，分为三端直接支持、需要宿主适配、某一端暂不支持三类。FinClip Studio 的兼容性检查可用于定位组件、API 和配置差异，扫描结果还要进入三端真机验证。依赖地图、蓝牙、直播等扩展模块时，扩展 SDK 与平台 SDK 的版本关系也要纳入检查。

公共用例围绕同一个小程序版本执行，覆盖登录、路由、网络请求、文件上传、缓存、支付回调和异常恢复。端侧用例再补充系统授权、前后台切换、返回行为、首次下载、弱网和 APP 升级。iOS 按项目支持的系统版本选取设备，Android 结合系统版本、厂商和内存档位抽样，鸿蒙覆盖声明支持的系统版本与设备形态。设备范围来自实际用户分布，不能只看开发机运行结果。

日志也要服务于三端定位。每条运行记录至少带上平台、系统版本、APP 版本、SDK 版本、基础库版本和小程序版本。同一个问题只在鸿蒙出现时，团队可以很快判断它来自业务代码、运行时差异，还是宿主适配。缺少版本信息的日志，即使数量很多，也很难支持跨端排查。

小程序版本的统一发布与分发管理

三端验证通过后，开发人员通过工具上传小程序代码包，测试人员验证体验版本，审核通过后再生成线上版本。管理平台将同一个小程序关联到 iOS、Android 和鸿蒙宿主，三个客户端按照发布策略获取代码包。这样发布后，三端拿到的是同一个线上版本，业务更新不必等待三套 APP 同时通过应用市场审核。

影响范围较大的改动可以先灰度，观察接口错误、页面异常和业务完成情况，再逐步扩大分发范围。新版本出现故障时，平台停止灰度、回滚到稳定版本，或者暂时下架对应小程序。发布记录、审核记录和版本关系都留在同一个平台中，三端出现差异时也有统一的版本依据。

发布时还要分清两类改动。页面、流程和小程序业务逻辑的修改通常通过管理平台更新；SDK 升级、原生接口调整、权限增加和宿主页面改动，仍要进入对应客户端的构建与应用市场流程。若一次需求同时包含两类变更，项目计划应拆成小程序版本和宿主 APP 版本，避免小程序已经上线，所需的原生能力却还没有进入用户设备。

管理平台还负责控制分发对象。内部工单小程序只关联员工 APP，面向客户的服务小程序则关联对应的 iOS、Android 和鸿蒙应用。宿主身份、接入凭据和小程序关联共同限定加载范围，业务代码不会因为放到统一平台就自动对所有 APP 开放。

跨端方案的试点实施与能力复用

试点可以从查询、预约、表单或内容服务等设备依赖较少的模块起步。需要跑通的是整条链路，从 SDK 集成、宿主关联、登录凭证、代码上传、三端验证，一直延伸到灰度和回滚。

这一轮会留下三类结果：小程序源码需要调整的兼容点、三个宿主接口的实现差异、经过验证的运行时版本组合。通用能力沉淀到宿主接口层，系统差异留在对应客户端，业务页面中的临时判断则在试点结束前清理掉。

等到下一个小程序接入，客户端无需重新搭建运行环境，只需补充业务所需的权限和宿主能力，再完成兼容检查与发布配置。活动规则、表单字段或服务流程发生变化时，改动也会更多地集中在同一份小程序代码和一个发布版本上。

到了第二、第三个小程序接入时，团队不再重复搭建三套业务页面。小程序继续承载可复用的业务，宿主 APP 处理系统差异，管理平台维持版本与分发秩序。iOS、Android 和鸿蒙各自保留原生工程，又能长期运行同一套业务版本，这才是小程序容器在多端架构中的实际作用。