在鸿蒙生态中，一个应用从源代码到用户手机上的图标，会经历一个从工程代码到编译产物，再到上架分发的完整形态转变。理解过程中涉及的核心包结构——App（Application Package）、HAP（Harmony Ability Package）、HAR（Harmony Archive）和HSP（Harmony Shared Package），是进行模块化开发和应用架构设计的基石。

它们之间的关系可以简单概括为：HAP是应用运行的基本单元，HAR和HSP是代码复用的两种方式，而App则是最终上架市场的发布形态。

1. App Pack：上架市场的最终形态

App Pack（以.app为后缀）是鸿蒙应用上架到应用市场的唯一发布形态。它本身是一个“打包集合”，不能在设备上直接安装运行。

一个App Pack中通常包含一个或多个HAP文件（Entry类型必须有一个，Feature类型可有多个），以及可能存在的HSP文件。同时，它还会附带一个pack.info文件，用于描述包内每个HAP和HSP的属性信息。

核心要点：App Pack是面向分发市场的，而HAP/HSP才是面向设备安装和运行的实际单元。

2. HAP：应用安装与运行的基本单元

HAP（Harmony Ability Package）是鸿蒙应用安装和运行的基础单位。它包含编译后的代码、资源文件和配置文件。一个应用必须至少包含一个HAP。根据功能和角色的不同，HAP分为两种类型：

2.1 Entry 类型

• 角色：应用的主模块，是应用的唯一入口。

• 要求：对于同一种设备类型，一个App中有且只有一个Entry类型的HAP。

• 功能：通常包含应用的主界面、桌面图标以及启动图标，提供应用的基础核心功能。

2.2 Feature 类型

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

• 数量：一个App可以包含零个、一个或多个Feature类型的HAP。

• 核心价值：按需加载和跨设备适配。

  • 按需加载：通过将deliveryWithInstall配置为false，Feature HAP不会在应用首次安装时下载，而是在用户需要用到特定功能时才从应用市场动态获取，从而有效减小应用的初始安装包大小。例如，一个电商App可以将"直播"功能设计为Feature HAP，用户点击直播入口时才触发下载安装。

  • 跨设备适配：可以根据不同设备（如手机、手表、车机）的能力和硬件条件，分发不同的Feature HAP，实现灵活适配。

3. HAR vs HSP：两种代码共享包

在大型应用开发中，模块化是核心思想。HAR和HSP正是实现代码、资源、组件在不同模块间复用的两种“共享包”。它们的本质区别在于编译和运行时的加载机制不同，这直接决定了它们的使用场景。

3.1 HAR（Harmony Archive）：静态共享包

• 机制：静态复用。HAR在编译时，会将自身代码和资源完整地拷贝并打包到引用它的每个HAP或HSP包中。

• 特点：

  • 多副本：如果有多个模块引用了同一个HAR，那么每个模块的产物中都会有一份该HAR的独立副本，导致应用包体积增大（空间换时间）。

  • 高效率：由于代码在编译时已打入宿主包，应用启动后使用时无需额外加载步骤，直接调用，效率极高。

  • 可发布：HAR包可以独立发布到OHPM（OpenHarmony Package Manager）私仓或中心仓，供其他应用甚至公司外部使用。

• 适用场景：

  • 基础工具库、UI组件库：如网络请求封装、通用日期工具类、基础Button组件等。

  • 跨应用共享：需要将能力发布给公司内部其他应用或三方开发者使用的场景。

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

• 机制：动态复用。HSP在编译时会独立编译成一个单独的.hsp文件。当多个HAP引用同一个HSP时，在设备上只存在一份该HSP的代码实例，所有引用它的HAP在运行时共享这一份代码。

• 特点：

  • 单副本：有效避免代码重复，显著减小应用包体积（时间换空间）。

  • 按需加载：HSP可以在运行时按需加载，而不是在应用启动时全部加载，可以优化应用的启动速度。

  • 随应用发布：HSP目前主要支持应用内共享，必须随宿主应用一起打包和发布，不能独立分发。

• 适用场景：

  • 多个HAP/HSP共用的公共能力：当多个模块都需要使用同一套稳定的公共UI组件、工具类或Native库时，使用HSP能有效避免重复，减小包体积。

  • 需要按需加载的大功能模块：将一个不常用的但体积较大的功能封装为HSP，可以实现按需加载，优化启动性能。

总结与架构选择建议

在实际项目架构中，如何选择这几种包类型，可以参考以下策略：

1. HAP是必需品：任何应用都必须包含一个Entry类型的HAP作为入口。只有当应用功能足够复杂，需要按需加载或跨设备差异化部署时，才考虑拆分Feature类型的HAP。

2. 优先考虑HAR，审慎使用HSP：对于大多数代码复用场景，特别是基础工具类和UI组件，优先使用HAR，因为它调试简单，加载效率高。HSP虽然能节省空间，但会引入版本依赖、调试复杂等问题，应仅在多个模块确实需要共享同一份稳定代码（如公共登录模块、支付模块） 时使用。

3. 组合策略：当一个HAR被多个HAP或HSP依赖，导致包体积增长过快时，可以考虑将多个HAR组合并封装成一个HSP，供其他模块统一引用，从而在享受复用性的同时，利用HSP的单副本特性减小包体积。