共计 3280 个字符，预计需要花费 9 分钟才能阅读完成。
编译构建是将利用 / 服务的源代码、资源、第三方库等，通过编译工具转换为可间接在硬件设施上运行的二进制机器码，而后再将二进制机器码封装为 HAP/APP 软件包，并为 HAP/APP 包进行签名的过程。其中，HAP 是能够间接运行在模拟器或真机设备中的软件包；APP 则是用于利用 / 服务上架到华为利用市场。HAP 和 APP 的关系阐明请参考工程介绍。
HarmonyOS 利用 / 服务反对 API Version 4~9，但 API Version 4~7 与 API Version 8~9 在编译构建体系、工程目录及配置文件等存在差别，接下来将具体介绍两者之间的差别。
构建体系
HarmonyOS 利用 / 服务 API Version 4~7 和 API Version 8~9 的构建工具和构建插件不同。
- API Version 4~7 构建体系是由 Gradle 构建工具和构建插件组成；
- API Version 8~9 构建体系是由 Hvigor 构建工具和构建插件组成。
Gradle 构建工具作为业界风行的自动化构建开源工具，本章节不再赘述，接下来为大家介绍 Hvigor 构建体系。
Hvigor 构建工具：一款全新基于 TS 实现的前端构建工作编排工具，联合 npm 包管理机制，次要提供工作管理机制，工作注册编排、工程模型治理、配置管理等要害能力，更合乎 ArkTS/JS 开发者的开发习惯。
构建插件 hvigor-ohos-plugin：是基于 Hvigor 构建工具开发的一个插件，利用 Hvigor 的工作编排机制实现利用 / 服务构建工作流的执行，实现 HAP/APP 的构建打包，利用于利用 / 服务的构建。
DevEco Studio 会主动配置配套版本的编译工具和构建插件依赖，对于构建工具和构建插件的版本配套关系可参考 DevEco Studio 版本阐明。如需批改构建工具和构建插件版本，API 9 及以上版本和 API 8 版本工程的批改地位不同：
- API 9 及以上版本需批改 hvigor 目录下的 hvigor-config.json5 文件，示例如下。
{“hvigorVersion”: "2.2.1",
"dependencies": {"@ohos/hvigor-ohos-plugin": "2.2.1"}
}- API 8 版本须要在工程级的 package.json 文件中配置相应的版本依赖，示例如下。
{
...
"dependencies": {
"@ohos/hvigor": "1.4.0",
"@ohos/hvigor-ohos-plugin": "1.4.0"
}
}工程目录及配置文件阐明
工程目录及配置文件（API Version 9）
HarmonyOS API Version 9 基于 Hvigor 构建体系，DevEco Studio 定义了其工程范式，上面是 Hvigor 构建体系的工程目录构造示意图：
对于 Hvigor 构建体系中的构建配置文件（build-profile.json5）、构建脚本（hvigorfile.ts）、依赖配置（oh-package.json5）的具体阐明请参考配置编译构建信息章节。
工程目录及配置文件（API Version 8）
HarmonyOS API Version 8 基于 Hvigor 构建体系，DevEco Studio 定义了其工程范式，上面是 Hvigor 构建体系的工程目录构造示意图：
对于 Hvigor 构建体系中的构建配置文件（build-profile.json5）、构建脚本（hvigorfile.ts）、依赖配置（package.json）的具体阐明请参考配置编译构建信息章节。
工程目录及配置文件（API Version 4~7）
HarmonyOS API Version 4~7 基于 Gradle 构建体系，DevEco Studio 定义了其工程范式，上面是 Gradle 构建体系的工程目录构造示意图：
对于 build.gradle 具体阐明请参考配置编译构建信息章节。
如何构建利用 / 服务
启动利用 / 服务构建
阐明
在实现利用 / 服务开发后，如果开发者须要将利用包上传到 AGC 平台的软件包治理或第三方治理平台草稿箱中，可抉择通过 Upload Project 实现编译并上传，具体请参见通过 DevEco Studio 编译和上传软件包。
通过 DevEco Studio 构建利用 / 服务的形式有以下两种：
- 形式一：通过单击或按钮，DevEco
Studio 会启动利用 / 服务的编译，并将编译后的 HAP 部署到设施中。这种形式个别用于利用开发阶段进行利用的调试、性能验证等场景。 - 形式二：通过 DevEco
Studio 的 Build 菜单栏的编译选项进行构建，HAP 的构建后果寄存于各模块的“build”文件夹下，APP 包的构建后果寄存于工程的“build”文件夹下。这种形式能够别离编译 HAP 和 APP 包，其中 HAP 可用于装置到设施中进行性能验证，APP 包则用于将利用 / 服务公布到利用市场。
对于 Build 菜单下的编译选项阐明如下：
查看编译过程
启动编译后，您能够在底部工具栏窗口查看编译工作的详细信息，例如执行的编译流程、工作的执行工夫等信息。如果在编译构建过程中呈现谬误，您能够依据编译工作的具体谬误阐明进行问题的定位。
API Version 8~9 工程编译构建示意图如下：
API Version 4~7 工程编译构建示意图如下：
另外，针对 Native C++ 开发方式，DevEco Studio 反对的编译工具链为 CMake 和 NinJa，在启动编译后，能够在底部工具栏窗口的输入内容中查看到编译工具链的具体配置信息。
CMake 的配置信息如下所示。
NinJa 的配置信息如下所示。
查看编译后果
编译构建胜利后，您能够在工程目录中找到对应的编译产物（如 APP/HAP）。
- API Version 8~9 编译构建后果：
- API Version 4~7 编译构建后果：
多工程构建
为升高大型利用多个团队合作开发的复杂度，提供多工程开发模式，进步合作开发效率。多工程开发能力反对将大型利用拆分为多个模块，每个模块对应一个独自工程。在每个工程别离编译生成 HAP 后，需对立打包生成一个 APP，用于上架利用市场。
1. 别离在每个工程的 build-profile.json5 配置文件中，设置 multiProjects 字段值为 true。
{
"app": {
...
"multiProjects": true,
}
}2. 筹备好 HAP 打包工具 hap_packing_tool.jar（在 ${HOS_SDK_HOME}/openharmony/ 版本号 /toolchains/lib 下）。
3. 应用如下命令，将多个 HAP 进行打包。
- hap-list：多个 HAP 文件名称，如“1.hap”和“2.hap”，用逗号隔开；
- out-path：生成的 APP 名称，如“final.app”
java -jar app_packing_tool.jar --mode multiApp --hap-list 1.hap,2.hap --out-path final.app作为一名合格一线开发程序员，大家心里必定会有很多疑难！鸿蒙零碎这么弱小~~
为了可能让大家跟上互联网时代的技术迭代，在这里跟大家分享一下我本人近期学习心得以及参考网上材料整顿出的一份最新版的鸿蒙学习晋升材料 ，有须要的小伙伴自行支付， 限时开源，先到先得~~~~
支付以下高清学习路线原图请点击→《鸿蒙 (Harmony OS)开发学习手册》纯血鸿蒙 HarmonyOS 根底技能学习路线图
支付以上残缺高清学习路线图，请点击→《鸿蒙根底入门学习指南》小编本人整顿的局部学习材料（蕴含有高清视频、开发文档、电子书籍等）
以上分享的学习路线都适宜哪些人跟着学习？
- 应届生 / 计算机专业
通过学习鸿蒙新兴技术，入行互联网，将来高起点待业。
- 0 根底转行
提前布局新方向，抓住风口，自我晋升，取得更多就业机会。
- 技术晋升 / 进阶跳槽
倒退瓶颈期，晋升职场竞争力，疾速把握鸿蒙技术，享受蓝海红利
总结
如果你感觉这篇内容对你有帮忙，我想麻烦大家动动小手给我：点赞，转发，有你们的『点赞和评论』，才是我发明的能源。
关注我，同时能够期待后续文章 ing，不定期分享原创常识。
想要获取更多残缺鸿蒙最新 VIP 学习材料，请点击→《鸿蒙全套学习指南》
