第35次：应用打包与发布

本文回到工程交付本身，结合当前项目文件讲解鸿蒙应用的打包与发布。核心会涉及 build-profile.json5、entry/src/main/module.json5、页面注册文件，以及已经可用的 assembleHap 构建流程。

---

先明确当前项目的发布状态

当前项目已经具备可用的打包能力，现状如下：

• assembleHap 执行成功
• 能生成 HAP 构建产物
• 当前签名配置有效
• 但构建过程存在较多警告，尤其是过时 API 和 rawfile 源码打包检查

也就是说，这个项目已经具备“可以出包”的基础，但如果要进入更正式的发布阶段，还需要做一轮工程清理。

---

一、build-profile.json5 决定了什么

这是鸿蒙项目里非常关键的构建配置文件。当前项目在这里配置了：

• 签名配置 signingConfigs
• 产品配置 products
• 构建模式 buildModeSet
• 模块入口 modules

尤其是签名部分，已经明确指定了：

• storeFile
• keyAlias
• profile
• certpath

这说明当前项目并不是“开发试玩状态”，而是已经准备了正式签名材料。教程里这一点一定要说明，因为它直接关系到应用是否能形成可安装、可发布产物。

---

二、module.json5 管的是应用模块身份

entry/src/main/module.json5 里定义了很多发布相关信息，包括：

• 模块名称 entry
• 类型 entry
• 主入口 EntryAbility
• 支持设备类型 phone
• 页面配置入口 $profile:main_pages

它决定了应用模块本身如何被系统识别。可以把它理解成“应用模块身份证”。如果这里配置有问题，哪怕页面代码都没错，应用也可能无法正确安装、启动或路由。

---

三、页面注册和打包其实也有关联

很多人会以为打包只看 build-profile.json5。实际上，页面注册文件 main_pages.json 也非常关键，因为被应用访问的页面需要在这里完整声明。

如果你新增了页面但没注册，可能不是“构建时报错”，而是“运行时导航不到”。这类问题往往会在提测或发布前才暴露出来，所以最好在发布前统一检查一次。

---

四、当前项目的打包流程

在当前环境里，已经验证可用的构建方式本质上就是调用 hvigor 进行 HAP 打包。对你来说，更重要的是理解它背后做了哪些事：

1. 清理旧构建产物
2. 读取应用与模块配置
3. 编译 ArkTS 与资源
4. 生成打包信息
5. 生成 unsigned hap
6. 执行签名
7. 输出 signed hap

这张流程图能帮助你理解：打包不是一个黑盒按钮，而是一整套构建链。

---

五、当前构建过程中有哪些发布前要关注的点

虽然打包成功了，但真正准备发布时，至少还要重点关注下面几类问题：

1. 过时 API 警告

例如：

• pushUrl
• back
• getParams
• getContext

这些短期不一定阻塞发布，但长期一定会增加升级成本。

2. rawfile 中包含较多源码型资源

构建时已经出现“Unexpected source code files packaged in entry”的警告。这意味着包内资源组织方式仍然可以继续优化，否则包体、审查和后续维护都会受影响。

3. 签名材料路径要在发布环境稳定可用

当前签名文件路径直接指向本地磁盘位置。在个人开发环境可用，不代表换机器、换 CI 或换发布环境后仍然可用。

---

六、发布前最推荐做的一轮检查

如果你以后真的要把这个项目拿去交付、提测或发布，建议至少按下面顺序做一遍检查：

1. 再跑一次完整打包，确认仍能成功出包。
2. 逐条梳理构建警告，标记优先级。
3. 检查 main_pages.json，确认所有入口页面都已注册。
4. 检查签名文件路径和证书是否仍然有效。
5. 运行应用主链路，确认首页、课程、题库、源码、项目、下载页都能进入。
6. 特别检查 rawfile 资源是否都能正确读取，例如图片、zip、视频。

这一步做完后，应用才算真正进入“可交付状态”。

---

七、图文结合看一下发布准备关系图

这张图想表达的是：发布不只是“点一下打包”，而是配置、资源、页面、签名、功能回归一起成立，才叫准备完成。

---

八、本篇常见坑

1. 构建成功就直接认为能发布

构建通过不代表警告、资源组织和签名环境都已经最优。

2. 忽略签名文件的环境依赖

本地绝对路径在换机器时很容易出问题。

3. 发布前不回归主要页面链路

很多问题不是编译问题，而是运行期导航或资源读取问题。

4. rawfile 里放太多不必要源码型文件

会增加打包风险和审查复杂度。

---

本篇小结

这最后一篇最重要的收获是：鸿蒙应用打包与发布从来不是“最后按一下按钮”，而是一个由配置、页面、资源、签名和构建结果共同决定的交付过程。

当前项目已经具备出包基础，但发布前仍然建议做一轮面向警告和资源组织的工程清理。这样应用不仅能打出来，还更适合长期维护和后续上架。

---

跟着真实配置继续往下看

当前项目 build-profile.json5 中真实存在的签名配置如下：

"products": [
  {
    "name": "default",
    "signingConfig": "default",
    "targetSdkVersion": "6.0.0(20)",
    "compatibleSdkVersion": "6.0.0(20)",
    "runtimeOS": "HarmonyOS"
  }
]

模块入口配置的真实代码如下：

"module": {
  "name": "entry",
  "type": "entry",
  "mainElement": "EntryAbility",
  "deviceTypes": [
    "phone"
  ],
  "pages": "$profile:main_pages"
}

按这个顺序动手

1. 打开 build-profile.json5，先看 products 和 signingConfigs。
2. 再打开 entry/src/main/module.json5，确认入口模块和页面配置。
3. 最后对照 main_pages.json，检查页面注册是否完整。

---

课后练习

1. 自己整理一份“发布前检查清单”，至少包含页面注册、签名、资源、主链路回归四部分。
2. 说明为什么 rawfile 内部源码文件的构建警告值得优先关注。
3. 思考如果未来接入持续集成，当前签名配置里哪些内容最需要先做环境抽离。