HarmonyOS NEXT系列之定制化构建制品

〇、前言

上一周，为了让自己开发的工具 EasyRouter，在 ohpm 中心仓中获得满分，所以针对评分规则添加了带 example 目录的 v1.1.0 版本，然而，等到审核成功并上架后，却发现仍旧没有拿到满分，而后我在 ohpm 中心仓上找一个已经获得满分的、其他人制作的工具，查看对应的源码工程，发现 example 目录必须在 src 目录同级，才能被扫描和识别。

那么问题来了，默认情况下，编译 har 包都只会将 src 目录编译进制品中，而 src 目录同级的其他目录是不会被打包的，如果想要一起打包进去，该如何操作呢？以及推而广之，输出 har 包制品时，能不能根据需要进行定制呢？下面就让我向大家分享，如何实现定制化构建制品

一、鸿蒙工程的编译配置文件

对于使用过 make 工具管理 C/C++ 项目的人来说，一定清楚 makefile.txt在make工具中的作用：控制编译，而在鸿蒙工程中，也有起到控制编译作用的文件，即 build-profile.json5 文件，而该文件与 makefile.txt 存在不同的地方，只不过是区分模块级和项目级。

1、默认内容

在 DevEco Studio 中创建的项目或模块，会自动创建 build-profile.json5 文件，并且默认具有如下配置项：

{"apiType": "stageMode","buildOption": {},"buildOptionSet": [{"name": "release","arkOptions": {"obfuscation": {"ruleOptions": {"enable": false,"files": ["./obfuscation-rules.txt"]},"consumerFiles": ["./consumer-rules.txt"]}},},],"targets": [{"name": "default"},{"name": "ohosTest"}]
}

如果你此前从未仔细阅读过相关官方文档，可能会认为 build-profile.json5 文件完整内容就是这样的，然而，实际上以上不过是保障项目正常运行所必须的基础配置罢了。

2、完整内容

build-profile.json5 文件作为控制编译过程的配置文件，完整内容涵盖丰富：

apiType
targets
└── name
└── runtimeOS
└── config└── distroFilter / distributionFilter└── apiVersion└── policy└── value└── screenShape└── policy└── value└── screenWindow└── policy└── value└── screenDensity└── policy└── value└── countryCode└── policy└── value└── deviceType└── buildOption└── atomicService└── preloads└── moduleName
└── source└── abilities└── name└── pages└── res└── icon└── label└── launchType└── pages└── sourceRoots
└── resource└── directories
└── output└── artifactName
showInServiceCenter
buildOption
buildOptionSet
└── name
└── debuggable
└── generateSharedTgz
└── copyFrom
└── resOptions└── compression└── media└── enable└── filters└── method└── type└── blocks└── files└── path└── size└── resolution└── exclude└── path└── size└── resolution└── resCompileThreads└── copyCodeResource└── enable└── includes└── excludes└── ignoreResourcePattern└── excludeHarRes└── includeAppScopeRes
└── externalNativeOptions└── path└── abiFilters└── arguments└── cppFlags└── cFlags└── targets
└── sourceOption└── workers
└── nativeLib└── filter└── excludes└── pickFirsts└── pickLasts└── enableOverride└── select└── package└── version└── includePattern└── excludePattern└── include└── exclude└── debugSymbol└── strip└── exclude└── headerPath└── collectAllLibs└── excludeFromHar└── excludeSoFromInterfaceHar└── librariesInfo└── name└── linkLibraries
└── napiLibFilterOption└── excludes└── pickFirsts└── pickLasts└── enableOverride
└── arkOptions└── runtimeOnly└── sources└── packages└── excludePackages└── types  └── obfuscation└── ruleOptions└── enable└── files└── consumerFiles└── buildProfileFields└── integratedHsp└── transformLib└── branchElimination└── byteCodeHar└── bundledDependencies└── packSourceMap└── autoLazyImport└── reExportCheckMode└── skipOhModulesLint└── apPath└── hostPGO
└── packingOptions└── asset└── include└── exclude
└── removePermissions└── name
buildModeBinder
└── buildModeName
└── mappings└── targetName└── buildOptionName
entryModules

原则上，就是需要控制编译过程中的什么东西，就相对应的加上什么配置。

3、认识默认配置项

在学会控制编译时，将 src 之外的目录一起打包之前，先对默认生成的配置项进行认识和了解。
build-profile.json5 文件的默认内容，主要包括三大方面：API 类型、编译混淆规则和制品输出目录。

3.1、apiType

build-profile.json5 文件中，一级字段的头一个就是 apiType，而它起到控制 API模型的作用，当前，鸿蒙工程API模型主要有 stageMode 和 faMode 两种，所以，apiType 的合法值也就是这两种。

模块级 build-profile.json5 文件中的 apiType 的值，要与项目级的保持一致。

3.2、targets

targets 配置项的功能，其实很好理解，就是控制制品的最终输出情况，比如生成的 har 包名称

这里主要利用到 targets 元素对象的 output 字段。

3.3、buildOptionSet

这个配置项，主要起到控制是否进行混淆编译的作用，默认只对 release 制品有配置规则。

二、自定义编译

1、目录包括

首先，看一下在进行自定义编译的时候，如何控制目录包括。

在 buildOption 配置对象里面，有一个 packingOptions 配置项：

这个配置项，正是我们实现目录包括所需要的，例如：

"buildOption": {"packingOptions": {"asset": {"include": ["./example/*"]}}
}

就可以实现 src 目录同级的 example 目录一并打包进制品中：

而 buildOption 的其他字段的作用，分别如下：

而 arkOptions 在实现跨模块路由功能的介绍中，已经使用过 runtimeOnly 配置。

对编译过程进行控制，基本上就是利用 buildOption 中的相关配置项，而详细的说明可以参考官方文档：自定义编译指导