Exploring OpenHarmony’s New JS UI Framework: Architecture, Code, and Development Insights

HarmonyOS and OpenHarmony Overview

HarmonyOS is Huawei's next‑generation operating system for IoT, watches, phones, tablets, TVs and other devices. In June 2021 OpenHarmony 2.0 Canary was released, open‑sourcing many subsystems and supporting devices with more than 128 MB memory. The article focuses on the new JavaScript UI framework introduced in this version.

System Architecture Layers

The system is divided into four layers: Application, Framework, System Service, and Kernel. The kernel layer includes the Linux macro‑kernel and LiteOS micro‑kernel with hardware drivers. The framework and system service layers contain many relatively independent subsystems, including the UI framework and Ability framework.

HarmonyOS vs OpenHarmony

OpenHarmony does not include GMS, HMS, or AOSP and does not support Android APIs. The commercial HarmonyOS version on Huawei phones includes additional proprietary components.

OpenHarmony UI Subsystem (ACE)

The open‑source version lacks a Java UI layer; instead it provides a JavaScript UI framework called ACE (Ability Cross‑platform Environment). Two repositories exist:

ace_engine_lite – ACE 2.0 (old architecture)

ace_ace_engine – ACE 1.0 (new architecture)

Source Code Directory Structure

OpenHarmony source is hosted on Gitee with over two hundred repositories. The main directory layout relevant to the UI framework is:

OpenHarmony/
  ├── applications          # sample apps
  ├── base                  # basic service subsystems
  ├── docs
  ├── domains               # enhanced service subsystems
  ├── drivers               # driver subsystem
  ├── foundation            # core system capabilities
  │   ├── aafwk                # Ability framework
  │   ├── ace                  # JS UI framework
  │   │   ├── ace_engine           # ACE 1.0 (ace_ace_engine)
  │   │   └── ace_engine_lite      # ACE 2.0 (ace_engine_lite)
  │   ├── appexecfwk           # app execution framework
  │   └── graphic              # graphics libraries
  ├── interface
  │   └── sdk-js               # TypeScript definitions for JS APIs
  ├── kernel                # LiteOS kernel
  │   ├── liteos_a
  │   └── liteos_m
  └── third_party

To fetch the source, run:

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

ACE Framework Architecture

The ACE framework provides a DSL similar to mini‑programs (HML + CSS + JS). It compiles source files into a JavaScript bundle that is loaded at runtime. The framework consists of several layers:

Frontend : JavaScript or JSON execution environment.

TaskExecutor : Single‑threaded task manager.

AssetManager : Loads JS code, images, fonts, etc.

PipelineContext : Manages the rendering pipeline, handling vsync callbacks and dirty node queues.

AceView : Root UI node rendered by the engine.

PlatformResRegister : Registers platform resources and communication interfaces.

JS UI Development Types

Three frontend implementations exist:

JS Frontend (Command‑style UI) : Uses rendering commands; syntax resembles mini‑programs (e.g., xx.hml, xx.css, xx.js, xx.json).

Declarative Frontend (JSView) : Similar to Flutter’s widget system; UI is built with atomic layout functions and supports decorators/annotations.

Card Frontend : No script engine; UI driven by a JSON format with template, styles, actions, and data sections, allowing limited dynamic updates via UpdateData().

Node Construction Process

All three frontend types eventually generate C++ rendering commands that build an internal DOM‑like tree, which is then transformed into a component tree and finally into render nodes. Render nodes form a layer tree that the porting layer submits to platform‑specific compositors.

Rendering Pipeline

The PipelineContext stores dirty node queues. On each vsync event, it flushes these queues, invoking OnLayout() to compute layout, then Repaint() to draw and generate the layer tree.

Discussion on HarmonyOS Future

HarmonyOS targets a distributed OS for a wide range of smart devices, emphasizing a micro‑kernel that can be plugged into IoT, wearables, and automotive hardware. Its Ability model enables cross‑device flow, potentially creating new interaction patterns. The article argues that without distinctive system‑level innovations beyond Android compatibility, HarmonyOS may struggle to achieve a breakthrough, but its open‑source UI framework and micro‑kernel design provide a solid foundation for future growth.