第43篇工程化实践——hvigor 构建与模块化配置一、引言在大型项目开发中工程化水平直接决定了团队的开发效率和代码质量。DriverLicenseExam 项目采用了鸿蒙推荐的 hvigor 构建系统结合多模块架构实现了高效的工程化管理。本文将深入解析项目的构建配置、依赖管理、代码质量保障等工程化实践。二、hvigor 构建系统概述2.1 hvigor 简介hvigor 是鸿蒙生态的构建工具类似于 Android 的 Gradle。它负责项目构建与编译依赖管理签名与打包多模块并行构建2.2 构建配置层次项目的构建配置分为三个层次工程级 build-profile.json5 ← 全局配置 ├── 签名配置 ├── 产品配置Flavor └── 模块注册 │ ├── 模块级 build-profile.json5 ← 模块构建配置 │ ├── apiType │ ├── buildOption │ └── targets │ └── oh-package.json5 ← 依赖声明 ├── 本地 HAR 依赖 └── 远程依赖三、工程级构建配置3.1 build-profile.json5项目根目录的build-profile.json5是整个工程的构建入口// build-profile.json5{app:{signingConfigs:[{name:default,material:{certPath:***.cer,keyStorePath:***.p12,keyStorePassword:***,keyAlias:***,keyPassword:***}}],products:[{name:default,signingConfig:default,compatibleSdkVersion:5.0.0(12),runtimeOS:HarmonyOS}]},modules:[{name:entry,srcPath:./products/entry}]}关键字段解析字段说明作用signingConfigs签名配置调试/发布签名证书products.name产品名称可用于多 Flavor 构建compatibleSdkVersion兼容 SDK 版本控制最低支持版本modules模块列表注册所有子模块3.2 多产品构建如果应用需要区分免费版和付费版可以配置多个产品{products:[{name:free,signingConfig:debug},{name:paid,signingConfig:release}]}但目前项目只配置了一个default产品保持了简洁性。四、模块级构建配置4.1 构建选项每个模块entry 和各个 HAR都有独立的 build-profile.json5// products/entry/build-profile.json5{apiType:stageMode,buildOption:{arkOptions:{compileArkTS:true}},targets:[{name:default,applyToProducts:[default]}]}关键字段apiTypestageModeStage 模型或 featureModeFA 模型compileArkTS是否启用 ArkTS 编译器targets构建目标可以针对不同产品定制4.2 HAR 模块的构建配置// commons/commonLib/build-profile.json5{apiType:stageMode,buildOption:{arkOptions:{compileArkTS:true}}}HAR 模块的构建配置比 entry 模块简单因为它不需要 targets 和签名配置。五、依赖管理5.1 oh-package.json5 详解oh-package.json5是鸿蒙的包管理配置文件类似于 Node.js 的package.json// products/entry/oh-package.json5{name:entry,version:1.0.0,dependencies:{exam:file:../../components/exam,aggregated_ads:file:../../components/aggregated_ads,aggregated_share:file:../../components/aggregated_share,app_setting:file:../../components/app_setting,check_app_update:file:../../components/check_app_update,collect_personal_info:file:../../components/collect_personal_info,feedback:file:../../components/feedback,membership:file:../../components/membership,module_city_select:file:../../components/module_city_select,search:file:../../components/search,guide:file:../../components/guide,ohos_agcit/driver_license_exam_commonlib:file:../../commons/commonLib,ohos_agcit/driver_license_exam_datasource:file:../../commons/datasource,ohos_agcit/driver_license_exam_network:file:../../commons/network}}5.2 依赖类型项目中使用的依赖有两种形式1. 本地 HAR 依赖——使用 file: 协议exam:file:../../components/exam这种依赖方式直接将本地模块链接到当前项目被依赖模块的任何修改都会实时反映到主项目中非常适合组件化开发。2. 命名空间隔离ohos_agcit/driver_license_exam_commonlib:file:../../commons/commonLib使用ohos_agcit/前缀进行命名空间隔离避免不同 HAR 之间的名称冲突。这是一个推荐的最佳实践。5.3 HAR 模块自身的配置// commons/commonLib/oh-package.json5{name:ohos_agcit/driver_license_exam_commonlib,version:1.0.0,description:公共工具模块,main:Index.ets,license:Apache-2.0,dependencies:{}}HAR 自身的配置需要指定name包名主模块通过这个名字引用它main入口文件指定模块的导出入口dependenciesHAR 自身的依赖如果为空的 {} 则表示没有额外依赖六、模块导出管理6.1 Index.ets——模块的对外接口每个 HAR 通过Index.ets文件控制对外暴露的内容// commons/commonLib/Index.ets export { CommonConstants } from ./src/main/ets/constants/CommonContants; export { CommonEnums } from ./src/main/ets/constants/CommonEnums; export { Logger } from ./src/main/ets/utils/Logger; export { PermissionUtil } from ./src/main/ets/utils/PermissionUtil; export { AccountUtil } from ./src/main/ets/utils/AccountUtil; export { PreferencesUtil } from ./src/main/ets/utils/PreferencesUtil; export { RouterModule } from ./src/main/ets/utils/RouterModule; export { CommonModel } from ./src/main/ets/model/CommonModel; export { FormatUtil } from ./src/main/ets/utils/FormatUtil; export { StringUtil } from ./src/main/ets/utils/StringUtil; export { PushUtils } from ./src/main/ets/push/PushUtils; export { showToast, PromptActionClass } from ./src/main/ets/utils/PromptActionClass;导出管理的原则最小暴露只导出其他模块需要使用的类和方法内部隐藏模块内部使用的工具类、常量不应导出统一入口所有导出集中在 Index.ets 中七、代码质量保障7.1 代码检查配置项目使用code-linter.json5配置代码检查规则// code-linter.json5{rules:{arkts-identifiers:{option:{camelCase:true}}}}7.2 混淆配置HAR 模块的obfuscation-rules.txt用于配置代码混淆规则// commons/commonLib/obfuscation-rules.txt # 保留导出 API 不被混淆 -keep class com.example.commonLib.** { *; }混淆可以增加逆向工程的难度保护应用的安全性。7.3 消费者规则// commons/commonLib/consumer-rules.txt # 消费者规则确保 HAR 使用者的构建正确consumer-rules.txt定义了当其他模块引用此 HAR 时应该应用的规则。八、工程化最佳实践8.1 模块划分原则层级目录职责依赖原则公共层commons/工具类、数据源、网络不依赖其他模块组件层components/业务组件只依赖 commons产品层products/应用入口依赖所有组件8.2 版本管理{name:ohos_agcit/driver_license_exam_commonlib,version:1.0.0}所有 HAR 使用独立的版本号管理当接口发生变更时更新版本号主模块根据版本号决定是否升级依赖。8.3 构建优化{buildOption:{arkOptions:{compileArkTS:true}}}确保所有模块都启用 ArkTS 编译这是鸿蒙推荐的现代化编译方式性能优于传统 JS 编译。九、总结DriverLicenseExam 项目的工程化实践展示了鸿蒙多模块应用的完整构建体系hvigor 构建分层的构建配置支持多产品构建依赖管理file: 协议管理本地 HAR 依赖命名空间隔离模块导出Index.ets 统一管理导出最小暴露原则代码质量静态检查 混淆 消费者规则这种工程化架构不仅确保了当前项目的可维护性也为团队协作和持续集成奠定了坚实基础。关键源码文件build-profile.json5— 工程级构建配置products/entry/build-profile.json5— entry 模块构建配置products/entry/oh-package.json5— 依赖声明commons/commonLib/Index.ets— 导出管理code-linter.json5— 代码检查commons/commonLib/obfuscation-rules.txt— 混淆规则
