目录
[1 -> 前言](#1 -> 前言)
[2 -> 使用约束](#2 -> 使用约束)
[3 -> 创建模块](#3 -> 创建模块)
[4 -> 构建HAR](#4 -> 构建HAR)
[4.1 -> 以debug模式构建HAR](#4.1 -> 以debug模式构建HAR)
[4.2 -> 以release模式构建HAR](#4.2 -> 以release模式构建HAR)
[4.3 -> 构建字节码格式的HAR](#4.3 -> 构建字节码格式的HAR)
[4.4 -> 对HAR进行签名](#4.4 -> 对HAR进行签名)

1 -> 前言
构建模式:DevEco Studio默认提供debug和release两种构建模式,同时支持开发者自定义构建模式。
产物格式:构建出的HAR包产物分为包含源码的HAR、包含js中间码的HAR以及包含字节码的HAR三种产物格式。
debug构建模式时,从DevEco Studio NEXT Beta1(5.0.3.800)版本开始,默认产物是字节码HAR,用于开发者进行本地调测,可提升编译构建效率;同时支持构建包含源码的HAR。
release构建模式时,从DevEco Studio NEXT Developer Beta3(5.0.3.600)版本开始,默认不开启混淆,构建产物和debug模式相同;开启混淆后,构建产物是包含js中间码的HAR,用于发布到ohpm中心仓;同时支持配置产物格式为字节码HAR,用于提升发布产物的安全性。
2 -> 使用约束
- HAR包不支持在module.json5中配置extension组件。
- HAR包不支持pages路由配置。
- HAR自身的构建不建议引用本地模块,可能导致其他模块依赖该HAR包时安装失败,如果安装失败,需要在工程级oh-package.json5中配置overrides。
- 以release模式构建HAR时,对ArkTS代码的混淆仅支持API 10及以上的Stage模型。
- 引用字节码Har包时,当字节码Har包的API版本高于工程的compatibleSDKVersion时,不可用。
- 字节码Har包和Hap工程的compatibleSDKVersion均为API 12时,当字节码Har包的compatibleSdkVersionStage高于Hap工程的compatibleSdkVersionStage时,不可用。
3 -> 创建模块
- 新建工程时选择API 10及以上的Stage模型,工程创建完成后,新建"Static Library"模块。

- 编写代码。
library // HAR根目录
├─libs // 存放用户自定义引用的Native库,一般为.so文件
└─src
│ └─main
│ ├─cpp
│ │ ├─types // 定义Native API对外暴露的接口
│ │ │ └─liblibrary
│ │ │ ├─index.d.ts
│ │ │ └─oh-package.json5
│ │ ├─CMakeLists.txt // CMake配置文件
│ │ └─napi_init.cpp // C++源码文件
│ └─ets // ArkTS源码目录
│ │ └─components
│ │ └─MainPage.ets
│ ├─resources // 资源目录,用于存放资源文件,如图片、多媒体、字符串等
│ └─module.json5 // 模块配置文件,包含当前HAR的配置信息
├─build-profile.json5 // Hvigor编译构建所需的配置文件,包含编译选项
├─hvigorfile.ts // Hvigor构建脚本文件,包含构建当前模块的插件、自定义任务等
├─Index.ets // HAR的入口文件,一般作为出口定义HAR对外提供的函数、组件等
└─oh-package.json5 // HAR的描述文件,定义HAR的基本信息、依赖项等
-
在oh-package.json5中"main"字段定义导出文件入口。若不设置"main"字段,默认以当前目录下Index.ets为入口文件,依据.ets>.ts>.js的顺序依次检索。以将ets/components/MainPage.ets文件设置为入口文件为例:
{
...
"main": "./src/main/ets/components/MainPage.ets",
...
}
4 -> 构建HAR
4.1 -> 以debug模式构建HAR
产物是包含源码的HAR包,其中包含源码、资源文件以及配置文件等,方便开发者进行本地调测,不包含build、node_modules、oh_modules、.cxx、.previewer、.hvigor、.gitignore、.ohpmignore、.gitignore/.ohpmignore中配置的文件、cpp工程的CMakeLists.txt。
说明
- 如果是native工程,以debug模式构建的native产物中不包含调试信息和符号表,如需调试,请参考三方源码调试。
- 从5.0.3.403版本开始,不再建议使用相对路径跨模块引用代码文件,若历史工程存在此场景的跨模块引用,会出现warning告警,请尝试将该文件移至本模块内,再重新进行编译。
- 从5.0.3.403版本开始,以debug/release模式构建HAR的流程使用相同的语法校验规则,若历史工程出现ArkTS语法报错,请按照报错信息修改代码,以符合ArkTS语言规范。
- 将工程级build-profile.json5中的useNormalizedOHMUrl字段设置为false。
说明
使用DevEco Studio NEXT Beta1(5.0.3.800)之前的版本,工程级build-profile.json5的useNormalizedOHMUrl字段默认值为false,无需执行本步骤。
{
"app": {
"products": [
{
"buildOption": {
"strictMode": {
"useNormalizedOHMUrl": false
}
}
}
]
}
}
- 点击DevEco Studio右上角图标

,Build Mode 选择debug。 默认为**<Default>**模式:在编译App时使用release模式,编译HAP/HSP/HAR时使用debug模式。

- 若部分工程源文件无需构建到HAR包中,可在module目录下新建**.ohpmignore** 文件,配置打包时要忽略的文件,支持正则表达式写法。将无需打包进HAR包的文件/文件夹名称写入**.ohpmignore** 文件中。DevEco Studio构建时将过滤掉**.ohpmignore**文件中所包含的文件/文件夹。

- 选中HAR模块的根目录,点击**Build > Make Module '<module-name>'**启动构建。

构建完成后,build目录下生成HAR包产物。

HAR包产物解压后,结构如下:

4.2 -> 以release模式构建HAR
从DevEco Studio NEXT Developer Beta3(5.0.3.600)版本开始,默认不开启混淆,构建产物和debug模式相同,请参考以debug模式构建HAR。
开启混淆后,构建产物是包含js中间码的HAR包,其中包含源码混淆后生成的js中间码文件、资源文件、配置文件、readme、changelog声明文件、license证书文件,用于发布到ohpm中心仓。
- 点击DevEco Studio右上角图标

,Build Mode 中选择release。 默认为**<Default>**模式:在编译App时使用release模式,编译HAP/HSP/HAR时使用debug模式。

在编译模式为release时,为保护代码资产,建议开启混淆,在模块级build-profile.json5文件的release的buildOptionSet配置中,将obfuscation/ruleOptions下的enable字段设置为true。
{
"apiType": "stageMode",
"buildOption": {
},
"buildOptionSet": [
{
"name": "release",
"arkOptions": {
// 混淆相关参数
"obfuscation": {
"ruleOptions": {
// true表示进行混淆,false表示不进行混淆。5.0.3.600及以上版本默认为false
"enable": true,
// 混淆规则文件
"files": [
"./obfuscation-rules.txt"
]
},
// consumerFiles中指定的混淆配置文件会在构建依赖这个library的工程或library时被应用
"consumerFiles": [
"./consumer-rules.txt"
]
}
},
},
],
"targets": [
{
"name": "default"
}
]
}
- 将工程级build-profile.json5中的useNormalizedOHMUrl字段设置为false。
说明
使用DevEco Studio NEXT Beta1(5.0.3.800)之前的版本,工程级build-profile.json5的useNormalizedOHMUrl字段默认值为false,无需执行本步骤。
{
"app": {
"products": [
{
"buildOption": {
"strictMode": {
"useNormalizedOHMUrl": false
}
}
}
]
}
}
- 选中HAR模块的根目录,点击**Build > Make Module '<module-name>'**启动构建。

构建完成后,build目录下生成HAR包产物。

HAR包产物解压后,结构如下:

4.3 -> 构建字节码格式的HAR
默认产物是包含字节码的HAR包,其中包含abc字节码、资源文件、配置文件、readme、changelog声明文件、license证书文件,提升发布到ohpm中心仓产物的安全性。
由于字节码HAR包中包含的是编译后的abc字节码,因此当字节码HAR被其他应用模块(HAP/HSP)依赖时,在执行应用模块的编译构建时,不需要再对依赖的HAR中的代码进行语法检查和编译等操作,相比包含源码的HAR和包含js中间码的HAR,可以有效提升应用模块的编译构建效率。
说明
- 由于构建字节码HAR需要生成二进制的格式,所以单独构建字节码HAR会比构建非字节码HAR耗时更多。
- 当字节码HAR被集成使用时,那么该工程的build-profile.json5中的useNormalizedOHMUrl必须设置为true。
- 如果字节码HAR未开启混淆,则后续字节码HAR被集成使用时,将不会再对HAR包进行混淆。
- 字节码HAR使用的依赖需要配置在本模块的oh-package.json5的dependencies或dynamicDependencies中,如果不配置,后续字节码HAR被集成时会出现运行时异常。
- 支持使用不同构建模式进行构建,与构建HAP/HSP相同。
- 将工程级build-profile.json5的useNormalizedOHMUrl设置为true。
说明
从DevEco Studio NEXT Beta1(5.0.3.800)版本开始,工程级build-profile.json5中useNormalizedOHMUrl字段默认为true,byteCodeHar缺省默认值为true,无需执行步骤1和2。
{
"app": {
"products": [
{
"buildOption": {
"strictMode": {
"useNormalizedOHMUrl": true
}
}
}
]
}
}
-
在HAR模块的build-profile.json5中,将byteCodeHar设置为true。
{
"buildOption": {
"arkOptions": {
"byteCodeHar": true
}
}
} -
选中HAR模块的根目录,点击**Build > Make Module '<module-name>'**启动构建。

构建完成后,build目录下生成HAR包产物。

HAR包产物解压后,结构如下:

4.4 -> 对HAR进行签名
DevEco Studio在构建HAR流程的基础上,支持对HAR进行签名。签名后的HAR包后续可用于接入生态市场。
说明
1. 该能力只在Compatible SDK 5.0.0(12)及以上版本的SDK中支持。
2. 该能力需开启Hvigor的Daemon能力,请确保当前工程开启了Daemon,打开Settings > Build,Execution,Deployment > Build Tools > Hvigor,勾选字段Enable the Daemon for tasks。
-
在hvigor-config.json5中,开启构建签名HAR开关:
{
"properties": {
"ohos.sign.har": true
}
} -
配置工程签名信息,配置流程请参考配置签名信息。
-
选中HAR模块的根目录,点击**Build > Make Module '<module-name>'**启动构建。

构建完成后,build目录下生成签名HAR包产物。

感谢各位大佬支持!!!
互三啦!!!