对于任何鸿蒙应用开发者来说，App、HAP、HAR、HSP 这四个概念是绕不开的基础，也是构建一个结构清晰、性能优异的鸿蒙应用的基石。

简单来说，它们的关系可以这样理解：App 是最终上架和安装在用户手机上的完整应用，而 HAP、HAR 和 HSP 则是组成这个 App 的、不同角色和性质的“积木块”。

下面我将为你逐一拆解。

---

一、App Pack：最终呈现在用户面前的形态

App Pack（应用程序包）就是我们通常意义上所说的“应用安装包”。当开发完成后，需要将应用上架到华为应用市场时，所有编译产物（HAP、HSP等）会统一打包成一个以 .app 为后缀的文件，这个文件就是 App Pack。

关键特性：

• 发布形态：它是应用发布和分发的最终格式，只用于上架应用市场。

• 不可直接安装：.app 文件并不能直接发给用户安装到设备上，它需要经过应用市场的解析和处理。

• 内部包含：一个 App Pack 内部包含了应用所需的一个或多个 HAP 包以及 HSP 包。

在开发过程中，App 更像一个“容器”或“项目”的概念，代表你正在开发的整个应用。

---

二、HAP：应用运行的基本单元

HAP（Harmony Ability Package）是应用安装和运行的基本单元。一个 App 可以包含一个或多个 HAP。HAP 包是代码、资源、第三方库和配置文件的集合体。

根据功能和角色，HAP 分为两种类型：

1. Entry 类型 HAP

• 定义：应用的主模块，是应用的入口。

• 作用：它包含了应用启动图标、应用的基础和核心功能。

• 特性：一个应用中，对同一种设备类型，必须有且仅有一个 Entry 类型的 HAP。它具备独立安装运行的能力。

2. Feature 类型 HAP

• 定义：应用的动态特性模块，用于扩展应用的能力。

• 作用：用于承载应用的附加功能，如支付模块、直播模块、特定活动页面等。

• 特性：一个应用可以包含零个或多个 Feature 类型的 HAP。Feature HAP 最大的特点是可按需安装。通过在 module.json5 文件中将 deliveryWithInstall 设置为 false，该模块便不会在应用首次安装时下载，而是当用户需要使用时（例如点击某个功能入口），才从应用市场动态加载，从而达到为应用“瘦身”的目的。

---

三、HAR 与 HSP：代码复用的两种方式

在开发过程中，我们通常会抽取公共代码或组件以便复用。HarmonyOS 提供了两种共享包：HAR（静态共享包）和 HSP（动态共享包）。它们的核心区别在于复用时机和对包大小的影响。

1. HAR（Harmony Archive）：静态共享包

HAR 是静态共享包，可以理解为代码和资源的“拷贝粘贴”式复用。

• 工作机制：当模块 A 引用了 HAR 包，在编译时，这个 HAR 包中的代码和资源会被完整地复制一份到模块 A 的编译产物（HAP 或 HSP）中。如果模块 B 也引用了同一个 HAR，那么同样的副本也会被打包进模块 B。

• 优点：由于代码在编译时就已集成，所以运行时的加载效率非常高，无需额外开销。

• 缺点：如果多个模块引用同一个 HAR，会导致应用包体积显著增大（代码冗余）。

• 适用场景：

  • 发布到公共仓库：作为二方库（公司内部 OHPM 私仓）或三方库（OHPM 中心仓）供其他应用使用。

  • 基础工具库：比如网络请求封装、通用工具函数、UI 组件库等，如果它们只被一两个模块引用，使用 HAR 是最佳选择，因为它效率最高且没有动态加载的复杂性。

2. HSP（Harmony Shared Package）：动态共享包

HSP 是动态共享包，实现了代码和资源的“运行时共享”。

• 工作机制：无论有多少个模块（HAP 或 HSP）引用了同一个 HSP，在打包时，这个 HSP 只会保留一份。在运行时，所有引用它的模块共享这唯一的一份代码和资源实例，内存中也只存在一份。

• 优点：能有效减小应用最终的包体积，并节省运行时内存。

• 缺点：

  • 动态加载会带来一些性能开销（查找、加载、初始化）。

  • 不支持独立发布，必须随宿主应用（HAP）一起打包和安装。

  • 不能声明 UIAbility 或 ExtensionAbility 组件。

• 适用场景：

  • 多模块共享的公共能力：当一个公共模块（如登录组件、分享组件）被多个 HAP 或 HSP 引用时，使用 HSP 可以避免代码冗余，是优化包体积的最佳选择。

  • 按需加载的大功能模块：虽然 HAP 支持按需加载，但如果你有一个内部功能模块（不能独立运行，只是一个功能集）也需要按需加载，HSP 是更好的选择。

---

总结与选择指南

为了更直观地对比，这里汇总了一张表格：

特性维度	HAP	HAR	HSP
全称	Harmony Ability Package	Harmony Archive	Harmony Shared Package
核心角色	应用的功能模块	静态共享包	动态共享包
复用方式	独立存在	编译时拷贝，多副本	运行时共享，单实例
能否独立安装运行	是 (Entry/Feature)	否	否
可包含UIAbility	是	否	否
可包含 pages 页面	是	是 (通过命名路由)	是
对应用包大小影响	基础大小	增大 (多引用会膨胀)	减小 (避免重复)
典型使用场景	应用入口、核心功能、按需加载特性	基础工具库、公司内部/公开的SDK	被多个模块共享的公共UI组件、业务逻辑

信息综合自

如何选择？（核心建议）

1. HAP 的选择：

   • Entry HAP：每个项目都必须有。

   • Feature HAP：当一个功能模块非常大，或者你希望它具备独立的按需分发能力（例如，只有部分用户或特定设备才需要使用），且该功能可以独立运行（有自己的 Ability 入口），那么选择 Feature HAP。

2. HAR vs. HSP 的选择：

   • 优先考虑 HAR：对于大多数情况下的代码复用，尤其是工具类、数据模型、纯逻辑组件，以及需要发布到 OHPM 仓库供他人使用的库，应该优先选择 HAR。它的实现简单，调试方便，且加载效率最高。

   • 考虑使用 HSP：当一个公共模块被多个 HAP/HSP 频繁引用，并且你非常在意应用包体积时，应该使用 HSP。一个典型的例子是，当你的应用采用了多 HAP 架构，并且这些 HAP 都需要引用同一个登录或支付页面时，HSP 是唯一的正确选择。