HarmonyOS鸿蒙Next中HSP（Harmony Shared Package）和 HAR 有什么区别？

HarmonyOS鸿蒙Next中HSP（Harmony Shared Package）和 HAR 有什么区别？ 在拆分模块时看到 HAR 和 HSP 两种共享包。具体差异在哪？会不会增加包体积？

9 回复

har学名：静态共享库，

hsp学名：动态共享库

从使用场景来说的区别：har适合发到第三方仓库里面，再在项目内引用。hsp适合直接在项目内使用。

从开发环境来说的区别：har在项目内使用的话，如果多个模块引用了，那har在项目内就会有多份。

hsp则不一样，hsp在项目内使用，如果多个模块引用了，也只会存在一份。

这对于优化包体积有很明显的帮助。

更多关于HarmonyOS鸿蒙Next中HSP（Harmony Shared Package）和 HAR 有什么区别？的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


  • Static Library：静态共享库。编译后生成一个以.har为后缀的文件，即静态共享包HAR（Harmony Archive）。
  • Shared Library：动态共享库。编译后生成一个以.hsp为后缀的文件，即动态共享包HSP（Harmony Shared Package）。

HAR与HSP两种共享包的主要区别体现在：

共享包类型 编译和运行方式 发布和引用方式
HAR HAR中的代码和资源跟随使用方编译，如果有多个使用方，它们的编译产物中会存在多份相同拷贝。 HAR除了支持应用内引用，还可以独立打包发布到OHPM中心仓或者OHPM私仓，供其他应用引用。
HSP HSP中的代码和资源可以独立编译，运行时在一个进程中代码也只会存在一份。 HSP一般随应用进行打包，当前支持应用内和集成态HSP。应用内HSP只支持应用内引用，集成态HSP支持发布到OHPM私仓和跨应用引用。

 核心区别就是，HAR会打包进HAP里面，HSP以独立文件形式存在

详细的理解小伙伴感兴趣的话可以阅读一下文章

HarmonyOS 应用包类型详解 - HAP、HAR、HSP

这一张图应该就解决你的问题了😂

  • 想要减小包体积，就是用HSP。
  • 如果需要打包成二、三方独立SDK发布到OHPM私仓或公共仓库，则需要使用HAR

previewableImage

参考：选择合适的包类型-应用程序包概述

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

建议仔细看下官方文档谢谢
https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/in-app-hsp

有要学HarmonyOS AI的同学吗，联系我：https://www.itying.com/goods-1206.html

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

说明

  • 应用内HSP：在编译过程中与应用包名（bundleName）强耦合，只能给某个特定的应用使用。
  • 集成态HSP：构建、发布过程中，不与特定的应用包名耦合；使用时，工具链支持自动将集成态HSP的包名替换成宿主应用包名，并且会重新签名生使用场景 支持应用内共享，也可以作为二方库（SDK）、三方库（SDK）发布后供其他应用使用。 作为二方库（SDK），发布到OHPM私仓，供公司内部其他应用使用。 作为三方库（SDK），发布到OHPM中心仓，供其他应用使用。 约束限制 HAR不支持在设备上单独安装或运行，只能作为应用模块的依赖项被引用。 成一个新的HSP包，作为宿主应用的安装包，这个新的HSP也属于宿主应用HAP的应用内HSP。
  • 指南和API参考文档中如无特殊说明，默认HSP都为应用内HSP。

使用场景

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

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

使用场景

  • 支持应用内共享，也可以作为二方库（SDK）、三方库（SDK）发布后供其他应用使用。
  • 作为二方库（SDK），发布到OHPM私仓，供公司内部其他应用使用。
  • 作为三方库（SDK），发布到OHPM中心仓，供其他应用使用。

约束限制

  • HAR不支持在设备上单独安装或运行，只能作为应用模块的依赖项被引用。

HSP是动态共享包，可独立编译部署，支持代码和资源的运行时共享，依赖方使用时需动态加载。HAR是静态共享包，编译时链接到主包中，代码和资源在编译期集成，运行时不可更新。主要区别在于HSP支持运行时动态更新和多个应用共享同一实例，而HAR仅用于静态复用。

HSP（Harmony Shared Package）和HAR（Harmony Archive）是HarmonyOS Next中两种不同的共享包机制，主要区别如下：

1. 本质与编译方式

  • HAR：静态共享包。在编译时，其公共代码、资源等会被直接复制到依赖它的每个HAP中。每个HAP都包含该HAR的完整副本。
  • HSP：动态共享包。在编译时，其代码和资源会被单独编译成一个独立的包（.hsp文件），在运行时由系统动态加载。依赖它的HAP不会直接包含其代码，仅包含引用信息。

2. 运行时行为与包体积

  • HAR：由于代码被复制到每个依赖的HAP中，如果多个HAP依赖同一个HAR，则每个HAP的体积都会增加，导致应用整体包体积显著增大。在运行时，每个HAP进程内都有一份独立的HAR代码副本。
  • HSP：多个HAP可以共享同一个HSP的实例。这避免了代码重复，能有效减少应用的整体包体积。运行时，HSP的代码在系统中通常只加载一份（或按需加载），被多个HAP共用。

3. 依赖与耦合

  • HAR：提供的是源代码级别的静态依赖。版本更新时，所有依赖它的HAP都需要重新编译。
  • HSP：提供的是二进制级别的动态依赖。HSP可以独立编译、部署和升级（需遵循版本兼容性规则），依赖它的HAP无需重新编译即可使用新版本的HSP。

4. 使用场景

  • HAR：适用于共享工具类、公共UI组件、资源文件等，在模块间紧密耦合、且对包体积不敏感的场景。
  • HSP：适用于包含复杂业务逻辑、较大体积的公共代码或资源，且被多个HAP频繁共用的场景。是优化应用包体积、实现模块解耦和独立升级的关键手段。

关于包体积： 使用HSP通常会显著减少最终应用的整体包体积，因为它避免了公共代码的重复。而使用HAR，则必然会导致依赖它的每个模块体积增加，从而增大总包体积。

总结：HAR是静态共享，简单但会增加体积；HSP是动态共享，能优化体积并支持独立部署，但设计更复杂。选择时需根据代码复用程度、模块解耦需求和包体积要求来决定。

回到顶部