In the Overview of Jank and Frame Drops in Android - System Layer article, we touched upon jank cases caused by low system memory. Since low memory has a significant impact on overall device performance, I’m dedicating this article to exploring those effects in depth.
As Android versions evolve and apps become more feature-heavy, their memory requirements increase. When this article was written in 2019, many devices had 4GB of RAM or less. These users are prone to low memory situations, especially after major system updates or as more apps and services run concurrently.
Memory pressure can contribute to slow responsiveness and jank. Examples include longer app launch times, more frame drops in scrolling, more frequent cold starts as background processes are killed, and extra reclaim/restart work that can increase power use. Heat alone does not diagnose memory pressure. Below, I’ll outline the causes, debugging methods, and potential optimizations for these issues.
Version note — technical review, 2026-10-13: This article retains 2019 logs and Systrace cases. Old kernel LMK logs, tuning interfaces, and function names have version limits. Updates below cover Android 10/11 PSI/lmkd, Android 16 framework code, and Linux 6.6 reclaim mechanisms. Complete original traces and controlled experimental conditions are unavailable; the review corrects visible evidence rather than presenting a new device benchmark.
- Overview of Jank and Frame Drops in Android - Methodology
- Overview of Jank and Frame Drops in Android - System Layer
- Overview of Jank and Frame Drops in Android - Application Layer
- Overview of Jank and Frame Drops in Android - Low Memory
Identifying Low Memory
Meminfo Data
Start with Android’s system summary, then correlate processes and changes over time:
1 | adb shell dumpsys meminfo |
The original output is preserved below. 156,ba480K is corrupted text, not a valid number to reconstruct by guessing.
1 | ...... |
This is not a universal low-memory signature:
- In Android 9 AMS,
Free RAMcombines cached-process PSS, some kernel caches, and actually free pages. It differs from bothMemFreeandMemAvailablein/proc/meminfo. Used RAMandLost RAMuse different accounting involving PSS, swap PSS, kernel, and ZRAM values. Here, Used exceeds Total and Lost is negative. Check the system branch and original samples; do not interpret this as physically negative memory or proof of a leak.status moderateis also a framework state, not a per-frame pressure measurement.2,608K physical used,301,256K in swap, and4,247,544K total swapdescribe physical consumption, used swap space, and swap capacity. They are not interchangeable ZRAM utilization measures. These figures alone do not support the original claim of very high ZRAM use.
Caches are useful. Look for sustained loss of available memory, stalls from reclaim or swap-in, and foreground responsiveness in the same interval. A single low-free-memory snapshot is insufficient.
LMK and kswapd Activity
This is a historical in-kernel lowmemorykiller driver log, not the universal format of modern userspace lmkd:
1 | [kswapd0] lowmemorykiller: Killing 'u.mzsyncservice' (15609) (tgid 15609), adj 906, |
It records selecting PID 15609, adj 906, in kswapd0‘s reclaim context, with cache 258652kB, threshold 261272kB, and other conditions. It does not establish a universal “adj 900 watermark.” -5540kB above reserved is a value after reserve accounting, not a negative physical free-page count. The exact selection policy requires that vendor’s kernel source.
kswapd performs background page reclaim. The old LMK driver and userspace lmkd are separate implementations; neither should be conflated with the Linux OOM killer or AMS cached/empty-process trimming. Active kswapd alone does not prove that a process was killed.
Version update: The AOSP lmkd guide describes PSI support in Android 10 and the Android 11 strategy’s additional consideration of memory use and page-cache thrashing. Actual operation depends on kernel support and product configuration. Use that version’s lmkd reasons and pressure data rather than searching only for the old lowmemorykiller: prefix.
/proc/meminfo
Read the kernel summary with the leading slash in the path:
1 | adb shell cat /proc/meminfo |
This original sample has a different MemTotal from the dumpsys sample. Do not treat them as one synchronized device snapshot.
1 | MemTotal: 5630104 kB |
The Linux 6.6 /proc documentation distinguishes free RAM (MemFree) from an estimate of memory available to new applications without swapping (MemAvailable), accounting for reclaimable caches and reserves. The values here are 148928 kB and 864172 kB; they are not both almost zero. SwapFree of 42576 kB shows heavily used swap space, not necessarily active swap churn at this instant. Committed_AS is not physical residency.
Where the kernel provides the interfaces and permissions allow them, further read-only observations include:
1 | adb shell cat /proc/vmstat |
Use deltas around a reproduction for reclaim scans/successes, allocstall*, pswpin/pswpout, and workingset_refault*; field names vary by kernel. Large lifetime totals do not date a stall. PSI some measures time with at least some tasks stalled; full measures simultaneous stalls of all non-idle tasks. avg10/60/300 are time percentages over those windows in seconds; total is cumulative microseconds. See the PSI documentation. Missing interfaces, denied access, or uncaptured data mean unavailable, not zero pressure.
System-wide Lag & Slow Response
Memory pressure can contribute to slow launches, dropped frames, and more cold starts, but CPU, storage, locks, and other loads can cause similar symptoms. Align the user-visible delay with pressure, reclaim, thread waits, and process-exit evidence before placing memory on the critical path.
Impact of Low Memory on Performance
Main Thread I/O Latency
Pressure adds reclaim work, may evict file pages needed soon afterward, and may cause swap-related work. Foreground latency grows if the thread then waits for pages or storage completion.
Distinguish plain Uninterruptible Sleep from subclasses tagged Block I/O, and inspect the blocking call site. D state or a yellow color alone does not establish disk I/O. wait_on_page_bit_killable indicates a page-state wait, not by itself low memory, a specific file, or saturated storage. Cached reads need not block this way; loading a View does not necessarily read storage.
The SystemUI screenshot shows io_schedule as its blocking call site. That supports investigating I/O waits, but supplies no simultaneous memory-pressure value:
The next screenshot shows OPScreenRecord in bindApplication, including APK/OAT loading. Its thread states suggest waits during startup; color alone does not identify every wait’s cause.
CPU Contention
Reclaim, compression/decompression, and reloading content consume CPU. They can increase foreground Runnable delays when competing for execution time; confirm that on scheduling tracks instead of inferring it from a thread name.
The crop below shows kswapd0 repeatedly running on CPU 7. The original article described a Snapdragon 855 device, but this crop lacks enough topology and numerical frequency data to prove “the prime core at maximum frequency.” It also does not measure power or a specific foreground thread’s delay.
HeapTaskDaemon processes ART heap tasks. Its activity is neither automatically all GC nor all stop-the-world time. Correlate actual heap/GC tasks and allocation activity before attributing it to system pressure.
Process Death-Restart Cycles
Repeated exits and restarts add allocation, code-loading, and I/O work. First identify both the kill and restart reasons. The original Monkey-test log is preserved:
1 | 07-23 14:32:16.932 1435 1510 I am_proc_start: [0,30387,10145,com.tencent.mobileqq,restart,com.tencent.mobileqq] |
All nine am_kill events say empty #3. Android 9 AMSuses empty # plus a count when trimming excess empty processes; Android 16 OomAdjusterstill has the corresponding too many empty path. This supports repeated framework trimming followed by restarts, not a direct LMK-killed-QQ conclusion. The restart label alone does not identify a parent process reviving the app; investigate component/service restarts and other launch requests.
The corresponding system_server screenshot shows repeated start and killProcessGroup activity. That shape is not exclusive to any one kill reason:
The CPU crop below shows dense execution slices, but lacks complete per-thread accounting. It cannot attribute all CPU work to QQ or LMK. These are historical observations, not judgments about current app versions.
Memory Reclamation and I/O Triggers
After a phone has been in use for a long time, opening an app you used earlier can feel slower than opening it for the first time: you have to wait for it to load again. That is one of the situations that led me to look into low-memory jank. The symptom alone does not tell us the cause, though. We need to separate these mechanisms:
- The allocation fast path tries available free pages; it is not “fast-path reclaim.” On failure, the slow path may wake
kswapd, reclaim directly, or compact memory depending on flags and conditions. Direct reclaim runs in the allocating thread’s context and can affect foreground latency. See Linux 6.6page_alloc.c. - File-page reclaim does not always write storage. Eligible clean file-cache pages can be discarded and read again if needed; dirty pages generally involve writeback. Not every file-backed page must be written before eviction.
- Anonymous memory and swap do not imply physical storage I/O. ZRAM compresses data in RAM, consuming memory and CPU; configured backing-device writeback can also involve storage. Inspect
/proc/swapsand device configuration rather than assuming every phone uses RAM-only swap. See the Linux 6.6 ZRAM documentation. - A page fault need not read storage. Page/swap-cache hits and first mappings differ from faults requiring I/O. A slow return to an app may also be a cold start after process death, not merely swap-in.
Old names such as do_page_fault, lock_page_or_retry, and wait_on_page_bit_killable are investigation starting points, not a fixed chain on every architecture/version. Linux 6.6 file-cache paths use many folio interfaces. PG_locked and PG_writeback are separate states: folio_unlock() and folio_end_writeback()handle unlocking and writeback completion separately. The original statement that page locks clear only when writeback starts or read I/O finishes was incorrect; killable waits may also be interrupted by fatal signals.
Excessive readahead can create unused I/O and cache pressure; too little can hurt sequential access. Tune to access patterns, hits, and latency rather than assuming smaller is always better.
Case Study: App Startup Under Low Memory
I labeled these two captures low memory and normal memory at the time. Their arrows span bindApplication to around the first frame, not the full launch from the user’s tap or an independently verified presentation timestamp. Thermal, cache, and background-work conditions are incomplete, so they are not a controlled experiment varying memory alone.
Low Memory Startup
The arrow reads 2.044 s; the Thread Timeslices table spans 2053.451 ms, a slightly different interval. Running is 682.137 ms. The two Block I/O subclasses sum to 647.450 ms; all four Uninterruptible subclasses sum to 783.385 ms. The original “about 750ms” described only part of the classification.
The CPU Slices list includes HeapTaskDaemon, several kworker entries, and kswapd0. Grouping by name can combine same-named threads across processes; CPU time summed across cores is not foreground wait time or the interval’s wall duration.
Normal Memory Startup
The arrow reads 1.223 s; the thread-state selection spans 1227.232 ms. Running is 624.278 ms. All three Uninterruptible subclasses sum to 139.417 ms, of which the two Block I/O subclasses contribute 33.097 ms.
The thread-state tables compare as follows, in milliseconds. Do not mix their boundaries with the arrow selections:
| Metric | Low-memory sample | Normal sample |
|---|---|---|
| Selection extent | 2053.451 | 1227.232 |
| Running | 682.137 | 624.278 |
| Runnable | 63.060 | 43.902 |
| Sleeping | 524.869 | 419.635 |
| Uninterruptible, all subclasses | 783.385 | 139.417 |
| Of those, tagged Block I/O | 647.450 | 33.097 |
The last row is included in the preceding row, not additional time. Uninterruptible states show the largest increase, but subclasses without a Block I/O tag cannot all be counted as disk I/O. The captures also cannot attribute every difference to memory pressure.
The normal sample still lists HeapTaskDaemon and other workers. kswapd0 is visible in the low-memory ranking and absent from the displayed normal ranking; absence from a cropped ranking is not zero reclaim activity. The unequal interval lengths also prevent comparing total CPU milliseconds as if they were rates.
Optimization Strategies
These directions come from my own experience and ideas shared by fellow engineers. Each problem still needs to be examined on its own. Platform tuning belongs to system/OEM work; ordinary apps should manage their own allocations, caches, and background tasks first. An ongoing notification does not prove high memory consumption or justify unconditional process killing. Retaining fewer processes can increase cold starts, lost work, and failed background functions. Optimize responsiveness and reliability, not the free-RAM number alone.
- Watermarks:
extra_free_kbytesis a historical Android extension, not a universal kernel interface. The Android 16 adaptation script checks for it and otherwise calculateswatermark_scale_factor. Their high-watermark effects differ; values are not interchangeable. Higher reserves can reduce burst-driven direct reclaim while increasing background work and reducing cache capacity. - Storage: UFS 3.0 was a hardware-selection example in 2019, not a software fix or performance guarantee. Measure random I/O, queues, tail latency, and thermal state. A phone is not a desktop where replacing an SSD is a routine remedy.
- Readahead: Tune
read_ahead_kbusing access patterns and cache hits; no universal lower-is-better value applies. - Background I/O: Match the device’s cgroup version and enabled controllers. v1
blkiodiffers from v2 interfaces such asio.max; excessive throttling can delay work the foreground depends on. See Linux 6.6 cgroup v2. - Proactive reclaim: Experiment during verified idle periods while accounting for compression, writeback, CPU, and later refault costs. Periodically clearing caches is not capacity management.
- Exit/restart loops: Distinguish lmkd decisions, AMS count limits, crashes, and launch requests. Fix the actual loop; more kills do not imply better efficiency.
- kswapd: Tune around watermarks and allocation bursts, observing indicators such as
allocstall*. “Periodically reclaim more to the high watermark” is not a universal scheduler policy. - Swappiness: In Linux 6.6, its
0–200range expresses relative swap versus filesystem paging I/O cost, not a percentage of RAM at which swapping starts. Do not mechanically set ZRAM devices to zero; measure the workload. - Low-RAM products: Compare foreground tail latency, cold starts, exits, power use, and background-function success under comparable conditions. Do not copy a policy from another device based only on RAM size.
- Apps: Fix leaks, bound bitmap/object caches, reduce wasteful allocations and background tasks, and move suitable I/O off the main thread without blocking it for results. From Android 14 / API 34, ordinary apps cannot use
killBackgroundProcesses()to clean other packages; see the updated Launcher case study. - Unrecoverable incidents: A user-chosen restart can temporarily restore service; it does not fix the cause. Preserve relevant logs, pressure, and process data where possible and investigate the leak or abnormal load.
There are no universal best values. Validate changes with fixed device/build, workload, cache, and thermal conditions, repeated captures, and distributions rather than one improved screenshot.
References
Current mechanisms and versions are linked next to the relevant claims. The original historical references are retained below, not used as the sole authority for current behavior:
Article on Zhihu
For discussion, see the original Chinese low-memory case study on Zhihu.
About Me && Blog
Below are personal introductions and related links. Looking forward to exchanging ideas with fellow professionals - when three people walk together, one must be my teacher!
- Blogger’s Personal Introduction: Contains personal WeChat and WeChat group links.
- Blog Content Navigation: A navigation of personal blog content.
- Personally Organized and Collected Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome self-recommendations and recommendations (private WeChat chat is fine)
- Android Performance Optimization Knowledge Planet: The paid community stopped operating in 2026 and no longer accepts new members; this link preserves its history.
One person can walk faster, but a group of people can walk farther
