1. Design goals of multi-HAP mechanism
It is convenient for developers to manage applications modularly. Good applications are generally managed modularly, and the modules are loosely coupled. Multiple HAPs facilitate developers to divide services into multiple modules, and each module is placed in an independent HAP. For example, payment applications have a unified main interface, and the main interface manages various modules such as "scan", "receipt and payment", "message", and "financial management". The logic for managing other modules on the main interface is implemented in the Entry package, while modules such as "Scan", "Receipt and Payment", "Message" and "Financial Management" are implemented in different Feature packages. Multiple Feature packages can be developed at the same time, and the separate development and testing of Feature packages can be realized. Finally, the features of the Feature package can be unified and integrated by the Entry package.
It is convenient for developers to reasonably combine and deploy multiple HAPs to different devices. For example, the application contains an Entry package and two Feature packages (Feature1 and Feature2). Among them, the Entry package can be deployed to Device A and Device B, Feature1 can only be deployed to Device A, and Feature2 package can only be deployed to Device B, then developers can easily combine Entry and Feature1 to deploy on Device A, and combine Entry and Feature2 Deploy to device B.
It is convenient for developers to load the required modules on demand and reduce the package size. Developers can configure certain HAPs of an application to be loaded on demand. Features that are not initially used by the application during startup can be configured not to be loaded temporarily. When the user uses these features, the application can automatically download these feature HAPs, reducing the size of the application package to a certain extent.
Facilitate application resource sharing and reduce package size. Resources (including public resource files, public pages, etc.) and so (shared object) files needed by multiple HAPs can be placed in a separate HAP, and other HAPs can access resources and so files in this HAP, and to a certain extent above can reduce the application bundle size.
2. Multi-HAP construction view
The IDE supports the development and construction of multiple HAPs in one application project, as shown in the figure below.
Figure 1 Multi-HAP construction view
1. IDE development status view
AppScope directory
app.json5: Configure the global description information of the application, such as the application package name, version number, application icon, application name and dependent SDK version number, etc. resources directory: Place application icon resources and application name string resources. Note: This directory is automatically generated by the IDE, and the name cannot be changed. The file names under the AppScope directory and the file names under the Entry and Feature modules cannot be the same, otherwise the IDE will report an error.
The entry or feature directory (the name can be customized by the developer) is
a module created by the IDE to guide the developer, in which the business logic of the application is implemented; multiple modules can be created, and the entry and feature in the figure are the two created modules.
resources directory: place the resources used in this Module.
ets directory: developer's business logic.
module.json5: Configure the description information of the Module, such as: the name of the Module, the entry code path of the Module, and the included component information, etc.
2. Compile the packaged view
A development-state Module is compiled to generate a deployment-state HAP, and the Module and HAP correspond one-to-one.
module.json in HAP is synthesized from app.json5 and module.json5 in development view.
All HAPs will eventually be compiled into an App Pack (a package file with the suffix .app) for release to the application market.