不少APP团队原来只维护iOS和安卓两套客户端，协作方式已经比较稳定，现在也需要开发鸿蒙客户端，加入以后，同一项需求开始需要三个团队来实现：三个团队分别做页面、接接口、处理登录和权限，再各自测试、构建和发布。

如果需求是会员查询、活动专区或售后办理，三端背后的业务流程通常没有太大区别。产品改一个字段，三个工程都要跟着修改；接口增加一种状态，三端分别补页面和异常处理；其中一端排期晚几天，功能就很难同时上线。团队表面上在维护三个客户端，很多时间却花在重复实现同一项业务。

小程序容器提供了一种全新的解决方案：iOS、安卓和鸿蒙仍然保留自己的宿主 APP，系统相关能力继续按平台建设；页面、路由、表单、接口调用和业务规则放进一套小程序工程，由三个客户端中的小程序运行时共同承载，大幅度降低二次开发的成本。

重复开发的主要是业务的频繁迭代

iOS、安卓和鸿蒙有各自的应用生命周期、权限模型、导航方式和工程工具。APP 启动、账号安全、消息、支付编排、系统权限以及设备能力，通常都要留在原生宿主中处理。三个客户端分别维护这些底层代码是合理的，因为它们直接连接操作系统，差异无法靠复制一份页面代码消除。

上层业务更容易出现重复。一个订单查询页面，三端做的都是筛选、列表和详情；一项预约服务，三端都要填写信息、选择时间、提交并查看结果；内容专区也离不开栏目、列表、详情和分享入口。过去这些页面跟着客户端主工程分别开发，久而久之便形成三套相似代码，以及三条相互追赶的发布节奏。

采用小程序架构后，宿主APP 继续负责稳定的公共能力，小程序承接更新频繁、流程相对完整的业务。业务团队维护一套页面和规则，客户端团队维护各端运行环境，两边通过约定好的能力接口交换登录凭据、启动参数和处理结果。

如何实现业务与宿主APP解耦

多端复用采用“三套宿主、一份业务”的结构：iOS、安卓和鸿蒙宿主需要分别集成对应的小程序 SDK，完成应用信息配置、初始化、启动入口、页面返回、权限声明和生命周期处理。鸿蒙工程还要按照自身的 Ability、窗口和权限机制完成接入，不能直接照搬另外两端的代码。

以 FinClip 官方集成文档中的最小依赖配置为例，三个宿主工程分别引入对应的核心 SDK。代码只覆盖依赖声明；应用绑定、SDK Key 与 SDK Secret、初始化、权限以及扩展组件仍需按各端工程补齐。

iOS 工程依赖

iOS 可以通过 CocoaPods 引入核心 SDK：

target 'YourApp' do
  pod 'FinApplet'
end

FinApplet 是核心运行依赖。地图、蓝牙、通讯录等扩展能力应根据业务需要单独选择，避免把暂时不用的组件一起放进主工程。依赖写入后执行 pod install 或 pod update，再通过生成的 .xcworkspace 打开工程。

Android 工程依赖

Android 在 App 模块的 Gradle 配置中加入 finapplet：

dependencies {
    implementation 'com.finogeeks.lib:finapplet:x.y.z'
}

x.y.z 需要替换为项目实际使用并完成验证的 SDK 版本。宿主工程还要配置对应的软件仓库，并按照当前版本文档处理动态库打包、混淆及所需的扩展依赖，不能只复制一行 implementation 就直接进入发布构建。

HarmonyOS 工程依赖

HarmonyOS 通过 OHPM 管理依赖，在项目的 oh-package.json5 中加入核心 SDK：

{
  "dependencies": {
    "@finclip/sdk": "latest"
  }
}

官方示例使用 latest。生产工程更适合锁定已经完成联调和回归的具体版本，避免依赖更新后直接改变构建结果。工程还要完成 OHPM 仓库、build-profile.json5、Ability、窗口和权限配置。

容器接入完成后，每个宿主 APP 内都会有一套小程序运行环境。小程序代码面对相对一致的页面、组件、路由、网络和存储接口，运行时再把这些调用落到当前客户端。普通业务页面不需要知道自己运行在 iOS 还是鸿蒙上，平台差异集中在容器和宿主能力层处理，业务仓库也就不必长期堆叠三组平台判断。

登录、扫码、定位、文件选择、支付等能力需要提前形成接口契约。小程序发起“获取登录信息”或“选择文件”一类业务请求，各端宿主调用自己的系统能力，并返回约定好的数据结构。成功、失败、用户取消和权限拒绝都要有统一结果；某个旧版客户端暂不支持时，也应明确返回能力不可用，让小程序提示升级或走备用流程。

业务版本与 APP主包解耦

多端架构前期的工作量主要在宿主底座。三个客户端要完成 SDK 集成，统一小程序入口和导航行为，接好登录态、权限、日志及常用原生能力，还要把宿主版本和能力版本管理起来。这部分稳定以后，后续新增业务通常沿用同一条运行通道，不需要每来一个专区就重新改三套客户端页面。

日常业务更新也会换一条发布链路。小程序开发完成后上传到管理平台，经过体验、审核、灰度和正式发布，已关联的三端宿主就可以取得新的业务版本。页面文案调整、表单字段变化、接口规则修改或活动内容更新，只需要发布小程序，三个 APP 主包不用跟着重新构建，也不必因为一次业务修改再次进入应用市场审核。

新增系统权限、修改宿主自定义 API、升级原生 SDK、调整窗口或应用生命周期，仍然属于客户端改动，需要三端正常发版。小程序能够独立更新的是页面、组件和业务逻辑，无法替代操作系统层面的工程变更。管理平台还应记录小程序版本依赖的最低宿主版本，避免业务已经发布，旧客户端却缺少对应能力。

多端复用仍然需要分别验证

一套业务代码可以减少重复开发，但测试不能只跑一遍。三端运行时最终依赖各自系统的字体、网络、输入法、权限和窗口行为，页面在安全区域、键盘弹起、文件选择、前后台切换等场景中仍可能出现差异。容器提供的是相对一致的运行环境，不会抹掉操作系统本身的区别。

比较实用的测试方式，是建立一条共用业务基线，再补充平台差异清单。登录、路由、接口异常、缓存、上传、版本更新和回退可以共用一套用例；iOS 重点检查系统版本和授权行为，安卓覆盖主要设备与系统差异，鸿蒙检查 Ability 启动、权限以及扩展能力组合。涉及宿主接口的改动，还要同步验证三个客户端返回的数据结构和错误处理。

基于小程序的多端运行架构

小程序容器可以为iOS、Android 和 HarmonyOS 提供对应的小程序 SDK，三个宿主分别完成运行时接入，再通过管理平台关联同一项小程序业务。页面、组件、路由和业务规则集中在一套小程序工程中，宿主 APP 继续管理账号、安全、支付、消息和设备能力。具体 SDK 能力、版本要求和权限配置需要按各端项目逐项核对。

宿主底座搭好以后，业务团队可以通过管理平台上传、审核、灰度、发布、回退和下架小程序版本。三个客户端共用一份业务资产和发布节奏，普通业务更新不再反复推动 APP 主包发版。三端客户端仍然存在，但它们更多是在维护稳定的运行环境；变化频繁的业务回到同一套代码和同一条发布链路中，重复建设也会随之减少。