How Baidu App Prevents OOM Crashes with Real‑Time Memory Monitoring and Prediction

Background

As Baidu's app grew, many high‑memory scenarios such as live streaming, short video, mini‑programs, and image recognition caused over 150 pages to exceed 400 MB, leading to frequent OOM crashes on low‑end devices when multiple pages were visited sequentially.

Technical Overview

The memory‑control scheme, launched in Q1 2022, monitors memory continuously, predicts page memory consumption, determines safe and dangerous water‑levels, and triggers alerts, frequency control, and proactive downgrade to keep the app stable.

Real‑time Memory Monitoring

A background thread runs a timer every 3 seconds, sampling the phys_footprint field from task_vm_info. This metric is lightweight (<1 µs per sample) and provides sufficient real‑time accuracy without noticeable CPU overhead.

int64_t memoryUsage() {
    int64_t memoryUsageInByte = 0;
    struct task_vm_info info;
    mach_msg_type_number_t size = TASK_VM_INFO_COUNT;
    kern_return_t kerr = task_info(mach_task_self(), TASK_VM_INFO, (task_info_t)&info, &size);
    if (kerr == KERN_SUCCESS) {
        memoryUsageInByte = info.phys_footprint;
    }
    return memoryUsageInByte;
}

Page Memory Prediction

When a push navigation from page P1 to P2 occurs, the current phys_footprint (M1) is recorded. After P2 loads, a new value (M2) is captured; the difference (M2‑M1) represents P2's memory cost. This prediction allows the system to anticipate whether opening a new page will cross the dangerous water‑level.

Water‑Level Determination

Three thresholds are combined:

Data‑driven baseline: maximum observed memory without OOM for each device.

Page‑level increase: maximum predicted rise when a new page opens.

Active OOM trigger: a synthetic OOM test that allocates memory until the system kills the app, revealing the Jetsam limit.

The final dangerous water‑level is the active‑OOM threshold minus the page‑level increase; if this value is lower than the baseline, the baseline becomes the final limit.

Frequency Control & Proactive Degradation

When the app stays in the dangerous zone, a 3‑second timer notifies modules to release caches. To avoid wasteful repeated releases, a frequency‑control module throttles the notifications, balancing memory recovery with performance impact. Business code can also downgrade memory‑intensive features (e.g., loading a smaller model) when the dangerous level is reached.

Implementation Details

Key code snippets used in the solution:

int size = 20 * 1024 * 1024;
char *info = malloc(size);
memset(info, 1, size);

These allocate 20 MB every second to provoke OOM and capture the Jetsam limit.

Conclusion

The Baidu app memory‑control system combines real‑time phys_footprint monitoring, page‑level prediction, and multi‑source water‑level calculation to halve OOM rates on low‑end iOS devices while keeping user experience smooth.