Explore Mobile Performance Monitoring: HarmonyOS NEXT Agent Architecture and Technical Implementation

1. Background Information
On October 22, 2024, at the Native HarmonyOS Night event, HarmonyOS NEXT (version 5.0.0, starting from API 12) was released. Unlike the "dual-framework, dual-ecosystem" transitional form of the previous HarmonyOS 3.1 and 4.0, NEXT directly bids farewell to Android Open Source Project (AOSP) and fully switches to the HarmonyOS kernel, becoming a "pure HarmonyOS" in the true sense.

1. Understand NEXT with three keywords Pure: zero AOSP code and unified HarmonyOS kernel + ArkTS syntax chain. This completely removes the Android compatibility burden. Fast: The ArkCompiler directly translates application code into machine code during compilation, which greatly improves system runtime efficiency. Simple: Develop an application once and deploy it across multiple devices. The 1 (phone) + 8 (tablet, wearable, in-car system, and so on) + N (IoT ecosystem) model covers all scenarios.

1. Development base panorama IDE: DevEco Studio (JetBrains kernel), which enables visual multi-device preview. Development language: ArkTS. Built on TypeScript, ArkTS enhances static type checking and improves concurrency capabilities.

Compilation method: In traditional JavaScript program development, applications often contain JavaScript bundle files that are processed by frontend packaging tools, and interpreted and executed at runtime. This execution method requires devices to have powerful computing capabilities. HarmonyOS supports a wide range of devices, from low-end IoT devices to high-performance mobile phones. The traditional method cannot guarantee a consistent experience across different devices. In the HarmonyOS development environment, application code is compiled by a frontend compiler. The frontend compiler parses the source code based on the language specifications, compiles it into a binary bytecode format that the Ark runtime can understand, and then packages it into the application.

Compilation products: Module compilation results have three formats to meet different deployment state requirements.

HAR: HarmonyOS Archive (HAR) is an intermediate compilation product format that will eventually be compiled and merged into a package in the HarmonyOS Shared Package (HSP) or HarmonyOS Ability Package (HAP) format.
HSP: HSP allows modules to be shared in a runtime reusable form. Compared with HAR, when multiple HAPs depend on the same HSP, only one copy of the HSP will exist in the final packaged product.
HAP: An HAP is an independently installable container package for a HarmonyOS application. The same HAP can run on multiple devices. This way, you can develop an application once and distribute it to multiple devices for deployment.

1. System-level open capability atlas Application frameworks: provide the infrastructure for application development, including open capabilities such as the runtime, engine, and frameworks. Application services: provide core features and services for application development, including open capabilities such as push notifications, login authentication, and payment. Media: provides open capabilities for storing, processing, and transmitting multimedia content such as videos, audio, and images. Graphics: provide graphics technologies for rendering, display, and interaction, including open capabilities related to 2D and 3D graphics, animations, and games. AI: provides open capabilities related to machine learning, deep learning, natural language processing (NLP), and computer vision. System: provides open capabilities related to communication, security, drivers, DFX, diagnosis, and testing.

At this point, the basic outline of HarmonyOS NEXT is clear. It is not just a mobile OS, but a native neural system for the era of the Internet of Everything. As the HarmonyOS NEXT ecosystem flourishes, application performance monitoring becomes increasingly important. The SDK for HarmonyOS NEXT, developed by the Alibaba Cloud Application Real-Time Monitoring Service (ARMS) team, provides an industry-leading end-to-end monitoring solution for HarmonyOS applications. It is not just an SDK, but an intelligent partner for you to gain insights into user experience and optimize application performance.

2. HarmonyOS SDK architecture and design

1. Overall SDK architecture

Interface layer: the top layer that is exposed externally and provides APIs for customer calls.
Feature layer: provides data collection services and specifically includes the network, interaction, application, lag, crash, custom, WebView, and page modules.
Core layer: includes basic services, utility classes, logger, time, and data protocol. It is the session management, configuration management, and OpenTelemetry extension layer.
Dependencies: include opentelemetry-ts/js and Pako.

1. How to manage sessions A session refers to the behavior trajectory of a user from entering a host application to exiting it. When the application starts, a session begins. The unique SessionID is written to a global variable. When an event occurs, the current SessionID is written into the metrics of the event.

In other words, a session is a means for the SDK to link and manage user behavior trajectories. Developers can view the session trajectory in the console to understand the context of the user's operational behavior within the application, and then conduct analysis from various perspectives. A new session is started when the user directly kills the application or the time spent in the background exceeds 60s.

1. Data collection scheme design For data collection in different scenarios, the SDK adopts different collection schemes based on the characteristics of HarmonyOS. In general, the following three non-intrusive collection schemes are adopted.

Scheme 1: Leverage HarmonyOS system-level APIs
As mentioned earlier, HarmonyOS provides a variety of Kits. We mainly use the HiAppEvent capability of the Performance Analysis Kit to collect data on exceptions, lags, and startup time. This API provides the capability to subscribe to system events. We perform operations such as data collection in the callback function when a subscribed event occurs.

HiAppEvent provides the capability to subscribe to application events and system events. System events mainly refer to performance, power consumption, and stability issues that occur when applications are running. The exception events, lag events, and startup events that the SDK is concerned with all fall into the category of system events. For example, for crash events, HiAppEvent provides the ability to detect crashes of the NativeCrash and JsError types. After the system completes collecting crash information, it generates and reports an event. The SDK is only concerned with the operations after the event is reported and performs data analysis and processing based on the properties of the reported parameters, and finally reports the data. The following figure shows how the crash event is collected.

Scheme 2: Listen to the lifecycle of UI components
For events with a lifecycle, the SDK implements collection by listening to the lifecycle. For example, UiContext provides the UiObserver capability for the NavDestination component. The interface on(type: 'navDestinationSwitch', callback: Callback): void provides the capability to listen for Navigation page switch events. During SDK initialization, a listener is registered, and a callback function for data processing is constructed to handle data differently at various lifecycle stages.

As shown in the following figure, the page dwell time can be calculated from the difference between the onHidden and onShown time points. It is worth mentioning that when you need to unregister the navDestinationSwitch listener, you must specify the corresponding callback function to be unregistered. Otherwise, all global listeners for navDestinationSwitch become invalid, which may cause certain application features to fail.

Scheme 3: Implement compile-time replacement of AOP with the Hvigorw plug-in
During the data collection process, the system does not provide the listening capability for some events, and these events do not have a complete lifecycle to listen to. To achieve non-intrusive data collection, the SDK adopts aspect-oriented programming (AOP) to implement non-intrusive instrumentation during code compilation. The overall development idea for the plug-in refers to Huolala's open-source solution at https://github.com/HuolalaTech/AspectPro/tree/master, which implements code replacement during the code compilation process.

For example, each httpRequest corresponds to an HTTP request task in the network framework ohos.net.http. The SDK instruments the key code http.createHttp(), adds crucial processing logic, records performance metrics for network success and failure, and then generates a network span to report the data.

3. Summary
In the new era of HarmonyOS NEXT, Alibaba Cloud ARMS Real User Monitoring (RUM) SDK, as a performance and experience monitoring tool, can serve as a powerful assistant for application O&M. ARMS RUM SDK for HarmonyOS NEXT has been officially released. For more information, see the integration documentation. If you have any questions, you can join the RUM support DingTalk group (group ID: 67370002064) for consultation.