本节目标掌握 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 权限再创建 Profile1.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 上架自检流程提交审核前推荐完成以下自检流程软件包合法性检测必选检查包名、签名、版本号等基本信息上架自检推荐云端测试AGC 云测试进行全面检测本地 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新建测试版本返回 versionId4POST /publish/v2/test/version/pkg绑定软件包5PUT /publish/v2/test/app/version更新测试版本绑定测试群组6POST /publish/v2/test/app/version/submit提交测试版本审核5.2 CI/CD 集成要点鉴权方式使用 Service AccountPS256 JWT 直接当 Bearer API Clientclient_credentials 换 access_token。状态管理每次 CI 失败都会新建一个测试版本但未能完成 submit导致 state0 的版本逐步累积。累积到 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 status5.4 流水线配置示例以下是一个基于 GitLab CI 的流水线配置示例stages:-lint-build-test-performance-package-publishlint:stage:lintscript:-hvigorw codeLinterbuild:stage:buildscript:-hvigorw assembleHap--mode module-p productdefaultunit_test:stage:testscript:-hvigorw test--mode module-p moduleentrydefaultperformance:stage:performancescript:-deveco-testing run--task performance--baseline baseline.jsonpackage:stage:packagescript:-hvigorw assembleApp--mode project-p productreleaseartifacts:paths:-build/outputs/default/*.happublish:stage:publishscript:-shipup harmony upload--package build/outputs/default/*.app-shipup harmony submitonly:-tags六、多元化习题习题 1判断题题目在 HarmonyOS 应用上架审核中应用名称可以使用“手机计算器”“天气预报”等广义归纳类词汇。答案错误解读应用名称不得为广义归纳类、普遍且不具有识别性的词汇包括但不限于使用商标术语、热门应用名称或别称、流行词、行业名词、职业名词、类别词、功能性描述的词汇。需要结合应用特色、产品属性设计独特的应用名称。习题 2单选题题目以下哪种模块类型适合用于多个 HAP 都要共享同一套稳定公共能力、较大的公共资源或 native 库的场景A. HARB. HSPC. Feature HAPD. 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 到 OBSPUTOBS地址# 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导致 state0 的版本逐步累积累积到 8 个左右后再次 submit 会触发“审核中数量到达上限”的报错。改进方案包括在 submit 失败时捕获异常并记录在流水线中增加失败版本清理逻辑在提交前检查 state0 的版本数量超过阈值时先清理再提交。解读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 AccountPS256 JWT 直接当 Bearer加 API Clientclient_credentials 换 access_token每次 CI 失败会新建未完结版本导致 state0 累积需要在流水线中增加失败版本清理逻辑上传的 .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、沉浸光感组件与空间音频的完整技术栈与实战应用。