本节目标

  • 掌握 HarmonyOS 应用上架审核的核心规范，能够提前规避高频驳回问题
  • 掌握 AGC 云测试与 DevEco Testing 自检工具的使用，能够在提交审核前完成自动化质量检测
  • 掌握 AppGallery 增长引擎与 Push 用户增长服务的核心能力，能够为应用建立用户增长策略
  • 掌握 HAR/HSP/HAP 的组件化架构演进策略，能够合理规划模块拆分粒度
  • 掌握 AGC Publishing API 与 Testing API 的自动化上架流程，能够将上架集成到 CI/CD 流水线
  • 能够为应用建立从代码提交→自动构建→云测试→上架审核→运营增长的完整工程化闭环

一、上架审核规范与高频驳回问题

1.1 审核机制与周期

华为应用市场对应用审核实行机器+人工双检机制。正式版本审核一般在 1-3 个工作日完成，多数应用会在 24 小时内完成审核。HarmonyOS 沿用双证书模型，但 NEXT 版本新增应用指纹绑定，任何改动都必须重签名。

审核前需要准备的材料：

  • 图标、截图、介绍、隐私政策
  • 资质材料、APP 核准（备案）
  • 如需使用 ACL 权限，需先申请 ACL 权限再创建 Profile

1.2 应用信息违规 TOP 问题

TOP 1：应用信息与实际应用功能不符

开发者优化、新增、删减应用功能后，需核对应用素材信息（应用介绍、一句话简介、新版本特性、应用截图和视频、应用分类及标签等）与实际功能一致。例如应用截图中含有“智能 AI”模块但应用内并未搭载此功能，会被驳回。

TOP 2：应用截图不符合规范

应用截图中不得出现三方信息元素、不当内容或尺寸格式错误。2026 年 1 月 7 日起在 AGC 提交应用时，应用截图需满足新规要求。

TOP 3：应用名称广义不具辨识性

应用名称不得为广义归纳类、普遍且不具有识别性的词汇，包括但不限于使用商标术语、热门应用名称或别称、流行词、行业名词、职业名词、类别词、功能性描述的词汇。例如“手机计算器”“天气预报”“手机定位”等名称会被驳回。

TOP 4：应用分类及标签与实际功能不符

含游戏玩法却选择应用分类上架会被驳回，游戏不得以应用分类上架。

TOP 5：用户权益类问题

应用需注册登录才能使用但未提供注册通道或未提供可用的测试账号，会被驳回。需要在提交审核信息填写页面的“版本信息 > 应用审核信息”处正确填写可直接登录的测试账号用户名和密码。

1.3 应用价值 3.5 条款

3.5 条款是审核中高频驳回的条款，核心关注“应用价值与独特性”。

不收录的应用类型：

  • 功能与手机系统自带功能重复且缺乏独特价值的应用（如简易计算器、桌面时钟、加密备忘录等）
  • 有限的信息内容罗列（如信息介绍、生活指南、法律案例展示、书籍推荐等）
  • 单一界面的恶作剧恶搞类应用（如屏幕破裂、模拟打嗝等）
  • 单一 H5/Web 页面应用（如一张图片、一首音乐等）
  • 企业黄页类应用（仅展示文字信息不提供用户服务）
  • 应用内容均为广告推广
  • 页面仅提供简单预约功能但未体现实质价值

改进路径：

  • 明确应用的独特价值，确保核心功能与系统功能非完全重叠
  • 从纯展示向强交互演进，构建复合型功能体系
  • 深化内容价值，丰富交互场景与功能闭环

二、云测试与自检工具

2.1 AGC 云测试

AGC 提供云测试服务，可在云端对应用进行兼容性、稳定性、性能、功耗、UX、隐私等自动化检测，获取检测报告，提前定位修改问题。操作路径为：AppGallery Connect → 应用上架 → 软件包管理 → 点击软件包“操作”列的“启动自检”。

2.2 DevEco Testing 上架预检

DevEco Testing 提供本地上架预检测试能力，包括：

  • 应用上架预检（自动化测试） ：自动化执行上架前的合规检查
  • 性能基础质量测试：检测启动时延、页面切换、内存占用等指标
  • UX 基础质量测试：检测布局适配、交互响应等用户体验指标
  • 场景化性能测试：针对特定业务场景的性能测试

