DevEco Studio 大型项目 hvigor 构建慢，有哪些系统性的优化手段？
DevEco Studio 大型项目 hvigor 构建慢，有哪些系统性的优化手段？
- hvigor-config.json5 中的并行构建、增量编译相关配置项有哪些？
- HAR模块之间的依赖关系声明是否会影响构建缓存的命中？
问题一：
- hvigor.enableMemoryCache: 开启后任务产物常驻内存，增量编译时直接复用，显著提速；但会增加内存占用。若内存紧张可关闭，但增量编译时间会增加。
- ohos.arkCompile.noEmitJs : 跳过 JS 中间产物生成，可降低编译峰值内存并加快编译速度，适合大型 ArkTS 工程。 harmonyos.cool
- hvigor.incremental.optimization：优化任务增量判断逻辑，减少不必要的任务重执行。harmonyos.cool
- ohos.processLib.optimization: 针对包含大量.so 库的项目，优化增量判定耗时。
问题二：
源码依赖 vs HAR 产物依赖： 当模块 A 以源码形式依赖模块 B时，B的任何源文件变更都会导致 A的编译缓存失效（因为输入发生了变化）。若 B 以编译后的HAR产物形式依赖，且 HAR版本未变，则 A的缓存可保持命中。
HAR是静态拷贝机制：HAR在编译时会被完整复制到依赖它的每个 HAP/HSP 中。如果多个模块依赖同一个 HAR，该 HAR 会被多次编译打包，这不仅增加包体积，也会导致各模块对同一 HAR 的编译缓存相互独立，无法共享。
hvigor-config.json5 关键配置项详解
| 配置项 | 作用 | 建议 |
|---|---|---|
hvigor.enableMemoryCache |
开启后，任务产物常驻内存，增量编译时直接复用，避免反复 IO 和重复计算，显著提速 | 开启。若内存 < 16GB 可关闭，但增量时间会加长 |
ohos.arkCompile.noEmitJs |
跳过 JS 中间产物生成，直接编译为方舟字节码，降低编译峰值内存并加快速度 | 大型 ArkTS 工程强烈推荐开启（true） |
hvigor.incremental.optimization |
优化增量判断逻辑，减少不必要的任务重执行（如更精确的文件变更检测） | 开启，可大幅减少增量编译范围 |
ohos.processLib.optimization |
针对包含大量 .so 库的模块，优化增量判定的耗时 |
如果项目有大量 Native 库，开启 |
hvigor.parallel |
控制并行编译的任务数，一般自动检测 CPU 核心数 | 通常无需手动设置，若出现内存溢出可适当调小 |
hvigor.daemon |
启用守护进程，重用 JVM/Node 进程，减少启动开销 | 默认开启，不要手动关闭 |
| 优化方向 | 关键操作 | 预期效果 |
|---|---|---|
| 编译配置 | 开启 noEmitJs, enableMemoryCache, incremental.optimization |
减少内存/IO，加速增量 |
| 依赖方式 | 稳定层发布 HAR，多模块共享换 HSP | 减少连锁缓存失效，避免重复打包 |
| 项目结构 | 消除循环依赖，控制模块大小 | 减少非必要重编译 |
| 环境 | 大内存、SSD、多核 CPU，守护进程常驻 | 提升整体吞吐量 |
可以考虑从下面的几个配置来进行优化
| 配置项 | 值 | 说明 |
|---|---|---|
hvigor.enableMemoryCache |
true |
是否开启内存缓存。开启后占用内存更多但构建更快；关闭后内存占用减少但编译时间增加4 |
hvigor.pool.cache.capacity |
4 |
内存缓存数据量，值越低内存中缓存数据越少4 |
hvigor.pool.maxSize |
CPU核数-1 | 线程池大小，包含 ohos.arkCompile.maxSize，值越小占用内存越少4 |
ohos.arkCompile.maxSize |
5 |
ArkTS 编译阶段最大并发任务数，值越小占用内存越少4 |
nodeOptions.maxOldSpaceSize |
4096 |
守护进程 Node.js 堆内存大小（MB），大型项目可适当增大 |
至于你说HAR 模块之间的依赖关系声明是否会影响构建缓存的命中，答案是会影响，而且是显著影响的。
首先当 HAR A 依赖 HAR B 时，HAR A 的编译任务会依赖 HAR B 的编译任务。这意味着： HAR B 的任何变更都会导致 HAR A 的任务输入发生变化，HAR A 的构建缓存失效，必须重新编译，依赖链越长，一个底层 HAR 的变更引发的级联重编译范围越大。
其次依赖关系影响增量判断的输入范围： 增量构建的核心机制是检测任务的输入输出是否变化。HAR 模块的依赖声明会作为下游模块编译任务的隐式输入：如果 HAR B 的产物（.har 文件）发生了变化，所有依赖 HAR B 的模块都会判定为输入变更，缓存不命中，即使 HAR B 只是修改了内部实现而接口未变，下游模块的缓存同样会失效
还有就是不必要的依赖声明也会导致缓存命中率下降，比如： 冗余依赖：如果模块 A 声明了依赖 HAR B，但实际上并未使用，那么 HAR B 的任何变更都会导致模块 A 无谓地重新编译 传递依赖膨胀：HAR A → HAR B → HAR C 的链式依赖中，HAR C 的变更会级联影响 HAR B 和 HAR A10 循环依赖风险：虽然 DAG 不允许循环，但隐式的循环引用可能导致增量判断异常
针对大型鸿蒙项目hvigor构建慢，系统性优化手段包括：
- 启用hvigor增量编译和并行构建（配置
parallel参数）。 - 使用模块化架构，分离独立模块，减少全量编译。
- 配置build-cache（本地/远程缓存），复用中间产物。
- 调整Gradle守护进程参数（增大内存
-Xmx）。 - 精简依赖，避免多版本冲突导致的重复解析。
- 使用DevEco Studio的构建分析工具定位瓶颈。
在大型项目中，hvigor 构建慢主要可从三个层面优化：
1. hvigor-config.json5 关键配置项
parallel: 设为true开启多模块并行构建。incremental: 设为true启用增量编译，仅重新构建变动部分。daemon: 启用 hvigor 守护进程，减少冷启动开销。maxWorkers: 控制并行任务数，可根据 CPU 核心数调整（建议 ≤ 物理核心数）。buildCache: 设为true启用全局构建缓存，加速重复构建。
2. HAR 依赖关系对缓存的影响
HAR 模块间的依赖声明直接影响缓存命中。若依赖通过源码直接引用而非产物，任何上游模块的任意文件变更都会导致下游模块缓存失效，触发全量重编。建议：
- 将稳定、不常变动的 HAR 以二进制产物方式依赖（如通过 ohpm 仓库），减少级联重编。
- 避免循环依赖，维持单向依赖链，使增量构建能准确计算影响范围。
3. 系统性优化手段
- 拆分模块：按业务稳定度分层，将高频变动代码隔离在叶子模块。
- 编译配置精简：关闭未使用的编译选项（如 lint、混淆在开发阶段关闭）。
- 硬件资源：为 DevEco Studio 分配足够内存（hvigor 守护进程堆内存可在 gradle.properties 调整）。
- 远程构建缓存：多人团队可通过共享缓存避免重复构建。
