How Baidu App Prevents OOM Crashes with Real‑Time Memory Management

Background

As Baidu App grew, many high‑memory scenarios such as live streaming, short video, mini‑programs, and image recognition appeared. Over 150 M pages exceed 40 M memory, with the most demanding pages reaching 400 M. While a single page rarely crashes, the cumulative memory of many pages can push the app into a high‑water‑mark state, causing OOM on low‑end devices.

Problem Statement

The goal is to keep the app stable and responsive when memory levels are high, extending usage time while preventing OOM.

Technical Solution Overview

The solution consists of six modules:

Real‑time memory monitoring : A background timer samples the phys_footprint field every 3 seconds, providing a single, low‑overhead memory metric.

Page memory prediction : Using historical data, the system predicts the memory increase of a page before it is opened, allowing pre‑emptive actions.

Memory water‑mark judgment : Determines whether the current memory level is safe or dangerous .

Frequency control : Limits the frequency of memory‑release notifications to avoid performance loss.

Dangerous‑water‑mark alarm : Sends alerts to both the base‑service layer (automatic image and NSURLCache reclamation) and the business layer (targeted cache clearing for high‑memory pages).

Active downgrade : When the water‑mark is dangerous, business logic allocates a smaller memory budget; otherwise full allocation is allowed.

The overall architecture is illustrated below:

Difference from iOS System Memory Alarm

iOS provides a memory‑alarm mechanism that triggers only when memory is critically low, sending a NOTE_VM_PRESSURE to the most memory‑intensive process. Baidu App’s solution adds two capabilities:

Continuous real‑time memory status, enabling prediction before the system alarm fires.

Customizable water‑marks per device, allowing proactive memory release.

Why phys_footprint ?

All iOS memory metrics are defined in task_vm_info. phys_footprint aggregates internal memory, compressed memory, I/O‑mapped memory, purgeable non‑volatile memory, and page tables, making it the most accurate indicator of actual memory pressure used by Jetsam.

struct task_vm_info {
    mach_vm_size_t  virtual_size;       /* virtual memory size (bytes) */
    integer_t       page_size;
    mach_vm_size_t  resident_size;      /* resident memory size (bytes) */
    mach_vm_size_t  phys_footprint;
    /* ... */
}

Page Memory Prediction

When navigating from page P1 to P2, the current phys_footprint (M1) is recorded. After opening P2, the new value (M2) is recorded; the difference (M2‑M1) represents P2’s memory cost. Only push‑based navigation is used to avoid bad cases caused by pop‑based singleton creation.

Determining Memory Water‑Marks

Three thresholds are derived:

Baseline from online memory sampling (maximum observed safe usage).

Page‑level increase threshold from historical page‑memory data.

Active OOM‑triggered threshold obtained by deliberately allocating memory until Jetsam kills the process.

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

Implementation Details

Key code snippets:

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

(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;
}

Jetsam internals are accessed via XNU source files such as kern_memorystatus.c and kern_memorystatus.h, using structures like memorystatus_priority_entry_t and commands like MEMORYSTATUS_CMD_GET_PRIORITY_LIST to retrieve per‑process limits.

typedef struct memorystatus_priority_entry {
    pid_t   pid;
    int32_t priority;
    uint64_t user_data;
    int32_t limit;   // memory water‑mark
    uint32_t state;
} memorystatus_priority_entry_t;

Summary

Device‑specific water‑marks enable graceful memory release without affecting user experience.

Real‑time monitoring plus page‑level prediction reduces OOM by up to 50%.

Both proactive (dangerous‑water‑mark downgrade) and reactive (alarm‑based release) mechanisms improve performance compared to previous server‑side full‑downgrade approaches.

References

OOM investigation: XNU memory state management – https://www.jianshu.com/p/4458700a8ba8

XNU source – https://opensource.apple.com/source/xnu/

Deep analysis of macOS & iOS – 《深入解析Mac OS X & iOS操作系统》

iOS OOM principles – https://juejin.cn/post/6844903749836603400#heading-7