使用流程：DevEco Testing 客户端 → 准备测试设备 → 连接设备并开始测试 → 关注和跟踪测试任务 → 查收测试报告。

2.3 上架自检流程

提交审核前推荐完成以下自检流程：

  1. 软件包合法性检测（必选） ：检查包名、签名、版本号等基本信息
  2. 上架自检（推荐，云端测试） ：AGC 云测试进行全面检测
  3. 本地 DevEco Testing 预检：针对性能、UX、稳定性进行本地验证

AGC 页面逐项填写：应用基础信息、发布区域、应用内资费及商品、隐私相关信息、AI 功能声明、资质材料、APP 核准（备案）、联系信息、上架时间等。

三、AppGallery 运营增长工具

3.1 AppGallery 增长引擎

AppGallery 增长引擎包含预约发布、精选提名、搜索优化、评论评分管理、数据服务等，有效帮助应用提升曝光度和交易成功率。

应用归因服务能提供下载来源、拉活来源、归因来源三类结果查询，有效替代物理分包，实现系统级风控及 100% 准确的无 ID 归因匹配。

3.2 Push 用户增长服务

Push 用户增长平台基于智能大数据分析、华为消息推送中台和 PushKit 客户端构建了端、管、云、数相结合的用户增长平台，通过广泛的设备触达、精准的人群圈选、丰富的内容样式、智能的展示时机，助力开发者应用用户增长。

五大核心能力：

目标设定：支持沉默唤醒和促激活，面向两种不同的场景的推广目标。

人群圈选：支持标签人群圈定、私有人群上传、自定义人群直投和 RTA 筛选。

文案创意：支持文本、图片、按钮基本样式，支持文案 AB，支持自定义小图标、背景图、自定义标题颜色等高级样式。

呈现时机：支持定义消息呈现的时机，立即显示、下拉通知栏显示、亮屏显示。

效果归因：支持效果统计分析，点击回执上报。

3.3 搜索优化（ASO）实践

应用名称：包含核心关键词，但不得堆砌。例如“极简待办 - 高效任务管理”比“待办清单待办事项任务管理”更规范。

副标题与简介：在前三行内突出核心卖点和差异化优势。

关键词：在应用信息中自然融入用户可能搜索的关键词，如“待办”“清单”“任务”“提醒”“效率”。

评分与评论：积极引导满意用户评分，及时回复差评并解决问题。评分 4.5 分以上的应用在搜索结果中排名更靠前。

下载量与活跃度：下载量和活跃度是搜索排名的重要因素，通过持续运营提升这两个指标。

四、工程化模块拆分策略

4.1 HAR/HSP/HAP 的选型原则

类型定位适用场景包体积影响编译影响
HAR静态共享包基础 UI 组件、工具层、网络层、埋点层随依赖方打包，多副本增量编译，边界简单
HSP动态共享包多 HAP 共享稳定公共能力、大资源或 native 库运行时复用，单副本编译耗时增加
多 HAP独立模块独立大业务、按需分发、不同设备/市场按需分发独立编译

选型原则：

HAR：优先用于业务内静态复用。比如基础 UI 组件、业务领域组件、工具层、网络层、埋点层、页面内可复用能力等。HAR 会随依赖方一起编译/打包，边界简单，调试成本低，适合大多数模块化拆分。

HSP：只有在确实需要运行时共享代码/资源时再上。比如多个 HAP 都要共享同一套稳定公共能力、较大的公共资源或 native 库。HSP 的问题是版本依赖、调试和发布联动会变复杂，适合放稳定的基础能力，并且要控制公开 API。

多 HAP：主要用于真正独立的大业务或按需分发场景。比如某个功能体积较大、低频使用、可以独立路由/入口/资源管理，或者不同设备/市场只分发部分功能。普通中小项目不要为了“架构好看”上多 HAP。

4.2 模块拆分粒度建议

40+ HAR 项目可以按团队/业务域分组，保留 10 到 20 个左右清晰边界的模块通常更容易维护和构建。如果很多 HAR 只是一个页面或几个工具类，通常拆得过细了。可以把高内聚的小模块合并成“领域包”，例如 account、payment、content、common-ui，而不是一屏一个 HAR。

