Boosting HarmonyOS Mini‑Program Performance with Cangjie: A JD Case Study

Background Introduction

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

Mini‑program Architecture

The JD HarmonyOS mini‑program framework follows a dual‑thread model: a JS logic thread runs the JS engine and business logic, while a WebView thread (UI main thread) handles rendering and user interaction. Worker sub‑threads may be spawned to assist tasks. The JS Bridge acts as a bridge layer, with native (C++) implementations dispatching JS API calls. When a JS API request arrives, the system checks for a native implementation; if absent, it falls back to ArkTS dispatch.

Performance Bottleneck Analysis

During page load and active phases, numerous JS API calls are issued. The JS thread initiates the call, the main thread processes it, and the result is returned, creating several bottlenecks:

High‑frequency APIs such as Storage, SystemInfo, and Network are invoked dozens of times during startup, causing main‑thread queuing and heavy load.

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

The JS Bridge relies on many nAPI interfaces, spawning nAPI threads; handling hundreds of APIs purely in native code is costly and impractical.

Native JS API Call Process Decomposition

Using the frequently called getSystemInfo API as an example, the call flow is:

JS thread submits the request to the main thread, which dispatches it to a task pool. After execution, the result is returned, allowing the pipeline to process the next API. Each call occupies main‑thread time, and frequent calls prevent timely handling of other WebView tasks.

Scenario Analysis

Trace analysis of a sample store mini‑program shows a cold‑start time of ~2800 ms, with 900‑1000 ms spent in WebView tasks interleaved with numerous getSystemInfo calls. Even with hash‑code caching, retrieving the cached value still consumes main‑thread time, indicating room for Cangjie‑based optimization.

Cangjie Refactoring Practice

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

As an official HarmonyOS language, Cangjie provides full system API support, enabling one‑to‑one rewrites of native APIs.

Thread‑pool capabilities allow JS API execution without occupying the main thread, and native memory sharing eliminates serialization overhead.

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

Seamless interop with ArkTS enables access to runtime and WebView information, ensuring correct API logic.

The refactored JS API execution flow is illustrated below:

Two modules are modified: the JSBridge incorporates Cangjie dispatch logic, and the getSystemInfo API is reimplemented in Cangjie, as shown:

Cangjie Optimization Effect

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

Future Plans and Outlook

Extend Cangjie implementation to more high‑frequency APIs and validate gains in popular scenarios such as instant food delivery.

Leverage Cangjie’s high‑concurrency to optimize network modules and onboard additional mini‑programs.

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

Apply Cangjie to new modules and features, capitalizing on its performance and security advantages for AI, cross‑screen, and high‑performance web use cases.

Support cross‑platform development (HarmonyOS, Android, iOS, PC) to unify JD’s multi‑endpoint capabilities and reduce development complexity.