How Cangjie Boosts Performance of JD Mini‑Programs on HarmonyOS

Background Introduction

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

Mini‑Program Architecture

The JD HarmonyOS mini‑program framework follows a dual‑thread model: a JavaScript 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 for auxiliary tasks. The JS Bridge connects the two, delegating API calls to native C++ implementations; if no native implementation exists, the call falls back to ArkTS dispatch.

Performance Bottleneck Analysis

During page load and active phases, a large number of 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, queuing on the main thread and consuming significant time.

Data transfer between threads requires serialization/deserialization, increasing latency.

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

Native JS API Call Process

Using the frequently called getSystemInfo API as an example, the call originates from the JS thread, is handed to the main thread, which schedules it in a task pool, executes the native implementation (via ArkTS), and returns the result. Each call occupies main‑thread time, and frequent invocations prevent timely processing of other WebView tasks.

Scenario Analysis

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

Cangjie Refactoring Practice

Cangjie offers several advantages for this scenario:

As an official HarmonyOS language, it provides full system API coverage, enabling one‑to‑one native API rewrites.

Its thread‑pool model executes JS APIs off the main thread, eliminating main‑thread blockage and removing serialization overhead.

Efficient C inter‑op allows direct calls without the heavyweight nAPI protocol.

Seamless inter‑op with ArkTS grants access to runtime and WebView information, ensuring correct API behavior.

The refactored execution flow moves the getSystemInfo processing to a Cangjie thread, as shown below:

Two key modules were modified: the JS Bridge now includes Cangjie dispatch logic, and the getSystemInfo API implementation was rewritten in Cangjie.

Cangjie Optimization Effects

Testing shows that the Cangjie‑refactored getSystemInfo reduces execution time by over 50 % and eliminates main‑thread usage. End‑to‑end cold‑start tests on a sample mini‑program reveal a total performance gain of roughly 20 % (about 500 ms).

Future Plans and Outlook

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

Porting more high‑frequency APIs to Cangjie and validating gains in popular scenarios such as rapid‑delivery food.

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

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

Applying Cangjie to new modules and features, capitalizing on its performance and safety benefits for AI, cross‑screen, and high‑performance web use cases.

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