4.3 构建优化方向

  • 让依赖方向单向、分层，避免 A/B/C 互相依赖或公共模块频繁改动导致大面积重编。
  • 把稳定基础能力放底层，业务模块只依赖接口或 facade，不直接依赖大量实现细节。
  • 对资源、native 库、三方库做集中治理，避免每个 HAR 重复携带或重复初始化。

五、CI/CD 自动化上架流水线

5.1 AGC Publishing API 自动化流程

AGC 提供 Publishing API，支持通过编程方式实现 HarmonyOS 应用的自动化上架、更新及管理，可与 CI/CD 流水线集成，实现应用的自动打包、提交和发布。

一次完整的测试版本自动化提交包含六个步骤：

步骤API 调用说明
1GET /publish/v2/upload-url/for-obs申请 OBS 上传地址
2PUT 上传 .app 到 OBS上传软件包
3POST /publish/v2/test/app/version新建测试版本，返回 versionId
4POST /publish/v2/test/version/pkg绑定软件包
5PUT /publish/v2/test/app/version更新测试版本（绑定测试群组）
6POST /publish/v2/test/app/version/submit提交测试版本审核

5.2 CI/CD 集成要点

鉴权方式：使用 Service Account（PS256 JWT 直接当 Bearer）+ API Client（client_credentials 换 access_token）。

状态管理：每次 CI 失败都会新建一个测试版本但未能完成 submit，导致 state=0 的版本逐步累积。累积到 8 个左右后，再 submit 会稳定复现“审核中数量到达上限”的报错。建议在 CI 流程中增加失败版本的清理逻辑。

上传包解析等待：上传的 .app 在服务端需要异步解析（apiLevel 校验），解析完成前更新测试版本会报“package state is abnormal”。建议增加固定间隔重试，并监控解析完成状态。

异常处理：提交审核可能返回“审核中数量到达上限”的错误（code 204144692）。需要在 CI 流程中捕获该异常并跳过本次提交，等待已有审核完成后重试。

5.3 社区 CLI 工具

shipup 是一个 Node.js CLI 工具，支持 HarmonyOS AppGallery Connect（.app）的上传、提交、查询和发布操作，以及 Android 多市场上传和 iOS App Store Connect 操作。设计用于本地自动化和 CI 场景，支持 JSON 输出到 stdout、诊断信息到 stderr、统一的 provider 状态和退出码。

HarmonyOS 相关命令：

shipup harmony upload --package ./application.app --dry-run
shipup harmony submit
shipup harmony status

5.4 流水线配置示例

以下是一个基于 GitLab CI 的流水线配置示例：

stages:
  - lint
  - build
  - test
  - performance
  - package
  - publish

lint:
  stage: lint
  script:
    - hvigorw codeLinter

build:
  stage: build
  script:
    - hvigorw assembleHap --mode module -p product=default

unit_test:
  stage: test
  script:
    - hvigorw test --mode module -p module=entry@default

performance:
  stage: performance
  script:
    - deveco-testing run --task performance --baseline baseline.json

