JDImage: JD’s Self‑Developed HarmonyOS Image Library – Architecture, Implementation, and Performance Optimizations

In early 2024 JD started developing a HarmonyOS version of its e‑commerce app, recognizing that image loading performance is crucial for displaying product information. To meet the high performance and loading‑experience requirements, JD decided to build a self‑developed image library, JDImage, as a core capability in the first phase of HarmonyOS infrastructure.

Pre‑research revealed two native approaches on HarmonyOS: the built‑in System Image component, which offers basic loading but suffers from limited functionality, poor performance under concurrent loads, lack of AVIF support, and no extensibility; and the third‑party ImageKnife library, a HarmonyOS port of Android’s Glide, which improves features but still falls short in performance, stability, and extensibility.

Because neither solution satisfied JD’s needs and to reduce the maintenance cost of supporting an additional platform, the team chose to develop a C++‑core image library. This approach enables cross‑platform reuse (future expansion to iOS and Android), seamless integration with the Taro Harmony framework via CAPI, and higher runtime performance compared with ArkTS.

Core Modules

Image Cache : Memory cache using an LRU algorithm and disk cache with multi‑threaded read/write to reduce network traffic.

Data Source : Supports HTTP (implemented with Cornet for high‑performance parallel downloads) and Base64 sources.

Decoder : System decoder for common formats (PNG, JPG, GIF, WebP, SVG) and an AVIF decoder based on libavif.

Performance Monitoring : Tracks loading stages, cache hit rates, format usage, and resource consumption.

Image Component : Wraps the system Image component, accepting a decoded PixelMap via the src attribute and providing extra properties such as lazy , sourceSize , and priority for performance tuning.

Performance Optimizations

The loading pipeline, inspired by Fresco, allows flexible scheduling of sub‑tasks (decoding, caching, network request) and uses HarmonyOS’s FFRT framework for high‑performance thread dispatch. It includes duplicate‑task aggregation, cancellation/retry logic, and integration with JD’s image server to apply on‑the‑fly transformations (scaling, quality reduction, format conversion) that reduce network payload.

Quality Assurance

Online monitoring of loading success rates, latency, and resource usage.

Exception monitoring with distinct error codes and severity levels, reporting both warnings and errors.

Recovery mechanisms: pipeline retry, component fallback to the system Image component, and remote‑configuration‑driven degradation for specific devices or app versions.

Future Plans

Network optimizations such as weak‑network handling and HTTPDNS.

Further performance gains via cache reuse, memory‑pooling, GIF optimization, and low‑end device tuning.

Deeper integration with JD’s image server for dynamic resizing, quality adjustment, and format selection.

Expanding support to additional platforms (iOS, Android) and adding more image‑type capabilities.

Enhancing visual quality with advanced interpolation, super‑resolution, and HDR techniques.

Since its integration with Taro, JDImage has been deployed in the JD HarmonyOS app, delivering improved loading speed and stability. Ongoing work will continue to refine performance, extend functionality, and explore broader cross‑platform applications.