[null,null,["最后更新时间 (UTC)：2025-07-27。"],[],[],null,["# Memory allocation among processes\n\nThe Android platform runs on the premise that free memory is wasted memory. It\ntries to use all of the available memory at all times. For example, the system\nkeeps apps in memory after they've been closed so the user can quickly switch\nback to them. For this reason, Android devices often run with very little free\nmemory. Memory management is vital to properly allocate memory among important\nsystem processes and many user applications.\n\nThis page discusses the basics of how Android allocates memory for the system\nand for user applications. It also explains how the operating system reacts to\nlow memory situations.\n\nTypes of memory\n---------------\n\nAndroid devices contain three different types of memory: RAM, zRAM, and storage.\nNote that both the CPU and GPU access the same RAM.\n\n**Figure 1.** Types of memory - RAM, zRAM, and storage\n\n- RAM is the fastest type of memory, but is usually limited in size. High-end\n devices typically have the largest amounts of RAM.\n\n- zRAM is a partition of RAM used for swap space. Everything is compressed\n when placed into zRAM, and then decompressed when copied out of zRAM. This\n portion of RAM grows or shrinks in size as pages are moved into or taken out\n of zRAM. Device manufacturers can set the maximum size.\n\n- Storage contains all of the persistent data such as the file system and the\n included object code for all apps, libraries, and the platform. Storage has\n much more capacity than the other two types of memory. On Android, storage\n isn't used for swap space like it is on other Linux implementations since\n frequent writing can cause wear on this memory, and shorten the life of the\n storage medium.\n\nMemory pages\n------------\n\nRAM is broken up into *pages*. Typically each page is 4KB of memory.\n\nPages are considered either *free* or *used*. Free pages are unused RAM. Used\npages are RAM that the system is actively using, and are grouped into the\nfollowing categories:\n\n- Cached: Memory backed by a file on storage (for example, code or memory-mapped files). There are two types of cached memory:\n - Private: Owned by one process and not shared\n - Clean: Unmodified copy of a file on storage, can be deleted by [`kswapd`](#kswapd) to increase free memory\n - Dirty: Modified copy of the file on storage; can be moved to, or compressed in, zRAM by `kswapd` to increase free memory\n - Shared: Used by multiple processes\n - Clean: Unmodified copy of the file on storage, can be deleted by `kswapd` to increase free memory\n - Dirty: Modified copy of the file on storage; allows changes to be written back to the file in storage to increase free memory by `kswapd`, or explicitly using [`msync()`](/reference/android/system/Os#msync(long,%2520long,%2520int)) or [`munmap()`](/reference/android/system/Os#munmap(long,%2520long))\n- Anonymous: Memory **not** backed by a file on storage (for example, allocated by [`mmap()`](/reference/android/system/Os#mmap(long,%2520long,%2520int,%2520int,%2520java.io.FileDescriptor,%2520long)) with the `MAP_ANONYMOUS` flag set)\n - Dirty: Can be moved/compressed in zRAM by `kswapd` to increase free memory\n\n| **Note:** Clean pages contain an exact copy of a file (or portion of a file) that exists in storage. A clean page becomes a dirty page when it no longer contains an exact copy of the file (for example, from the result of an application operation). Clean pages can be deleted because they can always be regenerated using the data from storage; dirty pages cannot be deleted or else data would be lost.\n\nThe proportions of free and used pages vary over time as the system actively\nmanages RAM. The concepts introduced in this section are key to managing\nlow-memory situations. The next section of this document explains them in\ngreater detail.\n\nLow memory management\n---------------------\n\nAndroid has two main mechanisms to deal with low memory situations: the kernel\nswap daemon and low-memory killer.\n\n### kernel swap daemon\n\nThe kernel swap daemon (`kswapd`) is part of the Linux kernel, and converts used\nmemory into free memory. The daemon becomes active when free memory on the\ndevice runs low. The Linux kernel maintains low and high free memory thresholds.\nWhen free memory falls below the low threshold, `kswapd` starts to reclaim\nmemory. Once the free memory reaches the high threshold, `kswapd` stops\nreclaiming memory.\n\n`kswapd` can reclaim clean pages by deleting them because they're backed by\nstorage and have not been modified. If a process tries to address a clean page\nthat has been deleted, the system copies the page from storage to RAM. This\noperation is known as *demand paging*.\n\n**Figure 2.** Clean page, backed by storage, deleted\n\n`kswapd` can move cached private dirty pages and anonymous dirty pages to zRAM,\nwhere they are compressed. Doing so frees up available memory in RAM (free\npages). If a process tries to touch a dirty page in zRAM, the page is\nuncompressed and moved back into RAM. If the process associated with a\ncompressed page is killed, then the page is deleted from zRAM.\n\nIf the amount of free memory falls below a certain threshold, the system starts\nkilling processes.\n\n**Figure 3.** Dirty page moved to zRAM and compressed\n\n### Low-memory killer\n\nMany times, `kswapd` cannot free enough memory for the system. In this case, the\nsystem uses\n[`onTrimMemory()`](/reference/android/content/ComponentCallbacks2#onTrimMemory(int))\nto notify an app that memory is running low and that it should reduce its\nallocations. If this is not sufficient, the kernel starts killing processes to\nfree up memory. It uses the low-memory killer (LMK) to do this.\n\nTo decide which process to kill, LMK uses an \"out of memory\" score called\n[`oom_adj_score`](https://android.googlesource.com/platform/system/memory/lmkd/+/master/README.md)\nto prioritize the running processes. Processes with a high score are killed\nfirst. Background apps are first to be killed, and system processes are last to\nbe killed. The following table lists the LMK scoring categories from\nhigh-to-low. Items in the highest-scoring category, in row one, will be killed\nfirst:\n\n**Figure 4.** Android processes, with high scores at the top and low scores at\nthe bottom\n\nThese are descriptions for the various categories in the table above:\n\n- Background apps: Apps that were run previously and are not currently active.\n LMK will first kill background apps starting with the one with the highest\n `oom_adj_score`.\n\n- Previous app: The most recently-used background app. The previous app has\n higher priority (a lower score) than the background apps because it is more\n likely the user will switch to it than one of the background apps.\n\n- Home app: This is the launcher app. Killing this will make the wallpaper\n disappear.\n\n- Services: Services are started by applications and may include syncing or\n uploading to the cloud.\n\n- Perceptible apps: Non-foreground apps that are perceptible to the user in\n some way, such as running a search process that displays a small UI or\n listening to music.\n\n- Foreground app: The app currently being used. Killing the foreground app\n looks like an application crash which might indicate to the user that\n something is going wrong with the device.\n\n- Persistent (services): These are core services for the device, such as\n telephony and wifi.\n\n- System: System processes. As these processes are killed, the phone may\n appear to reboot.\n\n- Native: Very low-level processes used by the system (for example, `kswapd`).\n\nDevice manufacturers can change the behavior of LMK.\n\nCalculating memory footprint\n----------------------------\n\nThe kernel tracks all memory pages in the system.\n\n**Figure 5.** Pages used by different processes\n\nWhen determining how much memory is being used by an app, the system must\naccount for shared pages. Apps that access the same service or library will be\nsharing memory pages. For example, Google Play Services and a game app may be\nsharing a location service. This makes it difficult to determine how much memory\nbelongs to the service at large versus each application.\n\n**Figure 6.** Pages shared by two apps (middle)\n\nTo determine the memory footprint for an application, any of the following\nmetrics may be used:\n\n- Resident Set Size (RSS): The number of shared and non-shared pages used by the app\n- 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)\n- Unique Set Size (USS): The number of non-shared pages used by the app (shared pages are not included)\n\nPSS is useful for the operating system when it wants to know how much memory is\nused by all processes since pages don't get counted multiple times. PSS takes a\nlong time to calculate because the system needs to determine which pages are\nshared and by how many processes. RSS doesn't distinguish between shared and\nnon-shared pages (making it faster to calculate) and is better for tracking\nchanges in memory allocation.\n\nAdditional resources\n--------------------\n\n- [Overview of memory management](/topic/performance/memory-overview)\n- [Processes and Application Lifecycle](/guide/components/activities/process-lifecycle)\n- [Understanding Android memory usage - Google I/O presentation](https://www.youtube.com/watch?v=w7K0jio8afM)\n- [Android Memory and Games - Google I/O presentation](https://www.youtube.com/watch?v=Do7oYWwOXTk&t=314s)\n- [Android low memory killer daemon](https://source.android.com/docs/core/perf/lmkd)\n\nRecommended for you\n-------------------\n\n- Note: link text is displayed when JavaScript is off\n- [App startup time](/topic/performance/vitals/launch-time)"]]
