HarmonyOS application packages support multi-module development. A generated application package (.app) can contain multiple HAPs or HSPs. To achieve quick startup, the size of HAP and HSP files is limited, and the atomic service startup mechanism is optimized. This multi-module development mode of atomic services is called "sub-packaging".
When an atomic service navigates via subpackage page routing, the system dynamically loads the subpackages and starts the corresponding page after the loading is complete. If you want to optimize the subpackage loading speed, refer to Preloading.
Subpackaging Rules and Constraints
Main package: The EntryHAP is used as the main package, which contains the code and resources of the page (home page) that will be opened when the atomic service is started for the first time.
Subpackage: Other modules that contain functional pages and the HSP dynamic shared module are used as subpackages, which contain the code and resources of the functional pages and atomic service pages.
The size of a single package file (including all its dependent shared packages) cannot exceed 2 MB. If the size exceeds the limit, DevEco Studio packaging will fail.
The total size of all package files (including all their dependent shared packages) of the same atomic service cannot exceed 10 MB. If the size exceeds the limit, it will fail to be released to the app market. If necessary, apply to the platform to increase the total package size to 20 MB.
In this way, to start the atomic service, only the downloading and installation of the main package are required, which greatly shortens the startup time of the atomic service.
- Atomic services support only a single ability. The subpackage module type must be shared (HSP). Atomic services do not support modules of the feature type.
- If the total package size needs to be adjusted to 20 MB, send an email to apply for the adjustment. We will reply with the application result by email within seven working days. In the email, provide the permission name, atomic service name, and app ID, explain the reason for the application, and copy the email to the Huawei contact person.
- Application email: atomicservice@huawei.com
Figure 1 Atomic service architecture design example
Design principles:
Product customization layer (products): personalized services for different device forms, including the UI, resources, and related configurations. Products cannot directly depend on each other and depend on the service module layer and common basic layer.
Service module layer (features): can be depended on by HAPs of different device forms at the product customization layer, but cannot depend on the product layer. It can also depend on the common basic layer.
Common capability layer (Commons): basic capability set. Any common service contained within each service module layer can be implemented on the common basic layer. It can only be depended on by the product layer and service module layer. Reverse dependency is not supported.
Subpackaging Process
Create an atomic service for the stage model. For details, see Creating an Atomic Service Project.
Create an HSP module. For details, see Developing a Dynamic Shared Package.
Figure 2 Project directory structure for atomic service subpackage
The entry module is the main package of the atomic service, and the type field is entry. The following is the module.json5 file of the entry module:
{ "module": { "name": "entry", "type": "entry", "pages": "$profile:main_pages", ... } }The library module is a shared subpackage, and the type field is shared. The following is the content in the module.json5 file of the library module:
{ "module": { "name": "library", "type": "shared", ... } }