package:
  stage: package
  script:
    - hvigorw assembleApp --mode project -p product=release
  artifacts:
    paths:
      - build/outputs/default/*.hap

publish:
  stage: publish
  script:
    - shipup harmony upload --package build/outputs/default/*.app
    - shipup harmony submit
  only:
    - tags

六、多元化习题

习题 1（判断题）

题目：在 HarmonyOS 应用上架审核中，应用名称可以使用“手机计算器”“天气预报”等广义归纳类词汇。

答案：错误

解读：应用名称不得为广义归纳类、普遍且不具有识别性的词汇，包括但不限于使用商标术语、热门应用名称或别称、流行词、行业名词、职业名词、类别词、功能性描述的词汇。需要结合应用特色、产品属性设计独特的应用名称。

习题 2（单选题）

题目：以下哪种模块类型适合用于多个 HAP 都要共享同一套稳定公共能力、较大的公共资源或 native 库的场景？

A. HAR
B. HSP
C. Feature HAP
D. Entry HAP

答案：B

解读：HSP 只有在确实需要运行时共享代码/资源时再上，比如多个 HAP 都要共享同一套稳定公共能力、较大的公共资源或 native 库。HAR 适合业务内静态复用，多 HAP 适合真正独立的大业务或按需分发场景。

习题 3（多选题）

题目：关于 Push 用户增长服务的核心能力，以下说法正确的有（多选）：

A. 支持标签人群圈定、私有人群上传和 RTA 筛选
B. 支持文案 AB 测试和自定义小图标、背景图等高级样式
C. 支持立即显示、下拉通知栏显示、亮屏显示等多种呈现时机
D. 仅支持 Android 设备，不支持 HarmonyOS

答案：A、B、C

解读：Push 用户增长服务支持标签人群圈定、私有人群上传、自定义人群直投和 RTA 筛选，选项 A 正确。支持文本、图片、按钮基本样式，支持文案 AB，支持自定义小图标、背景图、自定义标题颜色等高级样式，选项 B 正确。支持定义消息呈现的时机，立即显示、下拉通知栏显示、亮屏显示，选项 C 正确。Push 用户增长平台可覆盖华为手机，支持 HarmonyOS，选项 D 错误。

习题 4（代码填空题）

题目：请补全以下 AGC 测试版本自动化提交流程中的关键 API 调用。

# 1. 申请 OBS 上传地址
GET /publish/v2/______________

# 2. 上传 .app 到 OBS
PUT <OBS地址>

# 3. 新建测试版本
POST /publish/v2/test/app/______________

# 4. 绑定软件包
POST /publish/v2/test/version/pkg

# 5. 更新测试版本（绑定测试群组）
PUT /publish/v2/test/app/version

# 6. 提交测试版本审核
POST /publish/v2/test/app/version/______________

答案：upload-url/for-obs、version、submit

解读：完整的 AGC 测试版本自动化提交流程包括申请 OBS 上传地址、上传包、新建测试版本、绑定软件包、更新测试版本、提交审核六个步骤。每个步骤对应特定的 API 端点，CI 流水线按顺序调用即可完成全自动提交。

习题 5（代码改错题）

题目：以下 CI/CD 流水线代码在上架自动化环节存在缺陷，请指出问题并给出改进方案。

upload_and_submit:
  script:
    - curl -X POST "https://api.agc.com/publish/v2/test/app/version/submit" \
        -H "Authorization: Bearer $TOKEN" \
        -d '{"versionId": "$VERSION_ID"}'

答案：代码缺少失败处理和版本清理逻辑。根据 AGC API 的反馈，每次 CI 失败都会新建一个测试版本但未能完成 submit，导致 state=0 的版本逐步累积，累积到 8 个左右后再次 submit 会触发“审核中数量到达上限”的报错。改进方案包括：在 submit 失败时捕获异常并记录；在流水线中增加失败版本清理逻辑；在提交前检查 state=0 的版本数量，超过阈值时先清理再提交。

解读：AGC 测试版本 API 对未完结版本有数量限制，CI 流水线必须包含失败重试和状态清理机制，否则累积的无效版本会阻塞后续提交。

习题 6（简答题）

题目：简述 HAR、HSP、多 HAP 三种模块类型的选型原则，以及模块拆分粒度的建议。

答案：HAR 优先用于业务内静态复用，如基础 UI 组件、业务领域组件、工具层、网络层、埋点层等，边界简单调试成本低。HSP 只有在确实需要运行时共享代码/资源时再上，如多个 HAP 都要共享同一套稳定公共能力、较大的公共资源或 native 库，适合放稳定的基础能力并控制公开 API。多 HAP 主要用于真正独立的大业务或按需分发场景，普通中小项目不要为了“架构好看”上多 HAP。模块拆分粒度方面，40+ HAR 项目可以按团队/业务域分组，保留 10 到 20 个左右清晰边界的模块通常更容易维护和构建。如果很多 HAR 只是一个页面或几个工具类，通常拆得过细了，可以把高内聚的小模块合并成“领域包”。

解读：模块拆分的核心原则是“默认 HAR，少量 HSP，谨慎多 HAP”。拆分粒度应基于业务边界和团队协作需求，而非过度追求“小而美”。模块数量与维护成本呈正相关，找到合适的平衡点比追求极致拆分更重要。

习题 7（简答题）

题目：简述 AGC Publishing API 自动化上架流程的六个步骤，以及 CI/CD 集成中的关键注意事项。

答案：AGC Publishing API 自动化上架流程包括六个步骤：第一步，GET /publish/v2/upload-url/for-obs 申请 OBS 上传地址；第二步，PUT 上传 .app 到 OBS；第三步，POST /publish/v2/test/app/version 新建测试版本并返回 versionId；第四步，POST /publish/v2/test/version/pkg 绑定软件包；第五步，PUT /publish/v2/test/app/version 更新测试版本（绑定测试群组）；第六步，POST /publish/v2/test/app/version/submit 提交测试版本审核。

CI/CD 集成的关键注意事项包括：鉴权使用 Service Account（PS256 JWT 直接当 Bearer）加 API Client（client_credentials 换 access_token）；每次 CI 失败会新建未完结版本导致 state=0 累积，需要在流水线中增加失败版本清理逻辑；上传的 .app 在服务端需要异步解析，解析完成前更新版本会报错，需要增加重试机制；提交审核可能返回“审核中数量到达上限”的异常，需要捕获并等待重试。

解读：AGC Publishing API 的自动化上架流程清晰但需要注意状态管理和异常处理。CI/CD 集成中的核心挑战不是 API 调用本身，而是如何管理版本状态、处理异步解析延迟、以及应对审核队列上限等边界情况。

习题 8（简答题）

题目：简述应用上架前应完成的自检流程，以及各环节的核心目的。

答案：应用上架前应完成三个自检环节。第一，软件包合法性检测（必选）：检查包名、签名、版本号等基本信息，确保软件包符合上架的基本要求。第二，上架自检（推荐，云端测试）：通过 AGC 云测试进行全面检测，包括兼容性、稳定性、性能、功耗、UX、隐私等维度，提前发现并修复问题。第三，本地 DevEco Testing 预检：针对性能、UX、稳定性进行本地验证，包括应用上架预检、性能基础质量测试、UX 基础质量测试和场景化性能测试。三个环节从基础到深入，层层递进，确保应用在上架前达到质量要求。

解读：上架自检的核心目的是提前发现问题、降低驳回概率、缩短审核周期。建议开发者将自检流程集成到 CI/CD 流水线中，实现自动化检测，确保每次提交的版本都符合上架标准。

七、本节知识点总结

上架审核规范
应用信息必须与实际功能一致，截图素材需符合规范，应用名称不得使用广义归纳类词汇，应用分类需与实际功能匹配。3.5 条款关注应用价值与独特性，不收录功能与系统重复、信息罗列、单一 H5 页面、企业黄页、广告推广等类型应用。

云测试与自检工具
AGC 云测试支持兼容性、稳定性、性能、功耗、UX、隐私等自动化检测。DevEco Testing 支持本地上架预检、性能基础质量测试、UX 基础质量测试。提交审核前应完成软件包合法性检测、上架自检和本地预检。

运营增长工具
AppGallery 增长引擎包含预约发布、精选提名、搜索优化、评论评分管理、数据服务和应用归因服务。Push 用户增长服务支持目标设定、人群圈选、文案创意、呈现时机和效果归因，通过场景理解引擎与意图识别实现精准触达。

工程化模块拆分
默认 HAR（业务内静态复用），少量 HSP（运行时共享稳定能力），谨慎多 HAP（独立大业务或按需分发）。40+ HAR 项目可合并为 10-20 个领域包，让依赖方向单向分层，稳定基础能力放底层。

CI/CD 自动化上架
AGC Publishing API 支持六步自动化流程：申请 OBS 上传地址→上传包→新建测试版本→绑定软件包→更新测试版本→提交审核。CI 集成需注意失败版本清理、异步解析等待和审核队列上限的异常处理。社区 CLI 工具 shipup 支持 HarmonyOS 和 Android 多市场的自动化上传与发布。

下节预告

第17课将进入 HarmonyOS 7.0 空间计算与 3D 渲染实战，涵盖 ArkGraphics 3D、Component3D、Spatial Recon Kit、沉浸光感组件与空间音频的完整技术栈与实战应用。

# 华为 # harmonyos # ui # 学习
Logo
HarmonyOS开发者社区

讨论HarmonyOS开发技术，专注于API与组件、DevEco Studio、测试、元服务和应用上架分发等。

更多推荐

cover

HarmonyOS 7 ArkUI 实战 01｜布局别再硬堆

avatar HarmonyOS开发者社区
cover

HarmonyOS 7 ArkUI 实战 02｜列表这样写更稳

avatar HarmonyOS开发者社区
cover

鸿蒙开发 W3 手把手入门：ArkUI 组件与布局

avatar HarmonyOS开发者社区