harmonyOS 原来构建还有这么多弯弯绕绕

• 启用增量构建: 增量构建是hvigor执行任务的一种优化，只对发生变化的部分进行编译，而不是整个项目。如果在两次执行任务工程中，执行任务的输入和输出没有更改，hvigor会跳过该任务的执行。

# 启用增量构建 hvigorw--incremental

# 关闭增量构建 hvigorw--no-incremental

• 并行编译：大部分工程都包含了多个子工程，其中一些子工程是相互独立的，也就是说，它们之间没有状态共享。在大多数情况下，通过并行构建可以有效地减少多个子工程的整体构建时间。默认情况下，hvigor会开启并行执行

# 启用并行执行 hvigorw--parallel 

# 关闭并行执行 hvigorw--no-parallel

• 启动守护进程：将进程常驻在内存中，一方面避免了Node进程重复启动、减少了加载js文件的耗时，另一方面可以复用构建过程中的增量缓存、减少增量缓存信息的读取与落盘操作。重复构建同一项目时，守护进程可以将构建时间缩短。多次构建时，守护进程只会将hvigor一次性加载到内存中，而不是每一次构建。

# 启用守护进程 hvigorw--daemon 

# 关闭守护进程 hvigorw--no-daemon

根据业务场景，合理配置增量/并行编译、开启守护进程，可以降低约 60% 的构建耗时

2. 模块化编译构建

为了提升HarmonyOS应用的开发效率和开发者体验，DevEco Studio引入了模块化编译方式，以优化传统的JSBundle化编译方案。以往的方案会为每个入口页面打包成一个独立的bundle包，不支持运行时共享，因此每当修改单个模块文件时，需要进行整包重新编译。这不仅增加了编译时间，也导致HAP包体积增大，影响开发效率。

模块化编译通过以下方式解决这些问题：

• 独立编译：模块之间相互独立编译，避免了不必要的整包重编译，从而显著加快了编译速度。

• 动态共享包（HSP）：支持将多个模块的通用能力和资源提取为动态共享包，供其他模块或应用使用，减少了包体积。

• 原生ES Module规则：采用原生ES Module规则构建源码，解决了Bundle编译打包模式带来的问题，使资源文件可以以独立模块形式进行编译。

通过这些优化，开发者在修改单个模块代码时，无需整包编译，减少了编译的代码量，加快了增量编译速度，从而提升了整体开发效率和体验。需要注意的是，模块化设计的复杂性可能增加管理成本，因此开发者需要平衡好模块化的粒度。

3. 降低应用包体积

• 配置so压缩选项减小应用包大小，在DevEco Studio中修改应用模块配置文件（如 module.json5 ）中的 compressNativeLibs 字段，将其值设置为true。这样在打包应用时，so库文件将以压缩形式被打包到包中，从而减小应用包的大小

• 通过修改应用模块配置文件module.json5 中的compressNativeLibs字段为true来压缩原生库，从而进一步减少应用体积

• 使用压缩工具减小图片和音频文件的大小，并使用SVG等矢量格式代替位图图标。此外，删除项目中未被引用的资源文件也是优化资源文件的有效方法

• 共享代码和资源：通过HSP（Harmony Shared Package）共享代码和资源，避免重复，进一步优化应用的资源管理

• 启用混淆, HarmonyOS NEXT支持多种代码混淆工具，主要通过Gradle构建工具进行配置。在工程应用目录的gradle文件中设置minifyEnabled为true即可开启混淆。此外，HarmonyOS NEXT还支持ArkTS、TS和JS文件的混淆。在模块级的 build.gradle 文件中的 buildTypes 部分添加以下代码，确保在发布版本中启用混淆具体配置方法如下：

   buildTypes {
       release {
           minifyEnabled true
           proguardFiles getDefaultProguardFile('proguard-android-optimize.txt '), 'proguard-rules.pro'
       }
   }

4. 优化库管理加速构建

为了进一步优化长时间的构建我们还可以通过采用动态共享包（HSP）和静态共享包（HAR）的策略提升构建效率。动态共享包（HSP） 通过按需加载减少了不必要的编译时间，而静态共享包（HAR）在模块间实现了高效的资源共享。这些方法在实际项目中表现也足够出色，能够有效优化构建流程。

• 选择合适的共享包类型

?当需要在应用内部进行代码和资源共享时，建议使用HSP。它可以包含代码、C++库、资源和配置文件，但不支持独立发布，需随宿主应用一起发布。HSP通过按需加载，减少不必要的编译时间，提高构建效率。

?当共享包作为应用模块的依赖项被引用时，应选择HAR。它同样可以包含代码、C++库、资源和配置文件，适合用于通用组件的共享。HAR通过高效资源共享，优化了模块间的依赖管理，进一步缩短构建周期。

• 多任务窗口与依赖管理

?在多任务窗口场景中，HSP通过与宿主应用同进程运行，实现了更高效的资源管理和调用。这种方式不仅减少了资源加载的延迟，还优化了内存使用，使应用在多任务环境下更流畅地运行。此外，按需加载的特性进一步提升了应用启动速度。

?HAR在跨多个应用或模块的资源共享中表现出色。其模块化设计允许独立发布和管理，确保资源在不同应用间的高效共享。这种方法减少了重复资源的存在，降低了整体包体积，并简化了依赖管理，适合频繁更新和维护的复杂项目。通过优化资源的重用和依赖关系，提高构建效率。

• 懒加载技术的应用

?懒加载技术（如LazyForEach），是一种按需加载数据或资源的策略。通过按需加载数据或资源，懒加载避免了在构建初期加载所有内容，从而减少了构建时间和资源消耗。这种方法有效降低了编译时的负担，使得构建过程更加高效。此外，懒加载减少了不必要的库加载，优化了依赖管理，进一步缩短了构建周期。

5. 性能可视化检验成果

使用Build Analyzer工具会在每次构建应用时默认生成一份报告，可以记录任务执行耗时、线程、ArkTS编译中的各环节的细分耗时情况等信息，开发者可以通过这些数据分析排查构建过程中的性能问题。

• 通过命令行生成构建分析

hvigorw assembleHap --analyze=normal --config properties.hvigor.analyzeHtml=true

• 通过hvigor-config.json5配置中properties.hvigor.analyzeHtml字段生成构建可视化html文件

"properties": { "hvigor.analyzeHtml": true // 生成构建可视化html文件 }

构建任务时间图谱，构建任务展示按照各个任务总时长占比，以相对长度进行展示。可以对时间块进行缩小放大，查看具体的任务名称及耗时信息。

6. 不止于此

通过一系列优化策略，我们显著提升了超级APP的构建效率。首先，通过模块化设计，将应用拆分为多个独立模块，减少了构建时的耦合，并提高了并行处理能力。其次，利用Hvigor的增量和并行编译特性，仅对代码变更部分进行编译，大幅缩短了构建时间。缓存机制的合理配置减少了重复数据加载，优化了资源访问速度。同时，压缩和混淆代码、优化图片和音频文件、删除未使用资源等措施有效减小了应用包体积。共享代码与懒加载技术进一步优化了资源管理。借助Build Analyzer工具，我们能够实时监控和分析构建过程，快速识别和解决性能瓶颈。除此之外，通过自定义插件和构建任务，我们灵活调整了构建流程，进一步提升了效率。这些措施不仅缩短了构建时间，还提高了开发效率和产品迭代速度，使开发团队能够更快速地响应市场需求和用户反馈，确保应用的高效交付和稳定性。