How We Cut Feed Lag in iQIYI Kids App: A Deep Dive into Mobile Performance Optimization

Project Background

The iQIYI "Qibabu" app is a customized educational‑entertainment platform for children aged 0‑8, offering high‑quality animated content with a simple, child‑centric UI that won the 2018 German Red Dot Design Award. The engineering team continuously refines the app’s architecture to improve cold‑start time, crash resistance, memory usage, battery consumption, and package size.

Problem Status

On older devices the home‑page feed becomes noticeably janky, especially when scrolling with embedded video playback. The lag degrades the user experience and is traced to several performance‑critical paths.

Cause of Lag

Screen refresh is hardware‑driven (typically 60 Hz). When rendering exceeds a refresh interval, frames are dropped, causing visible stutter.

Multiple card styles in the feed lead to long cumulative initialization times.

Local images are read and rendered on the main thread, wasting CPU cycles.

The image library (a customized SDWebImage) performs disk‑cache reads on the main thread, adding latency.

Player start/stop operations during scrolling are costly.

Frequent Pingback submissions triggered by card exposure increase main‑thread workload.

Solution

Async Card Data Parsing and Rendering

A custom dispatch queue created with NSQualityOfServiceUserInitiated limits concurrency based on the device’s active CPU cores. Card data parsing, layout calculation, player initialization, and image/text rendering are off‑loaded to this queue, reducing thread‑switch overhead.

Home‑Page Card Preloading

Because the first few screens of the feed contain mostly static recommendation cards, the app preloads instances of these cards during cold start. The strategy is:

When the app launches, the feed JSON from the previous session is loaded from local disk cache.

Card class names are cached in memory, allowing instant instantiation when the user scrolls.

Preloading is triggered only when the main thread’s run‑loop enters DefaultMode and is about to sleep, indicating the user is not interacting.

Local Image Pre‑decoding

Many cards contain local placeholder and badge images that were previously read and decoded on the main thread. The new approach moves I/O to a background thread and generates a bitmap in memory before the image is needed. The implementation:

After the home page finishes rendering, a background task iterates over frequently used badge and placeholder images, creates a CGImage bitmap, and stores it in a dictionary keyed by image name.

Calls to [UIImage imageNamed:] are hooked to return the pre‑decoded bitmap, bypassing disk I/O and decoding.

For iOS 15+ the system method imageByPreparingForDisplay is used; older versions fall back to CGBitmapContext forced decoding.

Image Cache Read Optimization

The image library’s cache‑lookup logic is streamlined so that when a card re‑appears, the already‑cached image is displayed directly without invoking the library’s additional business‑logic checks.

Other Optimizations

Player start/stop is avoided during scrolling; the player maintains its state, and explicit stop‑loading APIs are called when a card goes off‑screen.

Pingback frequency is throttled during scroll events, slightly reducing exposure precision but staying within acceptable limits.

Project Summary

Technical Summary

The optimization techniques are illustrated in the following UML sequence diagram:

Results

Using Xcode’s Scroll Hitch Rate monitor, the average hitch per second dropped to 1.4 ms, well below Apple’s 5 ms smooth‑scroll threshold, even on low‑end devices. This measurable improvement translates into a noticeably smoother scrolling experience for users.

Note: Scroll Hitch Rate is calculated as total hitch time divided by total scroll duration, reflecting the severity of perceived lag.