Frontend Development 11 min read

Dynamic Cross‑Platform Adaptation to HarmonyOS: Architecture, Key Technologies, and Future Plans

The article explains how JD Finance’s Dynamic framework is adapted to HarmonyOS through V8 porting, JSI communication, UI rendering and layout solutions, outlines the challenges of native development, and presents future directions such as self‑drawing rendering and mini‑program conversion.

JD Tech Talk
JD Tech Talk
JD Tech Talk
Dynamic Cross‑Platform Adaptation to HarmonyOS: Architecture, Key Technologies, and Future Plans

1. Background

At the Huawei official release on 2023‑09‑25, it was announced that the new HarmonyOS will no longer be compatible with Android applications, meaning all Android apps, including JD Finance, will be unable to run on the new system and must be redeveloped as dedicated HarmonyOS apps.

2. Native Adaptation Solution

The native approach rewrites all business and infrastructure layers of the JD Finance app using HarmonyOS language, but it suffers from three major problems:

High initial development cost: a 1:1 rewrite leads to long cycles and huge R&D investment.

High iteration cost: future features must be developed simultaneously for iOS, Android, HarmonyOS, increasing product communication, development, testing, and UI acceptance effort.

Low release efficiency: each release requires submission, review, and publishing on Huawei Market, resulting in long cycles and no on‑demand deployment.

3. Dynamic Adaptation Solution

“Dynamic” is a self‑developed cross‑platform solution from JD Finance’s front‑end team that enables a single codebase to run on iOS, Android, and Web.

3.1 Solution Overview

The dynamic approach already supports iOS, Android, and H5. By integrating this capability with HarmonyOS, the initial adaptation effort is reduced, a single development serves four platforms, long‑term iteration costs drop, and on‑demand publishing becomes possible.

3.2 Implementation Details

The implementation on HarmonyOS follows a process similar to Android but faces challenges such as the lack of a V8 or JSCore virtual machine, complex core‑layer communication, and the need to port layout libraries.

The cross‑platform framework relies on a JavaScript virtual machine. iOS uses JSCore, Android uses V8, while HarmonyOS provides neither, so V8 must be ported (V8 For Harmony).

After porting V8, the ArkTS language wraps the V8 interfaces (ArkTs2V8) for object creation, memory management, and communication.

Running the RomaEngine JS file generates a virtual DOM (V‑Dom) tree and performs diffing to trigger UI updates.

For communication, the existing JSON‑based bridge on iOS/Android shows performance bottlenecks under heavy data loads. HarmonyOS adopts the industry‑standard JSI to establish JS ↔ native (C++) communication.

Using JSI, native C++ receives commands from JS; HarmonyOS’s UI language is ArkTS, so communication between C++ and ArkTS is achieved via the NAPI interface, forming a JS → C++ → ArkTS pipeline. Custom components enable recursive construction of the native UI tree.

The Yoga layout library is ported to HarmonyOS to compute final positions and sizes of UI elements, completing the rendering pipeline.

Interaction handling example: a button click triggers an ArkTS → C++ → JS communication chain to forward the event to the business layer.

3.3 Key Technologies

V8 Virtual Machine Porting

Porting V8 to HarmonyOS is a high‑difficulty task requiring cross‑compilation knowledge (CMake, Clang, LLVM, Ninja). The team has mastered V8 cross‑compilation techniques.

Huawei‑Built‑In V8

Short‑term, the team has a working V8 port; long‑term, embedding V8 into the OS reduces package size, improves stability, and benefits all dynamic frameworks.

Communication Scheme Design

HarmonyOS provides NAPI for ArkTS ↔ C/C++ communication. The dynamic framework uses JSI to connect the JS engine with the C++ host, establishing JS ↔ C++ ↔ ArkTS communication.

Page Rendering Scheme

Initial Rendering

RomaEngine creates a V‑Dom tree; through the JSI channel, ComponentTree nodes are created following the V‑Dom structure, then mapped to a RenderTree using HarmonyOS custom components.

Secondary Rendering

When data changes, a new V‑Dom tree is generated, diffed against the old one, and the resulting update list is sent via JSI to update the corresponding RenderTree nodes.

Layout Scheme

The Yoga library, a cross‑platform layout engine, is compiled for HarmonyOS to ensure consistent layout across iOS, Android, and HarmonyOS.

More Content

The article notes that many additional features such as interaction events, animations, lifecycle management, analytics, componentization, and charting will be covered in future series.

4. Future Plans

Self‑Drawing Solution

Beyond HarmonyOS, platforms like Xiaomi’s PengpaiOS and Vivo’s blueOS may also drop Android compatibility. The team plans to explore SKIA‑based self‑drawing technology to achieve a single rendering codebase for iOS, Android, HarmonyOS, PengpaiOS, blueOS, and future systems.

Mini‑Program Conversion

The V‑Dom based cross‑platform architecture can also generate code for WeChat, Douyin, Baidu, and other mini‑programs, enabling low‑cost, rapid private‑domain deployment.

Ecosystem Expansion

Future devices will form an interconnected world; the dynamic framework will continue to explore running on more devices, such as seamless integration between Huawei phones and car systems.

Frontendcross‑platformHarmonyOSV8JSI
JD Tech Talk
Written by

JD Tech Talk

Official JD Tech public account delivering best practices and technology innovation.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.