多业务 Cocos 接入鸿蒙方案

状态：架构咨询稿，非已完成实现。本文用“业务 A / 业务 B”和示例 gameId 描述模式，不包含实际产品、仓库、包名、接口地址或本机路径。

1. 结论

建议沿用 Android 宿主的总体模型：一个共享 Cocos 引擎宿主，通过 gameId 启动不同业务。鸿蒙侧拟提供一个 cocos_har，由应用 HAP 接入；业务源码可以分仓维护，但应进入同一个 Cocos 集成工程统一构建，形成两个业务 Bundle。

这里的“一个 HAR”指统一交付边界，不意味着把两份原始源码直接放进 HAR。HAR 交付的是鸿蒙原生运行时、宿主接口以及构建后的业务资源；业务资源是否全部内置，仍需根据包体和更新策略决策。

2. 已确认事实与方案假设

Android 的“共享引擎 + gameId 路由”可以复用为跨端接口思想；Android 的 AAR、Activity、Surface 生命周期实现不能直接搬到鸿蒙。鸿蒙需实现自己的 XComponent、NAPI 和页面生命周期适配。

3. 目标架构

运行时由 HAP 调用统一接口，例如 openGame(gameId, source, params, user)。容器按 gameId 选择业务 Bundle，保持一个引擎实例和统一桥接协议。game_a、game_b 仅为文档示例，不是实际标识。

HAP / ArkUI
  └─ cocos_har：共享引擎、渲染视图、生命周期、桥接、业务路由
       ├─ game_a → Bundle A（可常驻）
       └─ game_b → Bundle B（可按需加载）

业务 A 常驻、业务 B 退出释放，是一种可选内存策略；它与“共享引擎”不是同一个决策。Android 宿主代码有会话保留逻辑，因此鸿蒙是否完全照搬退出/恢复行为，须在内存预算与产品体验确认后定稿。

4. 各层职责

5. 落地前置条件

1. 业务侧兼容：两份业务的 Cocos 版本、资源格式、脚本依赖和原生能力清单与集成壳一致；同步必须包含 .meta，以保留资源 UUID。
2. 桥接契约：统一 gameId、启动参数、登录态、关闭回调、错误回传及原生能力接口；各业务避免私自定义互相冲突的全局事件和资源名。
3. 鸿蒙原生可行性 POC：验证 XComponent 创建与页面切换、Surface 重建/重绑、NAPI 双向消息、前后台恢复和异常退出。
4. 单工程构建：集成壳同时产出两个 Bundle；构建信息应记录业务源码版本、引擎版本及资源版本。独立业务仓库不分别产出可直接拼装的含脚本 Bundle，除非另有跨工程构建验证结果。
5. HAR 交付链：Cocos 构建产物和鸿蒙原生工程不是现成 HAR；仍需定义 DevEco 编译、HAR 封装、制品发布、HAP 集成及应用签名流程。

业务适配、鸿蒙容器 POC 和宿主接口定义可以并行；最终双业务 HAR 出包必须等这些接口与构建输入收敛后再验收。

6. 推荐实施顺序

最小验收集：业务 A/B 均可从 HAP 直接打开；切换后输入和音频不串业务；退后台再回来正常；业务 B 连续打开/关闭无持续内存增长；缺包、版本不匹配及桥接失败均能明确报错。

7. 待确认决策

• Bundle 是随 HAR 内置，还是由 HAR 按 gameId 下载并校验？建议首个 POC 内置，远程交付另立版本与安全方案。
• 业务 B 关闭后释放资源还是保留会话？业务 A 隐藏时是否继续执行定时器、动画和音频？
• HAP 页面切换时复用同一 XComponent，还是重建页面后重绑 Surface？以真机 POC 结果决定。
• 业务脚本更新是否只能在下次冷启动生效？更新、回滚和旧资源清理的边界是什么？
• HAR 与业务 Bundle 的版本、包体和内存预算由谁发布和验收？

8. 预计受影响范围

• 场景：集成壳启动场景；业务 A/B 的入口场景。
• 脚本：业务路由、Bundle 加载/卸载、桥接、生命周期和资源清理模块。
• 资源：两份业务 Bundle、.meta、构建清单及版本信息。
• 扩展/原生层：鸿蒙原生插件、XComponent、NAPI、HAR 打包与 HAP 接入配置。

本文是脱敏的目标方案，不替代实际 SDK 工程审查、鸿蒙真机 POC 或发布产线验收。