Preface#
The following are the goals I hope to achieve through learning HarmonyOS development:
- Use the Chinese documentation to quickly build a comprehensive concept and knowledge system required for native development, and expand the native development skill tree by breaking down the surface.
- Prepare for possible new tracks and wait for opportunities.
This article aims to understand what HarmonyOS development is from the perspective of application execution, based on the understanding of a web front-end engineer.
Application Model - The Basic Rules of HarmonyOS Applications#
The application model is an abstract refinement of the capabilities provided by HarmonyOS for developers to develop applications. It provides the necessary components and runtime mechanisms for application development. -- HarmonyOS Developer Documentation
The application model defines the "rules of the game" for HarmonyOS application development. Developing a HarmonyOS application means using components to implement application functionality within a predefined runtime mechanism.
Specifically, the application model includes five elements: application components, application process model, application thread model, application task management model, and application configuration file. (The last four are runtime mechanisms)
During the iteration of HarmonyOS, there are two models: FA and Stage. They have differences in all five elements, but here we mainly focus on the Stage application model, which will be the main model in the future.
Overview of Stage Model Development#
Application Components#
Application components are the main entities that developers use and implement. In the Stage application model, application components are divided into UIAbility and ExtentionAbility.
UIAbility is an application component that contains UI interfaces. It serves as the carrier for familiar front-end developers to interact with users. UIAbility is like a tab in Chrome that displays a multi-page application. The specific UI interface is completed by multiple pages.
ExtentionAbility is an application component for a specific application scenario, which may or may not include a UI interface. For example, input method scenarios, desktop card/widget scenarios, background services, etc. You can find specific component types in the documentation.
Other Core Concepts#
Between application components and the process, thread, and other runtime mechanisms, there is an implementation and concept that connects the components and runtime mechanisms. You can understand it through the following diagram in the documentation.
AbilityStage and Context#
Application components cannot drive themselves and inevitably require someone to drive and coordinate them. This "person" is the AbilityStage. When the application starts, it is created first and then starts loading and executing the default Ability.
Context is also created along with AbilityStage, which records all the contextual information of the AbilityStage. Each UIAbility will derive its own context (UIAbilityContext) from here. Pages within UIAbility can use the context to obtain runtime information and methods.
WindowStage and Page#
Each UIAbility does not directly manage pages during runtime but manages them through the held WindowStage. This is because in current applications, there are not only single full-screen window forms. For example, a document application can have multiple windows for real-time preview, and a video application can implement floating windows for continuous video playback. Compared with simulated windows in pages, WindowStage has more accurate lifecycles and stronger interaction capabilities because it is closer to the underlying implementation of the application model.
Finally, we come to the familiar page (Page) for front-end developers. Pages are interactive interfaces implemented using ArkUI, which is what users see. A UIAbility can have multiple pages displayed in specified windows.
It is worth mentioning that in HarmonyOS development, in addition to ArkUI, there is also a web development paradigm, which uses HTML, CSS, and JS to build page UIs (ArkUI only uses ArkTS to build pages without HTML and CSS). However, in the Stage development model, only ArkUI can be used for page development. Therefore, for individuals, following the Stage application model and using ArkTS and ArkUI to implement HarmonyOS applications is more in line with the development trend of HarmonyOS and will bring long-term benefits. For companies, the choice between replicating existing applications using the Stage model or using the FA application model and quickly migrating existing web pages using a web development paradigm depends on external factors such as Huawei's determination and investment, policy guidance, as well as internal factors such as current technology choices and available resources.
Understanding UIAbility#
By learning the core concepts of the Stage development model, we can understand that what users see in a HarmonyOS application is a collection of abilities based on AbilityStage and primarily scheduled by UIAbility.
Further understanding of UIAbility and its range of capabilities can help us better decompose application capabilities and design application structures.
Below, we will understand UIAbility from the inside (lifecycle) to the outside (interaction with other entities).
Lifecycle#
In the retained mode GUI world, just like humans, "everything" here has a cyclical nature of "birth, aging, illness, and death." We use callback functions at lifecycle nodes to build and change UI states, thereby depicting the interface view at a certain period. As a member of the "world," UIAbility naturally has its own lifecycle.
From the diagram, we can see that the lifecycle of UIAbility is from the user's perspective and includes four nodes: creation, foreground, background, and destruction. Because it "lives and dies" with WindowStage, their lifecycles are also related. With this diagram in mind, we can be more targeted in actual development.
In these nodes, we can perceive the current state of UIAbility (created, visible, currently focused) and interact with its related entities through various means to change the application's state.
Interaction with Pages#
We can send events to pages within UIAbility through an event mechanism to notify them to make certain changes. We can also share data between the global object and pages. For specific usage methods, please refer to the documentation. It should be noted that events are limited to within UIAbility because the EventBus is mounted on the UIAbility's own Context, and a page cannot obtain the Context of another UIAbility. The global object depends on the application model. In the Stage model, since all abilities share the same ArkTS engine, there is only one global object, and anyone can read and write on this object, which carries the risk of overwriting. (In the FA model, each Ability has its own ArkTS engine, so the global object is independent.)
Interaction with Other Abilities#
Interaction with other abilities can be summarized into two things: opening methods and information carriers. Currently, interacting with other abilities means opening and invoking other abilities. The methods are subdivided based on whether you need to obtain some results when the ability is closed. The information carrier, "want," describes how to open which ability. By determining certain parameters, we can open abilities within the same application or open abilities in different applications to achieve common scenarios such as third-party payments. The term "how to open" refers to "creating" or "reusing."
Here, let's also mention the launch modes of UIAbility, which are divided into three types: singleton mode, standard mode, and specified mode. Singleton mode means that if the current ability has already been created, it will only be brought to the foreground without creating a new one. The standard mode creates a new instance every time. In some complex scenarios, whether to create or reuse is determined when called, which is the specified mode and needs to be specified in the Want. For specific operation methods, please refer to the documentation.
Understanding Process and Thread Models#
There is relatively little description of processes and threads in the documentation. What needs to be understood is that all abilities of the same application run in the same process, while webviews have their own rendering processes. A process has a main thread and several worker threads, and both threads have ArkTS engines. As mentioned earlier, in the Stage model, UIAbility runs in the main thread's ArkTS engine. The main thread's functions are roughly as follows, as mentioned in the documentation:
- Execute UI drawing.
- Manage the ArkTS engine instances of the main thread to enable multiple UIAbility components to run on it.
- Manage the ArkTS engine instances of other threads (such as worker threads), such as starting and terminating other threads.
- Dispatch interactive events.
- Handle callbacks of application code, including event handling and lifecycle management.
- Receive messages sent by worker threads.
Due to my limited knowledge in this area, it is difficult for me to have a deep understanding. I will further study it when I have practical applications in the future.
Afterword#
By reading the HarmonyOS documentation on the application model, I have gained a general understanding of what the HarmonyOS application runtime looks like: in the main thread of a process, different UIAbility components are scheduled by AbilityStage, and UIAbility manages windows and displays pages.
In addition, for a complex existing app, the choice of development model needs to be considered. Since the Stage and FA models cannot be mixed, it is not possible to use the Stage model for some modules and the FA model for others within the same application. Therefore, the choice of the main model will determine whether modules can use a web development paradigm to quickly migrate existing web and mini-program pages.
The next article will probably focus on the organization of HarmonyOS application code during compilation, module reuse, and the final packaging. This will help establish a complete HarmonyOS application development system.