【HarmonyOS 5应用架构详解】深入理解应用程序包与多Module设计机制

⭐本期内容：【HarmonyOS 5应用架构详解】深入理解应用程序包与多Module设计机制
🏆系列专栏：鸿蒙HarmonyOS：探索未来智能生态新纪元

---

---

前言

HarmonyOS 5的应用程序包不仅仅是简单的代码集合，而是一个完整的软件分发和部署单元，包含了应用运行所需的所有元素。应用程序包的核心价值在于其模块化的组织方式，这种方式不仅提高了开发效率，还为分布式场景下的应用部署提供了强大的支持。通过精心设计的包结构，HarmonyOS能够实现按需加载、动态更新以及跨设备协同等高级功能。

---

应用与应用程序包

应用程序的基本概念

“应用”（Application）是指提供给用户的一组功能集合，用户可以通过应用获取服务和体验。每个应用都有其独特的业务逻辑和用户界面，为用户提供特定的功能和服务。而"应用程序包"则是应用的部署和分发单元，是应用在设备上安装和运行的基础。

应用程序包的类型

HarmonyOS的应用程序包主要有两种类型：

• HAP（Harmony Ability Package）是模块级的部署单元，包含特定模块的代码、资源和配置。每个HAP包都是一个独立的功能单元，可以包含一个或多个Ability，以及相关的资源文件和配置信息。
• APP（Application Package）是应用级的分发单元，由一个或多个HAP文件组成。当用户从应用市场下载应用时，实际下载的就是APP包，系统会自动解析并安装其中包含的所有HAP包。

标识机制

每个HAP包都由唯一的Bundle Name（应用包名）和Module Name（模块名）共同标识。

Bundle Name在整个系统中唯一标识一个应用，遵循反向域名命名规范，确保全局唯一性。Module Name则在应用内部唯一标识一个模块，使得同一应用的不同模块可以被准确区分和管理。

// 在app.json5中定义应用级配置
{"app": {"bundleName": "com.example.myapplication","vendor": "example","versionCode": 1000000,"versionName": "1.0.0","icon": "$media:layered_image","label": "$string:app_name","minAPIVersion": 12,"targetAPIVersion": 12}
}

应用安装流程

当用户从应用市场下载一个HarmonyOS应用时，实际上下载的是一个.app文件。系统接收到这个文件后，会进行以下处理步骤：

1. 解析APP包的结构和元数据。
2. 提取其中包含的所有HAP包。
3. 验证每个HAP包的完整性和签名。
4. 将HAP包安装到设备的相应位置并注册到系统中。

完整项目结构

一个标准的HarmonyOS应用项目具有清晰的目录结构，每个目录都有其特定的用途和功能：

MyHarmonyApp/
├── AppScope/                    // 应用级作用域
│   ├── app.json5               // 应用级配置文件
│   └── resources/              // 应用级资源
│       ├── base/               // 基础资源
│       │   ├── element/        // 基础元素资源
│       │   │   └── string.json // 字符串资源
│       │   ├── media/          // 媒体资源
│       │   │   └── app_icon.png// 应用图标
│       │   └── profile/        // 配置文件
│       └── en_US/              // 英文资源
├── entry/                      // 入口模块
│   ├── src/                    // 源代码目录
│   │   ├── main/               // 主要代码
│   │   │   ├── ets/            // ArkTS代码
│   │   │   │   ├── entryability/
│   │   │   │   │   └── EntryAbility.ets // 入口Ability
│   │   │   │   ├── entrybackupability/
│   │   │   │   │   └── EntryBackupAbility.ets // 备份Ability
│   │   │   │   └── pages/      // 页面代码
│   │   │   │       └── Index.ets // 首页
│   │   │   ├── resources/      // 模块资源
│   │   │   │   ├── base/       // 基础资源
│   │   │   │   │   ├── element/
│   │   │   │   │   │   ├── color.json // 颜色资源
│   │   │   │   │   │   └── string.json// 字符串资源
│   │   │   │   │   ├── media/  // 媒体资源
│   │   │   │   │   │   ├── layered_image.json
│   │   │   │   │   │   └── startIcon.png
│   │   │   │   │   └── profile/
│   │   │   │   │       ├── main_pages.json // 页面配置
│   │   │   │   │       └── backup_config.json // 备份配置
│   │   │   │   └── en_US/      // 英文资源
│   │   │   └── module.json5    // 模块配置文件
│   │   └── ohosTest/           // 测试代码
│   ├── build-profile.json5     // 构建配置
│   └── hvigorfile.ts          // 构建脚本
├── build-profile.json5         // 应用构建配置
└── hvigorfile.ts              // 应用构建脚本

应用的多Module设计机制

多Module设计的核心理念

HarmonyOS 5采用多Module设计机制，允许开发者将应用程序分解为多个功能模块。

多Module设计的优势

• 功能解耦：多Module设计的首要优势。通过将不同功能分离到不同模块中，可以有效减少代码之间的耦合度。
• 按需加载：用户只需下载和安装必要的模块，大大节省了设备的存储空间。对于功能丰富的大型应用，用户可以根据自己的需求选择安装特定的功能模块，避免了不必要的资源浪费。
• 团队协作：不同的开发团队可以并行开发不同的模块，每个团队专注于自己负责的功能领域，减少了团队之间的依赖和冲突，显著提高了整体的开发效率。
• 可维护性：当需要修复bug或添加新功能时，开发者可以快速定位到相关模块，进行精确的修改。
• 适应分布式场景：不同模块可以更容易地适配和部署到不同类型的设备上。

