How JD Boosted Mini‑Program Performance with Cangjie on HarmonyOS

Background

JD's mini‑program container is a core component of JD and its related apps, supporting numerous internal and external services such as rapid‑delivery food, grocery shopping, and luxury store mini‑programs.

Mini‑Program Architecture

The JD HarmonyOS mini‑program framework follows a dual‑thread model: a JS logic thread runs the JavaScript engine and business logic, while a WebView thread (UI main thread) handles rendering and user interaction. Worker sub‑threads may be spawned for auxiliary tasks. The JS Bridge acts as a bridge layer, with API dispatch implemented in native C++.

Performance Bottleneck Analysis

During page load and active phases, a large number of JS API calls are issued, creating three main bottlenecks:

Frequent startup calls to APIs such as Storage, SystemInfo, and Network cause main‑thread queuing and high CPU usage.

Cross‑thread data transfer requires serialization and deserialization, increasing latency.

The JS Bridge relies on numerous nAPI interfaces, spawning nAPI threads that are inefficient and costly to maintain.

Native JS API Call Process Breakdown

Using the high‑frequency getSystemInfo API as an example, the call originates in the JS thread, is handed to the main thread, processed by a task pool, and then returns the result. Each call occupies main‑thread time, leading to delays when the API is invoked repeatedly.

Scenario Analysis

Trace analysis of a store mini‑program shows a cold‑start duration of about 2800 ms, with roughly 900‑1000 ms spent in WebView tasks dominated by repeated getSystemInfo calls. Even with cached results, each retrieval still blocks the main thread.

Cangjie Transformation Practice

Cangjie offers several advantages for this scenario:

As an official HarmonyOS language, it provides complete system APIs, enabling a 1‑to‑1 rewrite of native APIs.

Its built‑in thread pool allows JS API execution off the main thread and shares memory across threads, eliminating serialization overhead.

Efficient C interop means calls between C and Cangjie code are simple and fast, avoiding nAPI.

Seamless interop with ArkTS runtime ensures correct API behavior.

The transformed JS API execution flow is illustrated below:

Two modules were modified: the JSBridge now includes Cangjie dispatch logic, and the getSystemInfo API was reimplemented in Cangjie.

Cangjie Optimization Effects

Testing shows that the Cangjie‑based getSystemInfo execution time is reduced by more than 50% and no longer occupies the main thread. End‑to‑end cold‑start tests on a mini‑program demonstrate a performance gain of approximately 20% (about 500 ms).

Future Plans and Outlook

The initial validation confirms Cangjie’s efficiency and development potential for mini‑programs. Future work includes:

Rewriting additional high‑frequency APIs and validating gains in popular scenarios such as rapid‑delivery food.

Leveraging Cangjie’s concurrency to optimize network modules and onboard more mini‑programs.

Exploring Cangjie optimizations beyond JS APIs, covering other stages of the mini‑program lifecycle.

Applying Cangjie to new modules and features, especially in AI, cross‑screen, and high‑performance web contexts.

Extending cross‑platform support to Android, iOS, and PC, consolidating JD’s multi‑device development capabilities.