HAR package usage scenarios

Read the original article：HAR package usage scenarios

Requirement Description

The HAR package, as a static shared package, is often used as a second-party/third-party SDK. However, version conflicts and large package sizes are frequently encountered during HAR package construction or referencing.

Background Knowledge

HAR Package Construction: DevEco Studio provides two default build modes, debug and release, and also supports developers to customize build modes. The constructed HAR package outputs are divided into three formats: HAR containing source code, HAR containing JS intermediate code, and HAR containing bytecode. Specific construction methods can be found on the official website.

HAR Package Referencing: You can reference local HAR packages or HAR packages in the OHPM repository.

Implementation Steps

Scenario One: Is it necessary to package into a HAR package before referencing every time?

It is not necessary to package into a HAR package before referencing every time. You can directly reference the source code. For example, if the entry module needs to depend on the source code of the foo module, it can be done as follows

Set the source code dependency in the oh-package.json5 of the module that needs to introduce the local module source code. That is, in the oh-package.json5 of the entry module, add the following configuration:

"dependencies": {
  "foo": "file:path/to/foo"  // This can also be a relative path starting from the directory where the current oh-package.json5 is located. 
}

Scene Two: Can Java or JAR files be packaged into HAR packages?

Currently, it is not supported to package Java or JAR files into HAR packages. HAR packages are static shared packages that can include ArkTs/ts code, C++ libraries, resources, and configuration files.

Scene Three: How to optimize HAR packages that are repeatedly packaged, such as when there is an SO library in the HAR package, and each module referencing this HAR package copies a copy of this SO library, resulting in a very large package size?

It is recommended to replace public resources with HSP dynamic shared packages.

In multi-package scenarios, if multiple HAP or HSP packages in an application use HAR packages to share code and resources, then each packaged HAP or HSP package will contain a copy of the shared HAR package, leading to redundant code and resources in the App package. As shown in the example below, application modules HAP1 and HAP2/HSP1 both reference HAR2 and HAR3. After packaging, HAR2 and HAR3 exist in multiple duplicate copies in the App package, resulting in a large size.

In this scenario, it is recommended that developers use HSP instead of HAR to achieve code and resource sharing. As shown in the example below, using HSP2 to upgrade and transform the original application, after packaging, only one copy of HAR2 and HAR3 exists in the APP package. When the total size of HAR2 and HAR3 is larger than HSP, the application package size can be reduced.

Scene 4: If an application has multiple modules, does referencing different versions of the same HAR package in multiple modules have any impact, and how to specify a unified version?

No impact, each module will copy its own HAR package to its module, which will not affect other modules.

The ohpm client supports the Override mechanism starting from version 1.4.0. You can add the overrides configuration in the project-level oh-package.json5 file (i.e., oh-package.json5 in the project root directory) to specify a unified version for the har package. The replacement version can be a specific version number, a fuzzy version, or a locally existing HAR package or source code directory.

Note: Overrides must be configured in the project-level oh-package.json5, and will not take effect if configured in the module-level oh-package.json5.

• If the project specifies the unified version of foo as 1.0.1, configure the following in the project-level oh-package.json5:

  {
    "overrides": {
      "foo": "1.0.1"
    }
  }

• If the source code or HAR package of foo exists locally and you want to ensure that foo always uses your local version, you can configure it as follows in the project-level oh-package.json5:

  {
     "overrides": {
        // The source code directory "foo" exists locally, such as the foo directory under the project root directory. 
        // "foo": "file:./foo" 
        // There is a HAR file named "foo" locally, such as foo.har in the libs directory under the project root directory. 
        "foo": "file:./libs/foo.har"
     }
  }

Scene Five: An application has multiple HAR modules, such as modules HARA, HARB, HARC, and HARD. HARB depends on and references HARA, HARC depends on and references HARB and HARA, and HARD depends on and references HARC, HARB, and HARA. Now, it is desired that the packaged result only contains one copy of HARA, HARB, HARC, and HARD to avoid redundancy and repetition in the generated HAR packages. How can this be achieved?

• Due to the existence of multiple HAR modules, there are repeated dependencies and references between these modules. Within the same project, different HAR modules have inheritance dependencies. For example, for modules HARA, HARB, HARC, and HARD under the project, first expose methods, classes, and interfaces in the modules through the export method, allowing other modules under the project to access them.
• Let HARB depend on HARA, HARC depend on HARB, and HARD depend on HARC, thus forming an inheritance dependency relationship among the four modules. This allows HARD to reference HARC, HARB, and HARA, HARC to reference HARB and HARA, and HARB to reference HARA, thereby avoiding the generation of duplicate HAR packages.
• Convert the outermost HAR module HARD into an HSP module first, and refer to the link for related configuration guidance on converting HAR to HSP. Since the HSP module can only be referenced by other HAP modules or HSP modules within the application, if it needs to be used by modules in other applications, the HSP module must be converted into an integrated state HSP. Refer to the link for related configuration guidance on integrated state HSP.
• Build and package the integrated state HSP module HARD for use by other applications.

Code Snippet / Configuration

The following code/configuration is provided as a reference implementation. For detailed step-by-step guidance, see the Implementation Steps (Scenarios 1–4) section above.

Written by Aycanur Ucar