Harmony中的HAP、HAR、HSP区别
HarmonyOS中的HAP、HAR、HSP区别详解
1. 基本概念
HAP (Harmony Ability Package)
- 定义：应用安装和运行的基本单元
- 特点：
- 包含代码、资源、第三方库及配置文件
- 支持声明Ability和Page
- 分为Entry（主模块）和Feature（特性模块）两种类型
HAR (Harmony Archive)
- 定义：静态共享包
- 特点：
- 编译态复用
- 不支持声明Ability和Page
- 适用于二三方库共享
HSP (Harmony Shared Package)
- 定义：动态共享包
- 特点：
- 运行时复用
- 仅支持声明Page
- 适用于多模块共用及元服务分包预加载
2. 功能对比
| 特性 | HAP | HAR | HSP |
|---|---|---|---|
| 独立安装运行 | ✓ | ✗ | ✗ |
| 声明Ability | ✓ | ✗ | ✗ |
| 声明Page | ✓ | ✗ | ✓ |
| 编译时复用 | ✗ | ✓ | ✗ |
| 运行时复用 | ✗ | ✗ | ✓ |
| 支持ExtensionAbility | ✓ | ✗ | ✗ |
3. 使用场景推荐
HAP推荐场景：
- 主模块（Entry）：实现应用的入口界面、图标和主功能
- 特性模块（Feature）：实现应用的动态特性功能，支持按需下载安装
HAR推荐场景：
- 作为二方库发布到OHPM私仓，供公司内部使用
- 作为三方库发布到OHPM中心仓，供其他应用依赖使用
- 不需要运行时动态加载的共享代码和资源
HSP推荐场景：
- 多模块共用的代码和资源，提高可重用性和可维护性
- 元服务分包预加载
- 需要运行时动态加载的场景
4. 选择原则
- 是否需要独立运行：
- 需要 → 选择HAP
- 不需要 → 考虑HAR或HSP
- 复用时机需求：
- 编译时需要复用 → 选择HAR
- 运行时需要复用 → 选择HSP
- 是否需要声明Ability：
- 需要 → 必须使用HAP
- 不需要 → 考虑HAR或HSP
- 性能与包体积考虑：
- 注重启动性能 → 优先考虑HAR（减少运行时加载）
- 注重包体积优化 → 优先考虑HSP（避免重复打包）
5. 技术特点对比
HAP特点：
- 是应用安装的基本单位
- 可以包含UIAbility和ExtensionAbility
- 支持多设备适配
- 可以独立发布到应用市场
HAR特点：
- 代码和资源会跟随使用方编译
- 如果有多个使用方，会存在多份相同拷贝
- 支持应用内引用，也可以独立发布供其他应用引用
- 编译时建议开启混淆保护代码资产
HSP特点：
- 代码和资源可以独立编译
- 运行时进程中只存在一份
- 一般随应用打包，支持应用内和集成态
- 与宿主应用同进程，具有相同的包名和生命周期
6. 开发注意事项
- HAR限制：
- 不支持循环依赖
- 不支持依赖传递
- 不支持在配置文件中声明ExtensionAbility组件
- HSP限制：
- 不支持独立安装/运行
- 版本号必须与依赖它的HAP一致
- 不支持具有入口能力的UIAbility（如配置了home action）
- HAP限制：
- 同一设备类型的所有HAP中必须有且只有一个Entry类型的HAP
- 所有HAP的签名证书要保持一致
7. 实际应用示例
典型工程结构：
MyApplication
├── entry (HAP主模块)
├── feature (HAP特性模块)
├── library (HAR静态共享库)
└── shared (HSP动态共享库)
资源引用方式：
- HAP内资源：$r(‘app.type.name’)
- HAR资源：通过HAR导出的资源管理类访问
- HSP资源：通过createModuleContext获取资源管理器
总结
HAP、HAR和HSP是HarmonyOS应用开发的三种重要模块类型，各有其特点和适用场景。合理选择和使用这些模块类型，能够有效提高代码复用率、优化应用性能、减小包体积，并实现更灵活的模块化管理。开发者应根据具体业务需求、性能要求和团队协作方式，选择最适合的模块类型组合。