应用上架与分发
一、引言
上一篇文章完成了签名与打包，本文继续回答"打包之后怎么办"：如何把四个 HAP 送到不同设备用户手中。multi-short-video 没有真实的服务端与账号体系，但它的多 HAP 结构恰好是理解 HarmonyOS 应用上架与分发机制的绝佳样本——一个应用、四种设备、四份产物、一套发布策略。上架不是简单地把包传到后台点"发布"，它涉及应用信息维护、版本号规划、审核合规、渠道选择、灰度与回滚等一系列决策，任何一个环节处理不当，都可能造成审核驳回、用户流失甚至线上事故。本文结合 AGC 平台流程，给出从应用创建、版本管理、审核到多渠道分发与灰度回滚的完整路径。
二、AGC 应用创建与基础配置
分发第一步是在 AppGallery Connect 创建应用。登录 AGC 控制台后选择"我的应用 → 新建应用"，关键配置项如下：
| 配置项 | 本工程建议值 | 说明 |
| 应用包名 | com.example.multishortvideo | 必须与AppScope/app.json5中 bundleName 一致 |
| 应用名称 | 多设备短视频 | 与AppScope/resources/base/element/string.json中 app_name 保持一致 |
| 应用分类 | 影音娱乐 | 影响应用市场类目与推荐位 |
| 语言 | 中文（简体） | 可多选，对应工程内 zh_CN/en_US 资源 |
| 发布国家/地区 | 中国 | 影响合规审核要求 |
这里最容易踩的坑是包名不一致：AGC 上创建的应用包名必须与工程AppScope/app.json5的bundleName完全一致，且后续不可修改（或修改成本极高），一旦发现填写错误，只能删除重建应用或申请修改。因此创建前务必先在工程里确认 bundleName，再动手建应用。
创建完成后需要维护应用的基础信息：图标（对应工程中AppScope/resources/base/media下的 layered_image 分层图标，注意图标需要 512x512 且不能带圆角，由系统统一裁切）、截图（真机截取的横竖屏截图，建议包含关键页面）、隐私政策链接与联系方式。对于多设备应用，还需按设备类型分别上传对应 HAP 的说明与截图——直板机截图体现竖屏沉浸播放，平板与电脑截图体现分栏布局，智慧屏截图体现焦点导航，手表截图体现精简交互，四类截图素材可在工程screenshots/device目录基础上加工。截图规范也要留意：不同设备类型对截图尺寸、数量有不同要求，上传前对照 AGC 的说明逐项核对，避免因截图不合格被驳回。
三、版本管理与发布策略
上架前先规划版本号。HarmonyOS 版本号体系由versionCode与versionName组成，本工程定义如下：
// d:\HarmonyOS\WorkSpace\multi-short-video\AppScope\app.json5 { "app": { "bundleName": "com.example.multishortvideo", "vendor": "example", "versionCode": 1000000, "versionName": "1.0.0", "buildVersion": "1" } }versionCode是递增整数，仅用于系统比较大小（同一应用安装时后者必须更大）；versionName是面向用户的展示版本。多 HAP 场景下，四个 HAP 的 versionCode 必须完全一致，否则按设备安装时系统会因版本不一致而拒绝更新。本工程 versionCode 使用"1,000,000"这种大整数写法，是给后续迭代留足余量（如 1.0.0 → 1000000、1.0.1 → 1000001），避免小步迭代很快撞上 2^31 上限或出现"版本号回退"的乌龙。
建议版本策略为：
- 主版本迭代（1.0.0 → 1.1.0）：新增功能，四个 HAP 同步发布；
- 补丁版本（1.1.0 → 1.1.1）：修复缺陷，同步更新；
- 分设备独立小版本：仅在确有差异时使用，例如 TV 端单独修 Bug，可只上传 TV 的新版本 HAP，但 versionCode 必须高于所有设备上已安装的版本。
在 AGC"版本管理"页面上传 HAP 后，需填写版本更新说明（建议按设备形态分别撰写，突出该设备的体验改进），并选择发布阶段：内测（Beta）、正式（Production）、灰度（分批放量）。正式发布默认全量；灰度发布则按比例放量，常用于验证新版本在特定设备上的稳定性。需要特别提醒的是：上传到 AGC 的 HAP 必须是使用发布证书签名的包，调试证书签名的包在正式环境会安装失败，这是提审时最高频的返工原因之一。
四、应用审核要点
华为应用市场对应用进行自动化与人工双重审核，多设备应用重点核查以下方面：
- 权限合规：逐项说明权限用途。本工程
module.json5中声明的ohos.permission.DETECT_GESTURE属于受限权限，审核时需提供使用场景说明；若不需要应在上架包中移除。 - 内容合规：短视频应用需审核示例视频素材的版权与内容导向。本工程 rawfile 中的
9_16.mp4、16_9.mp4等均为演示素材，正式商用必须替换为自有版权内容，且应说明视频内容的管理与举报机制。 - 隐私政策：应用内需提供可访问的隐私政策链接；若应用有网络能力（本工程无 INTERNET 权限则无需网络隐私声明），需补充数据收集说明，并做到"声明什么就收集什么"。
- 多设备适配：审核方会抽样在手机与平板真机安装验证，需确保关键页面（推荐流、评论、个人作品页）无布局错乱、无黑屏、无功能缺失。
- 版本一致性：四份 HAP 的 versionCode 一致、签名证书一致、应用图标与名称一致。
ic_user01.png等）替换为合规素材，否则即使代码质量再高也会卡在内容审核。五、多渠道分发与灰度回滚
除华为应用市场外，还可通过以下渠道分发：
| 渠道 | 适用场景 | 特点 |
| 华为应用市场（正式上架） | 面向公众 | 覆盖广、需审核、可灰度 |
| 应用市场内测/众测 | 小范围验证 | 需审核但放量可控 |
| 企业分发（AppGallery Connect 企业证书） | 企业内网员工 | 免应用市场审核，需企业实名认证 |
| 本地安装（hdc install） | 开发调试 | 不受渠道限制，仅用于测试机 |
企业分发是 B 端场景的重要补充：使用企业证书签名的 HAP 可以绕过应用市场审核直接安装，适合政府、企业内部使用，但企业证书的申请要求更高（需要企业资质认证），且不能在未注册设备上安装，适用于"设备白名单"场景。若产品面向大众消费者，正规路径仍是应用市场。
灰度与回滚是线上发布的安全网。推荐"金丝雀"策略：先放量 1%～5% 用户，监控崩溃率与关键指标（启动失败率、播放失败率），无异常再逐步放量至 100%。回滚手段有两级：一是 AGC 控制台将版本下线，已安装用户不受影响；二是通过推送高版本修复包覆盖，因此务必保证versionCode单调递增，为回滚后的修复版本留出空间。灰度期间要重点观察分设备指标——本工程四类设备硬件差异大，手机端表现正常的版本在手表端可能因内存不足而频繁被杀，灰度监控必须按 deviceType 维度拆分统计。
灰度放量的节奏建议分三档：1%（探路，重点看崩溃与安装失败率）→ 10%（功能验证，看核心链路漏斗）→ 50%（稳定性验证，看性能与耗电），每一档停留 24～48 小时并输出一份分设备数据对比。放量期间 AGC 会自动收集崩溃栈与性能数据，务必在后台配置崩溃告警阈值（如单设备类型崩溃率 > 0.5% 即暂停放量），避免问题版本在放量窗口内扩大影响面。
发布只是起点，上线后的数据回收同样重要。建议在首个版本就埋好三类基础事件：安装事件（区分 HAP 类型，验证四端安装是否符合预期）、启动事件（含启动耗时，建立性能基线）、核心功能事件（视频起播成功率、评论打开率、作品页跳转成功率）。没有这些基线数据，后续每次发布的灰度判断都只能靠"感觉"，无法量化。对示例工程而言，至少要把日志体系（common/multishortvideobase/src/main/ets/utils/Logger.ets）中的关键路径日志与上报通道打通，为灰度决策提供依据。
六、上架前自查清单
| 检查项 | 本工程对应 | 状态 |
| 包名、签名与 AGC 配置一致 | AppScope/app.json5 + 发布证书 | 必查 |
| 四 HAP versionCode 一致 | 各产品模块产物 | 必查 |
| 权限最小化、受限权限已说明 | module.json5 requestPermissions | 必查 |
| 图标、截图、隐私政策齐备 | resources/base/media + 截图 | 必查 |
| 演示素材版权确认 | resources/rawfile/*.mp4 | 必查 |
| 深色模式、多语言资源完整 | dark / zh_CN / en_US 目录 | 建议 |
| 发布说明按设备撰写 | AGC 版本管理 | 建议 |
| 崩溃率/启动耗时基线已建立 | 线上监控 | 建议 |
自查清单建议沉淀为团队模板，并在每次提审前由发布负责人逐项打勾。示例工程中尤其要注意前四项：包名一致性、四端版本一致、受限权限说明、素材版权，这四项占了多设备应用驳回原因的大头。
七、总结与最佳实践
上架与分发是把工程能力转化为用户价值的最后一步，多设备应用尤其要警惕"版本碎片化"。核心经验：一份签名、一套版本、四份产物、统一节奏。签名与包名全局唯一，versionCode 全局单调递增并四端同步，HAP 按 deviceTypes 各归其位，发布节奏以设备形态为维度进行灰度与回滚。此外，把上架自查清单沉淀为 CI 检查脚本（自动比对四端 versionCode、自动校验签名指纹），能显著降低"临上架发现权限没删、截图没传"的返工成本。对示例项目而言，正式商用前务必替换演示视频与图标素材，完成隐私合规评审，再进入 AGC 提审流程——记住，审核驳回一次，迭代周期就拉长一周，前置自查永远比事后补救划算。
