HarmonyOS 鸿蒙Next HAP、HAR和HSP包类型区别及选择

https://blog.csdn.net/yyz_1987/article/details/135715256

在开发中，一个应用包含一个或者多个Module，可以在DevEco Studio工程中创建一个或者多个Module。Module是应用/服务的基本功能单元，包含了源代码、资源文件、第三方库及应用/服务配置文件，每一个Module都可以独立进行编译和运行。Module分为“Ability”和“Library”两种类型，“Ability”类型的Module对应于编译后的HAP（Harmony Ability Package）；“Library”类型的Module对应于HAR（Harmony Archive），或者HSP（Harmony Shared Package）。

HAP是应用安装的基本单位，包含了编译后的代码、资源、三方库及配置文件。

每个应用可以包含多个.hap文件，一个应用中的.hap文件合在一起称为一个Bundle，而bundleName就是应用的唯一标识（请参见app.json5配置文件中的bundleName标签）。

HAP可分为Entry和Feature两种类型

HAR（Harmony Archive）是静态共享包，可以包含代码、C++库、资源和配置文件。通过HAR可以实现多个模块或多个工程共享ArkUI组件、资源等相关代码。

使用场景

• 支持应用内共享，也可以发布后供其他应用使用。
• 作为二方库，发布到OHPM私仓，供公司内部其他应用使用。
• 作为三方库，发布到OHPM中心仓，供其他应用使用。
• 多包（HAP/HSP）引用相同的HAR时，会造成多包间代码和资源的重复拷贝，从而导致应用包膨大。

约束限制

• HAR不支持在设备上单独安装/运行，只能作为应用模块的依赖项被引用。
• HAR不支持在配置文件中声明UIAbility组件与ExtensionAbility组件。
• HAR不支持在配置文件中声明pages页面，但是可以包含pages页面，并通过命名路由的方式进行跳转。
• HAR不支持引用AppScope目录中的资源。在编译构建时，AppScope中的内容不会打包到HAR中，因此会导致HAR资源引用失败。
• HAR可以依赖其他HAR，但不支持循环依赖，也不支持依赖传递。

HSP（Harmony Shared Package）是动态共享包，可以包含代码、C++库、资源和配置文件，通过HSP可以实现代码和资源的共享。HSP不支持独立发布，而是跟随其宿主应用的APP包一起发布，与宿主应用同进程，具有相同的包名和生命周期。

说明

应用内HSP：在编译过程中与应用包名（bundleName）强耦合，只能给某个特定的应用使用。

集成态HSP：构建、发布过程中，不与特定的应用包名耦合；使用时，工具链支持自动将集成态HSP的包名替换成宿主应用包名。

使用场景

• 多个HAP/HSP共用的代码和资源放在同一个HSP中，可以提高代码、资源的可重用性和可维护性，同时编译打包时也只保留一份HSP代码和资源，能够有效控制应用包大小。

• HSP在运行时按需加载，有助于提升应用性能。

• 同一个组织内部的多个应用之间，可以使用集成态HSP实现代码和资源的共享。

约束限制

• HSP不支持在设备上单独安装/运行，需要与依赖该HSP的HAP一起安装/运行。HSP的版本号必须与HAP版本号一致。
• HSP不支持在配置文件中声明ExtensionAbility组件，但支持UIAbility（除入口ability外）组件。
• HSP可以依赖其他HAR或HSP，但不支持循环依赖，也不支持依赖传递。

最后，简言之，如果只是开发应用，hap包供你开发调试即可。最终发布到应用市场需要打包为app包。

har库，方便你贡献提供三方库。

 hsp，方便你应用内自己共享。