Boosting Mini‑Program Performance on HarmonyOS: How Cangjie Cuts API Latency by 50%

Background

JD.com’s mini‑program container is a core component of JD’s ecosystem, supporting various business modules such as rapid‑delivery food, grocery, and luxury store mini‑apps.

Mini‑Program Architecture

The JD HarmonyOS mini‑program framework adopts 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. Workers may be spawned for auxiliary tasks. The JS Bridge, implemented in native C++, dispatches JS API calls, delegating to ArkTS when no native implementation exists.

Performance Bottleneck Analysis

During page load and active phases, numerous JS API calls are issued. Calls originate from the JS thread, are processed on the main thread, and then return results, causing several bottlenecks:

High‑frequency APIs such as Storage , SystemInfo , and Network are invoked dozens of times during startup, queuing on the main thread and blocking WebView tasks.

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

The JS Bridge relies on many nAPI interfaces, creating additional threads and overhead; handling all APIs natively would be impractical.

Native JS API Call Dissection

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

JS thread submits the request to the main thread.

The main thread enqueues the task in a task pool.

After execution, the result is returned to the JS thread.

Each call occupies main‑thread time, and repeated invocations delay other WebView operations.

Scenario Analysis

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

Cangjie Transformation Practice

Cangjie offers several advantages for this scenario:

As an official HarmonyOS language, it provides one‑to‑one native API bindings.

Its built‑in thread‑pool allows JS API execution off the main thread, eliminating serialization overhead.

Efficient C interop means calls are simple declarations without nAPI overhead.

Seamless ArkTS interop enables access to runtime and WebView information for correct API behavior.

The revised execution flow moves the getSystemInfo implementation to Cangjie, bypassing the main thread.

Optimization Results

Testing shows the Cangjie‑based getSystemInfo runs over 50 % faster and no longer blocks the main thread. End‑to‑end cold‑start tests on a sample mini‑program reveal a total startup improvement of about 20 % (≈500 ms).

Future Plans and Outlook

Building on this proof‑of‑concept, the team plans to:

Port more high‑frequency APIs to Cangjie and validate gains in popular scenarios like rapid‑delivery.

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

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

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

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