鸿蒙应用开发中hvigor构建系统的模块过滤实践

1. 项目背景与需求解析

在鸿蒙应用开发过程中，我们经常会遇到一个典型场景：为了演示功能或测试组件，开发者通常会在项目目录下创建大量demo模块。这些模块对于开发调试阶段非常有用，但当应用准备上架时，它们就变成了"包袱"——不仅增加了安装包体积，还可能包含仅供演示的非必要代码，影响应用审核通过率。

以我最近参与的一个电商类鸿蒙应用为例，项目结构中包含了12个演示模块，每个模块平均占用1.2MB空间。如果不做处理直接打包，最终APK体积会无故增加近15MB。更麻烦的是，这些demo模块可能引用了一些仅用于演示的测试API，导致应用商店审核不通过。

传统解决方案是手动删除demo目录，但这种方法存在明显缺陷：

1. 开发过程中需要频繁切换demo模块的包含状态
2. 团队协作时容易因操作不一致导致构建结果差异
3. 无法灵活控制不同构建变体（如debug/release）的模块包含策略

鸿蒙的hvigor构建系统提供了更优雅的解决方案——通过工程级hvigorfile.ts配置文件，我们可以实现构建时的智能模块过滤。这种方案的优势在于：

• 配置一次即可持续生效
• 不影响开发阶段的模块引用
• 可以基于条件逻辑动态控制过滤规则

2. 工程结构与构建流程分析

2.1 典型鸿蒙项目结构

先来看一个标准的包含demo模块的鸿蒙项目目录树：

code复制MyHarmonyApp/
├── entry/                  # 主模块
│   └── src/main/ets/       # 主代码目录
├── feature/                # 功能模块
│   └── payment/            # 支付功能模块
├── demo/                   # 演示模块目录
│   ├── cart-demo/          # 购物车演示
│   ├── product-demo/       # 商品展示演示
│   └── checkout-demo/      # 结算流程演示
└── build-profile.json5     # 构建配置文件

关键点在于build-profile.json5中的modules配置，它定义了哪些模块应该参与构建：

json5复制{
  "modules": [
    {
      "name": "entry",
      "srcPath": "./entry"
    },
    {
      "name": "feature_payment",
      "srcPath": "./feature/payment" 
    },
    {
      "name": "demo_cart",
      "srcPath": "./demo/cart-demo"
    }
    // 其他demo模块...
  ]
}

2.2 hvigor构建流程解析

鸿蒙的构建系统hvigor在执行时会经历几个关键阶段：

1