Read the original article：Differences and application scenarios of HAR, HSP, and HAP files
Differences and application scenarios of HAR, HSP, and HAP files
Problem Description
In projects, we often come across HAR, HSP, and HAP. What are the differences between these three, and what are their respective use cases?
Background Knowledge
HAP: A HAP is the basic unit for installing and running an application. It is a module package that contains code, resources, third-party libraries, and configuration files. There are two types of HAPs: entry and feature. An application package can contain only one basic entry HAP or one basic entry HAP and multiple feature HAPs.
HAR: This is a static shared package that can include code, C++ libraries, resources, and configuration files. Through HAR, multiple modules or projects can share ArkUI components, resources, and related code.
- Supports in-app sharing and can also be published for use by other applications.
- As a second-party library, it is released to the OHPM private repository for use by other applications within the company.
- As a third-party library, it is published to the OHPM central repository for use by other applications.
- If multiple HAPs or HSPs reference the same HAR, the code and resources in the HAR will be copied repeatedly, resulting in larger application packages.
HSP: It is a dynamic shared package that can include code, C++ libraries, resources, and configuration files. Through HSP, code and resources can be shared. HSP cannot be released independently; instead, it is released together with the host application's APP package, sharing the same process as the host application and having the same package name and lifecycle. Code and resources shared by multiple HAPs/HSPs are placed in the same HSP, which enhances the reusability and maintainability of the code and resources. Additionally, during compilation and packaging, only one set of HSP code and resources is retained, effectively controlling the size of the application package.
- HSPs in an app: During compilation, they are strongly coupled with the bundle name of the app and can be used only by a specific app.
- Integrated HSP: During the build and release process, it is not coupled with a specific application package name. When in use, the toolchain supports automatically replacing the package name of the integrated HSP with the host application's package name and will re-sign to generate a new HSP package, which serves as the installation package for the host application. This new HSP also falls under the category of in-app HSPs.
Solution
| Comparison dimension | HAP | HAR | HSP |
|---|---|---|---|
| Definition | A basic unit for installing and running an application, including code, resources, and configurations., Entry (main module) and feature (feature module) are supported.) | Static shared package, used for code/resource reuse (such as UI components and utility classes).) | Dynamic shared package, shared by multiple modules at runtime. |
| Cross-application sharing | Not shareable | Can be published to OHPM central warehouse/private warehouse. | Sharing only within the app. |
| Resource Reuse Methodology | N/A | Copying to the Referenced Module During Compilation | Dynamic loading at runtime |
| Multi-module reference impact | N/A | Code/resource duplication → Increased package size | Keep only one copy → Save space. |
| Typical Use Cases | 1. Entry module: implements the app startup page and core functions.; 2. Feature module: extended functions (such as the payment module), which are loaded on demand. | 1. Encapsulation of the common UI component library and tool classes; 2. Cross-team/enterprise sharing: Publish to OHPM central warehouse or private warehouse for other applications to call. | 1. Multiple modules share large resources (such as images and videos) to avoid repeated packaging and copying.; 2. Quick App Subcontracting preloading, improving performance; 3. The packet expansion problem caused by HAR is resolved. |
| Key constraints | 1. Declaration of Abilities/Pages is not supported, but pages can be included through navigation redirection.; 2. Cyclic dependency is not allowed. AppScope resources cannot be referenced. | 1. The version number must be the same as that of the host HAP.; 2. It cannot be independently released to the app store. | Cannot be used as a shared package for other applications. |
FAQs
Q: If multiple modules use the same HAR, will there be multiple HAR packages or only one HAR package in the app?
A: There may be multiple copies. Each user will copy a HAR file to the corresponding module, which increases the package size. For large files such as duplicate resources, it is recommended to use HSP for replacement.
Q: Can I create an AbilityStage in the HAR package? When is the lifecycle of the AbilityStage executed?
A: No. An AbilityStage corresponds to a HAP. The following figure shows the relationship between them.:
Q: What should I do if a compilation error is reported after the HAR is converted to the HSP?
A: After HAR to HSP package conversion /no_think. Ensure that the following configurations are correct:
- Check whether the type is set to shared and deliveryWithInstall is added in the module.json5 file in the HAR.
- Check whether the name of the hvigorfile.ts file in the module is changed from harTasks to hspTasks.
- By default, the build-profile.json5 file of the HAR package contains "consumerFiles": './consumer-rules.txt'. This item is only configurable for the HAR module and is the default obfuscation rule that is exported. You need to delete this item.
Q: Multiple HSPs reference the same HAR. The values in the HAR have been initialized in HSP A, but when used in HSP B, the values in the HAR are still the default. How can this issue be resolved?
A: After a HAR is referenced by multiple HSPs, it will be copied to each HSP. Therefore, instances in a HAR cannot be shared by multiple modules. In this case, you are advised to use HSPs instead of HARs.
Q: In which scenarios are multiple HAPs used?
A: Multiple HAPs are primarily designed to facilitate developers in managing applications in a modular manner. This allows developers to reasonably combine and deploy multiple HAPs on different devices, load them as needed, and reduce the package size. For example, in a payment application, there is a unified main interface that manages various modules such as "Scan," "Payment," "Messages," and "Financial Management." The logic for managing these other modules within the main interface is implemented in the entry package, while the "Scan," "Payment," "Messages," and "Financial Management" modules are implemented in separate feature packages. Developers can simultaneously develop multiple feature packages, enabling independent development and testing of each feature package, which are ultimately integrated into the entry package to provide the unified functionality of the feature packages.
Q: Can HAP be used as a shared package for other applications?
A: No, to share the package with other applications, please use HAR or integrated HSP.
Q: How can HSP be uploaded to the central repository for use by other third-party applications?
A: The OpenHarmony third-party library central repository only supports the release of HAR shared packages and does not support the release of HSP shared packages. If you need to share HSP within an application, you can publish the HSP shared package to a private repository for use. Please refer to ohpm private repository setup tool.
Q: In a project, there is one entry module and multiple feature modules. How can I specify the feature modules to be loaded after the program is started?
A: The entry module is the only module that can be used as the program startup entry. You cannot specify the feature modules to be loaded after the program is started. However, you can specify the type of each module as either entry or feature, and ensure that only one entry module exists. When the program is started, the entry module will be loaded. You can modify the type attribute in the module.json5 file of the module.
Q: How can an HSP compiled into an.tgz package for in-app sharing depend on external HAR packages?
A: The dependent HAR package needs to be embedded in the HSP package and compiled into a.tgz package.
Q: How can an in-app shared HSP compiled into a.tgz package depend on external HSP packages?
A: The dependent HSP package needs to be embedded in the HSP package and compiled together into the.tgz format, or the dependent HSP needs to be released to a private repository and shared during HSP development using version numbers for dependency management.
Q: Can a HAP be set as an independent process?
A: On 2-in-1 and tablet devices, the HAP can be set as an independent process for UIAbility. Modular Independent Processes
Q: Why is the size of the app package released to AppGallery smaller than that of the HAP package?
A: The HAP package compiled in the app is generally smaller than the normally compiled HAP package. The default compilation mode for the app package is non-Debug, while the default for the HAP package is Debug mode. Compared to the release version, the Debug version includes complete debugging information and symbol tables, which help developers quickly locate issues during debugging, view variable values, function call stacks, etc. In addition, the Debug version has not undergone obfuscation and optimization, resulting in a larger package size compared to the release version.
Q: During installation, the HSP was installed first, followed by the HAP. If there are subsequent updates for the HAP, can I directly hdc install hap? If I uninstall the HAP, will the related dependent HSP also be uninstalled?
A: You can directly hdc install xxx.hap without needing to uninstall and reinstall; the HSP will not be uninstalled. The HSP is a shared module and may be used by multiple HAPs.
Q: In the project-level oh-package.json file, the A HAR module is depended on. After compilation, the A HAR module is packed into the B HSP module. However, the B HSP module does not depend on the A HAR module, and a message is displayed indicating that the A and B modules are cyclically depended on.
A: The dependencies declared in the project-level oh-package.json file are used by all modules in the project. Currently, you are not advised to configure dependencies that are not in devDependencies in the project-level dependencies. That is, the non-development dependencies of an HSP or HAR module must be declared in the dependencies and dynamicDependencies of the corresponding module. You can declare the dependencies in the project-level oh-package.json file in the oh-package.json file of the required module as required.
Q: HAP depends on HSP and HAR. When HSP does not depend on HAR, can HSP use the resources in HAR?
A: There is no dependency relationship between HSP and HAR; HSP cannot use resources from HAR.
Top comments (0)