Unlocking 50% Faster JD Mini‑Programs on HarmonyOS with Cangjie

01 Background Introduction

JD's mini‑program container is a core component of JD and its related apps, hosting many internal and external services such as fast‑delivery food, grocery, supermarket, and luxury‑goods stores.

02 Mini‑Program Architecture

The JD HarmonyOS mini‑program framework consists of a dual‑thread architecture with a JS logic thread and a WebView thread. The JS thread runs the JS engine and business logic, while the WebView thread (UI main thread) handles rendering and user interaction. Workers may be spawned for auxiliary tasks. The JS Bridge mediates API calls, delegating to native C++ implementations or, if absent, to ArkTS dispatch logic.

03 Performance Bottleneck Analysis

During page load and active phases, numerous JS API calls are issued. The typical flow—JS thread → main thread → result → back to JS—creates bottlenecks:

Frequent calls to Storage, SystemInfo, and Network APIs during startup cause queuing on the main thread, consuming significant time and delaying WebView tasks.

Data must be serialized between threads, adding latency.

The JS Bridge relies on many nAPI interfaces, spawning nAPI threads; handling hundreds of APIs natively would be costly and impractical.

04 Native JS API Call Process Decomposition

The getSystemInfo API, a high‑frequency call, is implemented in ArkTS. The call is submitted by the JS thread to the main thread, which dispatches it to a task pool, receives the result, and returns it. Each call occupies main‑thread time, and frequent invocations block WebView tasks.

05 Scenario Analysis

Trace analysis of a store mini‑program shows a cold‑start of ~2800 ms, with 900‑1000 ms spent in WebView tasks interleaved with many getSystemInfo calls. Even with hash‑based caching, each cache retrieval still occupies the main thread, indicating room for Cangjie‑based optimization.

06 Cangjie Transformation Practice

Cangjie’s features that enable performance gains in this scenario include:

Official HarmonyOS language with full API support, allowing 1‑to‑1 rewriting of native APIs.

Thread‑pool capability; Cangjie‑based JS APIs run off the main thread, eliminating main‑thread blocking and avoiding serialization overhead.

Efficient C interop; C and Cangjie code can call each other with simple declarations, avoiding costly nAPI protocols.

Seamless ArkTS interop; Cangjie can access ArkTS runtime, WebView information, ensuring correct API logic.

The revised JS API execution flow using Cangjie is illustrated below:

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

07 Cangjie Optimization Effect

Testing shows that the Cangjie‑rewritten 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 20% overall startup improvement (≈500 ms).

08 Future Planning and Outlook

The initial validation confirms Cangjie’s efficiency and development potential for mini‑programs. Building on the Cangjie JS‑API dispatch framework, future work will focus on:

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

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

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

Applying Cangjie to new modules and features, benefiting AI, cross‑screen, and high‑performance web use cases.

Extending cross‑platform support (HarmonyOS, Android, iOS, PC) to simplify multi‑platform development.