JD's Self‑Developed HarmonyOS Image Library: Architecture, Implementation, and Performance Optimizations

Background

At the beginning of 2024 JD launched the development of a HarmonyOS app. Because e‑commerce apps heavily rely on images, the image library became a core capability and was included in the first phase of JD's HarmonyOS infrastructure construction. This article introduces the development process and technical principles of JD's self‑developed HarmonyOS image library.

Technical Implementation

Pre‑research

Our research found that HarmonyOS network image loading mainly uses two approaches:

System – Image component

The built‑in Image component provides basic loading but suffers from low performance, lack of AVIF support, no quality monitoring, and limited extensibility.

Third‑party – ImageKnife

Inspired by Android libraries such as Glide, ImageKnife implements a HarmonyOS version using ArkTS. Although it improves on the system component, it still falls short in performance, stability, and extensibility.

Because neither the system Image component nor ImageKnife met our requirements, we decided to develop our own image library. With HarmonyOS adding a new platform alongside iOS and Android, JD aims to achieve cross‑platform reuse and consistent capabilities.

Why C++ Core

Cross‑platform reuse: core modules written in C++ can be shared across iOS, Android, and HarmonyOS.

Adaptation to Taro: the Taro‑Harmony framework relies on CAPI; using C++ reduces communication overhead between ArkTS and C++.

High performance: C++ runtime outperforms ArkTS for image processing tasks.

JDImage Capabilities

Architecture Design

Using C++ for cross‑platform development introduces compatibility challenges, so we provide abstraction layers to flexibly replace platform‑specific modules. The design references mature iOS/Android libraries such as SDWebImage, Glide, and Fresco.

We adopt modularization and layered architecture: the library is split into independent modules, enhancing flexibility and replaceability. The architecture consists of a Core layer (implemented in C++) and a Client layer for platform‑specific implementations.

Core Modules Introduction

The library consists of image cache, decoder, data source fetcher, performance monitoring, and image component modules, which are loosely coupled.

Image Cache

Memory cache: stores decoded bitmaps using an LRU algorithm, with configurable size and eviction policies.

Disk cache: saves downloaded images in the app sandbox, supports multithreaded read/write for high performance.

Image Data Source

Provides multiple source implementations on HarmonyOS:

HTTP: downloads images via Cornet for high‑performance parallel requests.

Base64: reads images encoded in Base64 format.

Decoder

System decoder: leverages HarmonyOS hardware decoding for PNG, JPG, GIF, WebP, SVG, etc.

AVIF decoder: integrates libavif to support AVIF images.

Performance Monitoring

Loading performance: records stage timings, cache hit rates, format statistics, and resource consumption.

Exception monitoring: captures errors with unique codes and classifies them as warnings or critical exceptions.

Image Component

The component wraps the system Image component, rendering decoded PixelMap via the src attribute. It adds lazy loading, sourceSize , and priority attributes for performance.

Performance Optimization

Image Loading Pipeline

The pipeline, inspired by Fresco, includes scheduling, module invocation, thread dispatch using HarmonyOS FFRT , task aggregation, monitoring, and retry/cancel mechanisms.

Server‑Side Optimization

JD's image server supports on‑the‑fly transformations (format conversion, compression, resizing, rounding, grayscale). The pipeline can automatically append parameters to reduce network traffic, e.g., using .avif for smaller payloads.

Quality Assurance

Online Monitoring

Exception Monitoring

Each pipeline task defines custom exception objects with unique error codes, classified as exceptions or warnings, and reported according to a strategy.

Performance Monitoring

Task start/end timestamps are recorded to calculate stage durations and assist in fault analysis.

Exception Recovery

Pipeline Retry

Pre‑processing may alter URLs; if loading fails, the pipeline applies retry strategies based on error type.

Component Degradation

If retries fail, the component falls back to the system Image component, and ultimately to a fallback image if necessary.

Online Configuration Degradation

Using the mobile config SDK, JD can force degradation for specific users, devices, or app versions.

Future Plans

Network optimization: weak‑network handling, HTTPDNS.

Performance optimization: increase cache reuse, heap pool, GIF playback, low‑end device tuning.

Leverage server capabilities: dynamic resizing, quality, format selection.

Feature expansion: more loading parameters, support for additional image types.

Platform expansion: support iOS, Android, and other platforms.

Image quality enhancement: different interpolation methods, super‑resolution, HDR.

Summary

JD's self‑developed HarmonyOS image library, built with a modular design and pipeline scheduling, resolves cross‑platform development complexity while improving maintainability and stability. Multi‑layer exception handling ensures business reliability. The library meets JD's high‑performance image loading needs on HarmonyOS and lays a foundation for future cross‑platform development.

The library is already integrated via Taro into JD's HarmonyOS app, delivering solid loading experience and stability. Ongoing work will focus on performance tuning, feature expansion, and exploring broader platform support.