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. 选择原则

1. 是否需要独立运行：
   • 需要 → 选择HAP
   • 不需要 → 考虑HAR或HSP
2. 复用时机需求：
   • 编译时需要复用 → 选择HAR
   • 运行时需要复用 → 选择HSP
3. 是否需要声明Ability：
   • 需要 → 必须使用HAP
   • 不需要 → 考虑HAR或HSP
4. 性能与包体积考虑：
   • 注重启动性能 → 优先考虑HAR（减少运行时加载）
   • 注重包体积优化 → 优先考虑HSP（避免重复打包）

5. 技术特点对比

HAP特点：

• 是应用安装的基本单位
• 可以包含UIAbility和ExtensionAbility
• 支持多设备适配
• 可以独立发布到应用市场

HAR特点：

• 代码和资源会跟随使用方编译
• 如果有多个使用方，会存在多份相同拷贝
• 支持应用内引用，也可以独立发布供其他应用引用
• 编译时建议开启混淆保护代码资产

HSP特点：

• 代码和资源可以独立编译
• 运行时进程中只存在一份
• 一般随应用打包，支持应用内和集成态
• 与宿主应用同进程，具有相同的包名和生命周期

6. 开发注意事项

1. HAR限制：
   • 不支持循环依赖
   • 不支持依赖传递
   • 不支持在配置文件中声明ExtensionAbility组件
2. HSP限制：
   • 不支持独立安装/运行
   • 版本号必须与依赖它的HAP一致
   • 不支持具有入口能力的UIAbility（如配置了home action）
3. 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应用开发的三种重要模块类型，各有其特点和适用场景。合理选择和使用这些模块类型，能够有效提高代码复用率、优化应用性能、减小包体积，并实现更灵活的模块化管理。开发者应根据具体业务需求、性能要求和团队协作方式，选择最适合的模块类型组合。