【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则在应用内部唯一标识一个模块,使得同一应用的不同模块可以被准确区分和管理。

json 复制代码
// 在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。

json 复制代码
{
  "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界面、业务逻辑和资源文件。

json 复制代码
{
  "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中,可以避免代码重复,提高开发效率,同时也便于统一维护和更新这些共享资源。

json 复制代码
{
  "module": {
    "name": "common",
    "type": "shared",
    "srcEntry": "./index.ets",
    "description": "$string:common_module_desc"
  }
}

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

typescript 复制代码
// 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文件中明确声明:

json 复制代码
{
  "dependencies": {
    "common": "file:../common"
  }
}

总结

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

若存疑问,欢迎随时交流探讨!

相关推荐
BillKu7 分钟前
Vue3 + TypeScript 中 hook 优化记录
开发语言·javascript·typescript
移动端开发者1 小时前
鸿蒙Next显示动画animateTo介绍
harmonyos
移动端开发者1 小时前
鸿蒙Next使用AudioCapturer实现音频录制和AI语言转文字
harmonyos
移动端开发者1 小时前
鸿蒙Next选择按钮Toggle、Checkbox、Radio介绍
harmonyos
喻衡深1 小时前
解锁 TypeScript 魔法:递归类型实现字段路径自动推导
前端·typescript
掘金-我是哪吒2 小时前
分布式微服务系统架构第152集:JavaPlus技术文档平台日更
分布式·微服务·云原生·架构·系统架构
风铃喵游4 小时前
平地起高楼: 环境搭建
前端·架构
森焱森4 小时前
驱动开发,队列,环形缓冲区:以GD32 CAN 消息处理为例
c语言·单片机·算法·架构
Wgllss4 小时前
Kotlin + Flow 实现责任链模式的4种案例
android·架构·android jetpack
夜空孤狼啸5 小时前
前端常用拖拽组件库(vue3、react、vue2)
前端·javascript·react.js·typescript·前端框架·vue3