Boosting Mini-Program Performance on HarmonyOS with Cangjie: A Practical Guide

01 Background Introduction

JD.com mini-program container is a core component of JD.com and its associated apps, hosting various internal and external services such as fast‑delivery food, grocery, supermarket, and luxury store mini-programs.

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 acts as a bridge, dispatching JS API calls to native implementations (C++). When a JS API request arrives, the system checks for a native implementation; if absent, it falls back to ArkTS dispatch logic.

03 Performance Bottleneck Analysis

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

Frequent calls to Storage, SystemInfo, and Network APIs during startup cause main‑thread queuing and delay WebView tasks.

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

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

04 Native JS API Call Process Decomposition

Using the high‑frequency getSystemInfo API as an example, the call flow is:

getSystemInfo is implemented in ArkTS. The JS thread submits the request to the main thread, which executes it via a task pool and returns the result. Each call occupies main‑thread time, and frequent calls prevent timely WebView processing.

05 Scenario Analysis

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

06 Cangjie Refactoring Practice

Cangjie’s features that improve performance in this scenario include:

Official HarmonyOS language with full API support, enabling one‑to‑one native API rewrites.

Thread‑pool capability: Cangjie‑based JS APIs run off the main thread, and its native memory sharing eliminates serialization overhead.

Efficient C interop: C and Cangjie code call each other with simple declarations, avoiding nAPI overhead.

Seamless ArkTS interop: Cangjie can access ArkTS runtime and WebView information to ensure correct API logic.

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

The refactor focuses on two modules: adding Cangjie dispatch logic to the JS Bridge and implementing the getSystemInfo API in Cangjie.

07 Cangjie Optimization Results

Testing shows 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 20 % overall startup performance gain (≈500 ms).

08 Future Plans 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 include:

Porting additional high‑frequency APIs to Cangjie and evaluating performance in popular scenarios such as fast‑delivery.

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

Exploring Cangjie optimizations beyond JS APIs in other mini‑program stages.

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

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