HarmonyOS之深入理解HAP和HSP

一、HAP（Harmony Ability Package）核心功能

1. 基础定义

• 定位：应用安装和运行的基本单元，由代码、资源、配置文件等组成。
• 类型：
  • Entry HAP：主入口模块，必须唯一，提供基础功能（如应用启动页）。
  • Feature HAP：动态特性模块，按需安装（如电商App的支付模块）。

2. 关键能力

• 独立运行：支持单独安装和更新。
• 多设备适配：通过module.json5声明设备类型（如"deviceTypes": ["phone", "tablet"]）。

3. 使用场景

• 单设备核心功能：如微信聊天主界面（Entry HAP）。
• 按需加载模块：如美团的外卖功能（Feature HAP），用户使用时才下载。
• 多设备分发：为手机和平板提供不同的HAP包。

二、HSP（Harmony Shared Package）核心功能

1. 基础定义

• 定位：动态共享包，用于多模块间代码/资源复用，不可独立运行。
• 核心特性：
  • 运行时单例：同一进程内仅加载一份实例，减少内存占用。
  • 按需加载：延迟初始化提升启动性能。

2. 资源访问限制

// 错误：直接访问HSP资源会导致崩溃
const icon = $r('app.media.hsp_icon');

// 正确：通过模块上下文获取
const hspCtx = createModuleContext('com.example.shared');
const icon = hspCtx.resourceManager.getMedia($r('app.media.hsp_icon'));

• 资源隔离：需通过createModuleContext()获取资源管理器。

3. 使用场景

• 公共代码复用：网络请求工具类、自定义组件库。
• 资源优化：多模块共享图片/多语言资源（避免重复打包）。
• 性能敏感模块：弹窗组件等需动态加载的UI。

三、HAP vs HSP 核心差异对比

注：HSP的运行时共享机制可显著减少包体积。例如：将登录组件从HAR改为HSP后，包体积减少30%+。

四、实际应用决策指南

1. 何时选择HAP？

• 需独立运行：如应用首页（Entry HAP）或可拆卸功能模块（Feature HAP）。
• 多设备适配：为手机提供精简版，为平板提供完整版HAP。
• 含Ability组件：需后台任务或跨应用跳转时（如音乐播放服务）。

2. 何时选择HSP？

• 高频复用代码：工具类（如DateUtils）、网络请求库。
• 资源密集型模块：共享图片库、多语言文案。
• 动态加载需求：非首屏组件（如设置页）。

3. 混合架构最佳实践

• 分层设计：
  1. 基础层：HSP封装通用能力（日志、权限）。
  2. 业务层：HAP按功能拆分，依赖HSP。
  3. 资源层：独立HSP管理全局资源。

4. 性能与体积优化策略

• 包体积监控：单个HSP建议≤500KB，过大的HSP需拆解。
• 动态加载阈值：仅在模块>100KB时使用HSP，避免频繁加载小模块拖慢启动。
• HSP合并：将关联性强的工具类合并为单一HSP（如utils.hsp）。

五、决策流程图

graph LR
  A{需独立运行？} --是--> B[使用HAP]
  A --否--> C{需声明Ability？}
  C --是--> B
  C --否--> D{多模块复用？}
  D --否--> E[使用HAR]
  D --是--> F{包体积敏感？}
  F --是--> G[使用HSP]
  F --否--> E
  B --> H{是否主模块？}
  H --是--> I[Entry HAP]
  H --否--> J[Feature HAP]

关键原则：

• 功能隔离用HAP，代码复用用HSP；
• 包体积敏感场景优先HSP（如移动端应用）。

通过上述策略，可平衡应用性能、包体积与开发效率。初期建议采用 单HAP + 核心HSP 架构，逐步扩展至多HAP。