多Module应用结构

模块化设计的完整架构：

MyHarmonyApp/
├── AppScope/                   // 应用级作用域
│   └── resources/             // 全局资源文件
│       ├── base/              // 基础资源
│       │   ├── element/       // 全局元素资源
│       │   ├── media/         // 全局媒体资源
│       │   └── profile/       // 全局配置文件
│       └── rawfile/           // 原始文件资源
├── entry/                     // 入口模块
│   ├── src/
│   │   ├── main/
│   │   │   ├── ets/           // ArkTS代码
│   │   │   │   ├── entryability/
│   │   │   │   ├── pages/     // 页面代码
│   │   │   │   └── common/    // 通用代码
│   │   │   ├── resources/     // 模块资源
│   │   │   └── module.json5   // 模块配置
│   │   └── ohosTest/          // 测试代码
│   ├── build-profile.json5    // 构建配置
│   └── hvigorfile.ts         // 构建脚本
├── feature_module/            // 功能模块
│   ├── src/
│   │   ├── main/
│   │   │   ├── ets/
│   │   │   ├── resources/
│   │   │   └── module.json5
│   │   └── ohosTest/
│   ├── build-profile.json5
│   └── hvigorfile.ts
├── common_library/            // 公共库模块
│   ├── src/
│   │   ├── main/
│   │   │   ├── ets/
│   │   │   │   ├── utils/     // 工具类
│   │   │   │   ├── constants/ // 常量定义
│   │   │   │   └── components/// 公共组件
│   │   │   └── resources/
│   │   └── ohosTest/
│   ├── build-profile.json5
│   └── hvigorfile.ts
├── build-profile.json5        // 应用构建配置
├── hvigorfile.ts             // 应用构建脚本
└── oh-package.json5          // 依赖管理文件

Module类型

Entry Module（入口模块）

Entry Module是应用的主要入口点，承担着应用启动和主要业务流程的重要职责。它包含应用的主界面和核心业务逻辑，是用户与应用交互的主要入口。

为了确保应用启动的唯一性和一致性，一个应用必须且只能有一个Entry Module。

{"module": {"name": "entry","type": "entry","srcEntry": "./ets/entryability/EntryAbility.ets","mainElement": "EntryAbility","description": "$string:module_desc","abilities": [{"name": "EntryAbility","srcEntry": "./ets/entryability/EntryAbility.ets","description": "$string:EntryAbility_desc","icon": "$media:icon","label": "$string:EntryAbility_label","startWindowIcon": "$media:icon","startWindowBackground": "$color:start_window_background","exported": true,"skills": [{"entities": ["entity.system.home"],"actions": ["action.system.home"]}]}]}
}

Feature Module（功能模块）

Feature Module提供特定功能的独立模块，可以被Entry Module或其他Feature Module调用。一个应用可以包含零个或多个Feature Module，这种设计使应用可以根据业务需求灵活组织功能模块。

Feature Module具有高度的独立性，可以包含自己的UI界面、业务逻辑和资源文件。

{"module": {"name": "payment","type": "feature","srcEntry": "./ets/paymentability/PaymentAbility.ets","description": "$string:payment_module_desc","abilities": [{"name": "PaymentAbility","srcEntry": "./ets/paymentability/PaymentAbility.ets","description": "$string:PaymentAbility_desc","icon": "$media:payment_icon","label": "$string:payment_name","exported": false,"skills": [{"entities": ["entity.system.default"],"actions": ["action.system.payment"]}]}],"extensionAbilities": [{"name": "PaymentExtension","srcEntry": "./ets/paymentextension/PaymentExtension.ets","type": "service","description": "$string:PaymentExtension_desc"}]}
}

Shared Module（共享模块）

Shared Module是一种特殊类型的模块，专门用于包含可以被多个模块共享的代码和资源。它不会直接作为应用的可执行部分安装到设备上，而是作为其他Module的依赖被引用和使用。

Shared Module的主要价值在于代码复用和资源共享。

将通用的工具类、组件、常量定义等放在Shared Module中，可以避免代码重复，提高开发效率，同时也便于统一维护和更新这些共享资源。

{"module": {"name": "common","type": "shared","srcEntry": "./index.ets","description": "$string:common_module_desc"}
}

对应的index.ets文件通常会导出模块的公共接口：

// index.ets - Shared Module的入口文件
export { Logger } from './src/main/ets/utils/Logger'
export { HttpUtil } from './src/main/ets/utils/HttpUtil'
export { Constants } from './src/main/ets/constants/Constants'
export { CommonButton } from './src/main/ets/components/CommonButton'
export { DateUtil } from './src/main/ets/utils/DateUtil'

模块间依赖关系

在多Module应用中，模块间的依赖关系需要在oh-package.json5文件中明确声明：

{"dependencies": {"common": "file:../common"}
}

---

总结

模块化系统中，各类模块各司其职：Entry Module担任应用入口，Feature Module封装独立功能，Shared Module实现资源共享。三者协同运作，共同构建出灵活高效、易于维护的应用架构。

若存疑问，欢迎随时交流探讨！