Author: Men Liu

Hongmeng is a new generation of terminal operating system developed by Huawei, which can be applied to IoT, watches, mobile phones, pads, TVS and other types of devices. It has been criticized as a “domestic operating system”. In early June 2021, OpenHarmony 2.0 Canary was released, with more open source code for subsystems and support for devices with 128MB or more memory. Which contains the new version of THE JS UI framework, this article focuses on the analysis of this part of the code. (The content of this article is for reference only, if there is any inaccurate description of the content, thank you for the background message discussion and correction ~)

Overview of Hongmeng system

System architecture layering

For more information, visit OpenHarmony’s website [1]. Here is the official technical architecture:

First of all, Hongmeng app is packaged into HAP (Harmony Ability Package format distribution, and android APK is a compressed Package, Package structure is similar. Once distributed to the end, unification is carried over by the Hongmeng (Concept) API and then separated into different modes. The hongmeng version pushed on Huawei phones, which is compatible with Android apps without feeling, must rely on AOSP. While the open source part is mainly aimed at low-end IoT devices, or watch bands and the like, even without a screen. In June 2021, the open source version just supports devices with more than 128MB of memory, which cannot independently support apps on mobile phones. These are two extreme scenarios of “casing” and “self-development”, neither of which is necessarily a stable final state. In between, the subsystems of the framework layer and the system service layer in the overall architecture are relatively independent and decouplable, which can be used in these scenarios at the same time, but their functions are not sound enough. Some of them are open source, such as microkernel and JS UI framework, and some are not open source. Compatibility with Android is not a long-term solution, the open source part of the function is simple, so the middle of the uncertain piece will be the future of the main link? Will Hongmeng really develop into a self-developed full-platform operating system in the future? Wait and see.

Try answering one of the most discussed questions in the community:

Is Hongmeng self-developed? There must be a proprietary component, and there must be some reliance on tripartite code. At this stage, it is unrealistic to require all the code to be self-developed. It can’t be completed in one or two years. We must first innovate on the shoulders of giants, and then further reduce dependence and deal with the agreement and copyright issues.

Does Hongmeng rely on AOSP? You can say dependent, you can say not dependent. HarmonyOS’s compatibility mode relies on AOSP, otherwise it wouldn’t work with Android apps; OpenHarmony is open source and does not rely on AOSP, but is currently used mainly on low-end IoT devices.

Unless otherwise noted, all of the “hongmeng” mentioned below refer specifically to OpenHarmony.

UI subsystem of Hongmeng

There is no Java UI in the open source version (at least I can’t find it). The framework for implementing JS UI is called ACE, which stands for Ability Cross-Platform Environment. There are two repositories: Ace_engine_lite [2] corresponds to the old ACE architecture, while ACe_ACe_engine [3] corresponds to the new ACE architecture. Their implementation principles and upper syntax are different.

Source directory structure

The OpenHarmony open source code is hosted on Gitee, and there are more than 200 repositories under the group. It is recommended to download the code according to the documents obtained from the official source code. The source directory structure and the corresponding relationship between the repositories can be refer to the manifest repository configuration file [4].

If your environment is already configured, execute the following two commands:

repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify
repo sync -c
Copy the code

The whole process takes about 15 to 30 minutes. You can find the manifest configuration file after executing the first command and remove Linux and some third_party dependencies faster.

The directory structure of the abbreviated version is as follows (irrelevant directories are skipped and related parts are expanded only) :

├─ Application # ├─ Application # ├─ Application # ├─ Application # ├─ Application # ├─ Application # ├─ Application # ├─ Application # ├─ Application # ├─ Application # ├─ Application # ├─ Application # ├─ Application # ├─ Application # ├─ Application # ├─ Application # ├─ Application # ├─ Application # │ ├─ Heavy Metal Guitar School - Ace # JS │ ├─ Heavy Metal Guitar School - Ace # JS ACE ace_ace_engine │ │ └ ─ ─ ace_engine_lite # 2.0, warehouse name: │ ├─ ├─ Interface │ ├─ ├─ pdk-2, pdk-2, pdk-2 ├── Heavy Exercises ── heavy Exercises ─ heavy exercises ─ heavy exercises ─ heavy exercisesCopy the code

Old and new ACE frames

The following is the architecture diagram of ACE framework [5]. Now the UI described in the document and supported in IDE is this set of UI, which provides DSL[6] development UI similar to small program, HML(HarmonyOS Markup Language) + CSS + JS.

The main body of this architecture is divided into application, framework, engine, and cross-platform adaptation. The application layer is the syntax for developers, and there are several modes, explained below. The framework layer implements the componentized, MVVM capabilities common to front-end frameworks, enabling responsive UI updates. Here is the JS engine, which uses QuickJS and should also support V8. Further down is the rendering engine, which contains the core rendering pipeline, animations, events, and various layout rendering algorithms.

The bottom porting Layer is the key to adapt to multiple platforms. It defines a platform-independent layer data structure that can be submitted to various compositors for rendering. From the perspective of the code, it is supposed to support the Flutter Engine.

Overall rendering process

Container creation and management

The basic unit of UI is FA (Feature Ability), which corresponds to an instance of AceAbility and provides a lifecycle hook that creates an AceContainer internally when OnStart() is executed. However, this AceContainer is not held directly by AceAbility, but is managed by a globally unique singleton called AceEngine.

In the Frontend section, there are three different types of implementations: imperative UI based on rendering instructions, declarative UI, and UI rendered in JSON files without a scripting engine. Both the imperative UI and the declarative UI use QuickJS as the scripting engine. The declarative UI includes V8 abstractions, but they don’t seem to be open sourced.

JS Frontend (imperative UI)

“Imperative UI” is an engine implementation point of view, because the underlying rendering instructions are based, and the true syntax is open to developers, which can be interfacing with declarative and responsive front-end frameworks such as vue.js. The JS UI of hongmeng official website corresponds to JSFrontend. The syntax is similar to small programs, which should be inherited from the previous quick application. Each component corresponds to the template file of XX.hML, style file of XX.css, script file of xx.js and configuration file of XX.json.

<div class="container">
  <text class="title-text">{{headTitle}}</text>
</div>
Copy the code

/* xxx.css */
.container {
  flex-direction: column;
  margin-top: 20px;
  margin-left: 30px;
}
.title-text {
  color: #1a1a1a;
  font-size: 50px;
}
Copy the code

// xxx.js
export default {
  data: {
    headTitle: 'Capture the Beauty in This Moment'
  }
}
Copy the code

The above code will be packaged and compiled into a JS file for dynamic execution.

When initializing the JS execution environment, it first binds a series of native interfaces, then executes the built-in JS framework, and then dynamically loads the JS code of the executing user. In the qjs_engine.cpp [8] file of js frontend, you can see the interfaces registered with the JS environment:

DomCreateBody (0, 'div', {/* attrs */}, {/* styles */}, {/* events */})Copy the code

@Component class MyDemo { Column( Text('Hello World! '), Text('Some text here') .fontsize(36) .color(Color.Red) ).center() }Copy the code

The advantage of this method is that the combination is good, the layout nodes do not affect each other like CSS, the layout algorithm is more efficient. But abandoned the front-end favorite HTML + CSS layout, the existing various front-end frameworks, component libraries, style libraries can not be directly transferred to the ecological construction will be a little difficult.

Card Frontend (no script UI)

It’s called CardFrontend, but it’s probably mostly used in card-like scenarios like masked desktop widgets. It does not rely on a script engine, but is driven by a JSON file in a specific format.

JSON file format is not yet clear document, here is a test case, the main body is divided into the template, the styles, the actions, the data of this a few parts, can be written in the template data binding of curly braces {{. Some data}}, can write simple JS expression inside, It’s not completely static. The CardFrontend class also has an UpdateData() interface, which updates the template data and provides dynamic capabilities.

Node construction process

The above three front-end frameworks correspond to different UI development methods, but the node construction and layout drawing algorithm of the latter half are all the same link, and are self-drawn and rendered by C++, independent of system UI, with good consistency. The complete node-building process can be drawn as follows:

Each frame of vsync will trigger the OnVsyncEvent() callback. If the surface is already initialized, the internal dirty nodes will be refreshed in turn. If the animation is included, the next frame of vsync will be triggered by a RequestFrame() request. Dirty Elements will trigger Rebuild() to Rebuild RenderNode, and MarkNeedLayout() will be called to add it to the queue to be laid out. FlushLayout will flush the queue. Call the OnLayout() method of the node to calculate the layout, and then add itself to the queue to be drawn. Then FlushRender() calls the Repaint() method of the node in turn to redraw to generate the Layer Tree.

Discuss the development of Hongmeng

A graph posted at The Developer conference shows that the number of mobile, tablet and PC devices has not increased significantly in a long time and will not increase much in the next five years. However, IoT devices, such as watches, offline large screens, vehicles and other devices, are increasing, and the number of IoT devices is still in the stage of rapid development. Hongmeng judged that the future is the era of the Internet of everything, and the goal is to create a “multi-intelligent terminal, full scene distributed operating system”. Compared with AliOS, Hongmeng was born at the right time and has enough space.

Follow us every week for 3 mobile dry goods & Practices to give you thinking!