关于 HAP、HAR、 HSP、App

HAP

HAP（Harmony Ability Package）是应用安装和运行的基本单元。HAP包是由代码、资源、第三方库、配置文件等打包生成的模块包，其主要分为两种类型：entry和feature。

• entry：应用的主模块，作为应用的入口，提供了应用的基础功能。
• feature：应用的动态特性模块，作为应用能力的扩展，可以根据用户的需求和设备类型进行选择性安装。

应用程序包可以只包含一个基础的entry包，也可以包含一个基础的entry包和多个功能性的feature包。

使用场景

• 单HAP场景：如果只包含UIAbility组件，无需使用ExtensionAbility组件，优先采用单HAP（即一个entry包）来实现应用开发。虽然一个HAP中可以包含一个或多个UIAbility组件，为了避免不必要的资源加载，推荐采用“一个UIAbility+多个页面”的方式。
• 多HAP场景：如果应用的功能比较复杂，需要使用ExtensionAbility组件，可以采用多HAP（即一个entry包+多个feature包）来实现应用开发，每个HAP中包含一个UIAbility组件或者一个ExtensionAbility组件。在这种场景下，可能会存在多个HAP引用相同的库文件，导致重复打包的问题。

HAR

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

使用场景

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

HSP

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

说明：

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

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

使用场景

• 多个HAP/HSP共用的代码和资源放在同一个HSP中，可以提高代码、资源的可重用性和可维护性，同时编译打包时也只保留一份HSP代码和资源，能够有效控制应用包大小。
• HSP在运行时按需加载，有助于提升应用性能。
• 同一个组织内部的多个应用之间，可以使用集成态HSP实现代码和资源的共享。
• 元服务分包预加载、按需加载。

怎么理解App、HAP、HAR的关系

• App是个上架概念，多个HAP打包一起上架。
• HAP是可以独立运行、分发的，HAP不是复用的，复用的应该是HAR。
• HAR是静态共享包，每个模块依赖的话都会打包到HAP里。

har如何转换为hsp

HAR转为HSP主要是通过相关配置文件的修改实现的。具体方式可参考以下步骤：

1. 在HAR的module.json5中，将type字段的值改为“shared”，并添加deliveryWithInstall字段配置为“true”。
2. 若HSP需要对外声明可跳转的页面，需要在module.json5文件中添加pages字段，并在“resources/base”目录下建立“profile/main_pages.json”文件，添加“src”配置。
3. 将HAR的hvigorfile.ts文件中的“harTasks”更改为“hspTasks”。
4. HAR的build-profile.json5文件中默认生成consumerFiles字段，该项仅HAR可配置，为默认导出的混淆规则，需删除。

配置更改完成后即可重新编译。

备注

作者：夏天

链接：https://www.nutpi.net/

出处：https://www.arkui.club/

来源：坚果派 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。负责追究相关责任。