How iQIYI Cut Memory Peaks by 60% and Boost Animated Image Loading by 75% with Cangjie on HarmonyOS

Background

With the official release of HarmonyOS NEXT, more applications are adopting native Harmony development. iQIYI, a leading video platform, seeks to deliver smoother, higher‑quality viewing by optimizing image loading on the Harmony ecosystem.

Challenges with ArkTS

ArkTS, the recommended language for Harmony, follows a single‑thread event‑loop model. Complex image decoding and processing tasks can block the main thread, causing UI jank during list scrolling or fast page flips. Although ArkTS supports Workers and TaskPool, developers must manually manage memory isolation, thread communication, and serialization, leading to high development and maintenance costs.

Need for AVIF

iQIYI heavily uses AVIF for its superior compression (40‑50% smaller than JPEG, 20‑30% smaller than WebP) and richer visual capabilities such as 10‑12‑bit depth, HDR, and alpha channels. However, the built‑in Image component of HarmonyOS does not yet support AVIF, creating a critical gap for efficient image delivery.

Task Characteristics

Image loading : frequent network requests and disk I/O, requiring concurrency control, timeout management, and caching strategies.

Image decoding : CPU‑intensive and memory‑heavy operations.

Image processing : scaling, cropping, filtering, often needing GPU acceleration.

These tasks demand strong concurrency, memory management, and performance from the chosen language.

Why Cangjie

Huawei's Cangjie language offers static strong typing with compile‑time error detection, built‑in memory‑safety via ownership and lifetimes, and an efficient user‑level thread model that shares memory while providing isolation. It also supports seamless inter‑operation with C libraries (e.g., libavif, libwebp) and ArkTS, allowing gradual migration of performance‑critical modules without rewriting the entire codebase.

Architecture

The library adopts a layered architecture:

ArkTS layer : UI presentation, lifecycle management, business logic.

Cangjie layer : core image loading, decoding, caching, task scheduling.

C layer : reuse of mature decoding libraries such as libavif and FFmpeg.

This mixed architecture preserves ArkTS development speed while leveraging Cangjie’s performance advantages and existing C implementations.

Image Loading Flow

Loading follows a “cache‑first, network‑fallback” three‑level strategy (memory LruCache → disk cache → network request). The main thread calls loadImage, which spawns an asynchronous task. Cached images are returned instantly; otherwise, the task decodes the image. Static images become a single‑frame PixelMap, while animated AVIF images are decoded into a frame sequence. All results are converted to PixelMap and rendered by the ArkUI Image component, keeping the UI layer unaware of the source.

Animated‑Image Optimizations

To handle animated images efficiently, Cangjie‑specific optimizations were added:

Frame‑level lock : serial processing of frames to maintain order and prevent visual glitches, implemented with Cangjie’s concurrency primitives.

Synchronization : ensures decoded frame data is promptly delivered to the render thread, balancing decode speed with frame‑rate stability.

Task‑queue management : schedules multiple decode tasks without blocking, giving priority to visible animations.

Key Optimizations

Interop callbacks such as aboutToReuse and aboutToRecycle link ArkTS lifecycle events with the Cangjie side, releasing resources promptly to avoid memory leaks.

Memory‑copy optimization using memcpy reduces unnecessary data copying between C and Cangjie, lowering memory‑bandwidth pressure.

Standard‑library async I/O, connection pooling, and batch disk reads improve concurrent network handling and reduce system‑call overhead.

Thread‑scheduling refinement keeps lightweight tasks on the main thread and only offloads heavy work (network, decode) to background threads, minimizing context‑switch costs.

Results

Compared with a pure ArkTS implementation, the Cangjie image library achieved:

Memory peak reduction >60%.

More stable memory usage curves, eliminating GC‑induced performance spikes.

Loading‑time benchmarks (average over 12 image types):

Network static image: 231 ms vs 305 ms (‑24%).

Disk static image: 63 ms vs 122 ms (‑48%).

Memory static image: 26 ms vs 50 ms (‑48%).

Network animated image: 406 ms vs 1648 ms (‑75%).

Disk animated image: 122 ms vs 134 ms (‑9%).

Memory animated image: 32 ms vs 38 ms (‑16%).

In production, these gains translate to faster first‑screen loads, smoother list scrolling, stable animated‑image playback, and lower overall memory consumption, reducing OOM risk.

Future Work

Planned directions include:

Supporting additional image formats, filters, watermarks, and intelligent cropping.

Finer cache strategies with pre‑loading and smart eviction.

Extending the library to other HarmonyOS devices (tablets, cars, TVs) for true “write once, run everywhere”.

Gradual open‑source of core modules and community‑driven best‑practice sharing.

Deep collaboration with the Cangjie team to grow the language ecosystem.

Special thanks to the Cangjie technology team for their support.