The Android platform runs on the premise that free memory is wasted memory. It tries to use all of the available memory at all times. For example, the system keeps apps in memory after they've been closed so the user can quickly switch back to them. For this reason, Android devices often run with very little free memory. Memory management is vital to properly allocate memory among important system processes and many user applications.
This page discusses the basics of how Android allocates memory for the system and for user applications. It also explains how the operating system reacts to low memory situations.
Types of memory
Android devices contain three different types of memory: RAM, zRAM, and storage. Note that both the CPU and GPU access the same RAM.
Figure 1. Types of memory - RAM, zRAM, and storage
RAM is the fastest type of memory, but is usually limited in size. High-end devices typically have the largest amounts of RAM.
zRAM is a partition of RAM used for swap space. Everything is compressed when placed into zRAM, and then decompressed when copied out of zRAM. This portion of RAM grows or shrinks in size as pages are moved into or taken out of zRAM. Device manufacturers can set the maximum size.
Storage contains all of the persistent data such as the file system and the included object code for all apps, libraries, and the platform. Storage has much more capacity than the other two types of memory. On Android, storage isn’t used for swap space like it is on other Linux implementations since frequent writing can cause wear on this memory, and shorten the life of the storage medium.
Memory pages
RAM is broken up into pages. Typically each page is 4KB of memory.
Pages are considered either free or used. Free pages are unused RAM. Used pages are RAM that the system is actively using, and are grouped into the following categories:
- Cached: Memory backed by a file on storage (for example, code or
memory-mapped files). There are two types of cached memory:
- Private: Owned by one process and not shared
- Clean: Unmodified copy of a file on storage, can be deleted by
kswapd
to increase free memory - Dirty: Modified copy of the file on storage; can be moved to, or
compressed in, zRAM by
kswapd
to increase free memory
- Clean: Unmodified copy of a file on storage, can be deleted by
- Shared: Used by multiple processes
- Private: Owned by one process and not shared
- Anonymous: Memory not backed by a file on storage (for example,
allocated by
mmap()
with theMAP_ANONYMOUS
flag set)- Dirty: Can be moved/compressed in zRAM by
kswapd
to increase free memory
- Dirty: Can be moved/compressed in zRAM by
The proportions of free and used pages vary over time as the system actively manages RAM. The concepts introduced in this section are key to managing low-memory situations. The next section of this document explains them in greater detail.
Low memory management
Android has two main mechanisms to deal with low memory situations: the kernel swap daemon and low-memory killer.
kernel swap daemon
The kernel swap daemon (kswapd
) is part of the Linux kernel, and converts used
memory into free memory. The daemon becomes active when free memory on the
device runs low. The Linux kernel maintains low and high free memory thresholds.
When free memory falls below the low threshold, kswapd
starts to reclaim
memory. Once the free memory reaches the high threshold, kswapd
stops
reclaiming memory.
kswapd
can reclaim clean pages by deleting them because they're backed by
storage and have not been modified. If a process tries to address a clean page
that has been deleted, the system copies the page from storage to RAM. This
operation is known as demand paging.
Figure 2. Clean page, backed by storage, deleted
kswapd
can move cached private dirty pages and anonymous dirty pages to zRAM,
where they are compressed. Doing so frees up available memory in RAM (free
pages). If a process tries to touch a dirty page in zRAM, the page is
uncompressed and moved back into RAM. If the process associated with a
compressed page is killed, then the page is deleted from zRAM.
If the amount of free memory falls below a certain threshold, the system starts killing processes.
Figure 3. Dirty page moved to zRAM and compressed
Low-memory killer
Many times, kswapd
cannot free enough memory for the system. In this case, the
system uses
onTrimMemory()
to notify an app that memory is running low and that it should reduce its
allocations. If this is not sufficient, the kernel starts killing processes to
free up memory. It uses the low-memory killer (LMK) to do this.
To decide which process to kill, LMK uses an "out of memory" score called
oom_adj_score
to prioritize the running processes. Processes with a high score are killed
first. Background apps are first to be killed, and system processes are last to
be killed. The following table lists the LMK scoring categories from
high-to-low. Items in the highest-scoring category, in row one, will be killed
first:
Figure 4. Android processes, with high scores at the top and low scores at the bottom
These are descriptions for the various categories in the table above:
Background apps: Apps that were run previously and are not currently active. LMK will first kill background apps starting with the one with the highest
oom_adj_score
.Previous app: The most recently-used background app. The previous app has higher priority (a lower score) than the background apps because it is more likely the user will switch to it than one of the background apps.
Home app: This is the launcher app. Killing this will make the wallpaper disappear.
Services: Services are started by applications and may include syncing or uploading to the cloud.
Perceptible apps: Non-foreground apps that are perceptible to the user in some way, such as running a search process that displays a small UI or listening to music.
Foreground app: The app currently being used. Killing the foreground app looks like an application crash which might indicate to the user that something is going wrong with the device.
Persistent (services): These are core services for the device, such as telephony and wifi.
System: System processes. As these processes are killed, the phone may appear to reboot.
Native: Very low-level processes used by the system (for example,
kswapd
).
Device manufacturers can change the behavior of LMK.
Calculating memory footprint
The kernel tracks all memory pages in the system.
Figure 5. Pages used by different processes
When determining how much memory is being used by an app, the system must account for shared pages. Apps that access the same service or library will be sharing memory pages. For example, Google Play Services and a game app may be sharing a location service. This makes it difficult to determine how much memory belongs to the service at large versus each application.
Figure 6. Pages shared by two apps (middle)
To determine the memory footprint for an application, any of the following metrics may be used:
- Resident Set Size (RSS): The number of shared and non-shared pages used by the app
- Proportional Set Size (PSS): The number of non-shared pages used by the app and an even distribution of the shared pages (for example, if three processes are sharing 3MB, each process gets 1MB in PSS)
- Unique Set Size (USS): The number of non-shared pages used by the app (shared pages are not included)
PSS is useful for the operating system when it wants to know how much memory is used by all processes since pages don’t get counted multiple times. PSS takes a long time to calculate because the system needs to determine which pages are shared and by how many processes. RSS doesn't distinguish between shared and non-shared pages (making it faster to calculate) and is better for tracking changes in memory allocation.
Additional resources
- Overview of memory management
- Processes and Application Lifecycle
- Understanding Android memory usage - Google I/O presentation
- Android Memory and Games - Google I/O presentation
- Android Low Memory Killer Daemon
Recommended for you
- Note: link text is displayed when JavaScript is off
- App startup time