Besides the CPU, many users consider RAM size when buying a phone. Different RAM configurations come with different prices—but how much RAM do you actually need? How does Android manage its memory? Average users are often confused: How much RAM does this app use? How much does the system use? How does RAM affect my experience? And how much RAM should my next phone have?
A common question on Zhihu is: “Does the Android system not release memory?”. It’s not that the user doesn’t know the system releases memory, but rather they want to understand the mechanics to optimize their experience. In this article, I’ll address these user concerns. More technical details will be covered in later articles.
Version note — reviewed October 13, 2026: Written in 2018, this article uses screenshots from the original devices and apps; the full ROM version was not recorded. The explanations below correct memory accounting, exit actions, and startup states, and add Android 12–15 changes. The old advice to clear all tasks regularly and buy “at least 6 GB, ideally 8 GB” is outdated.
1. Does the System Not Release Memory After Closing an App?
First distinguish leaving a screen, removing a task, ending a process, and force-stopping an app. A process can remain cached after its UI disappears; that does not mean Android cannot reclaim its memory.
Pressing the Back Button
Let’s start with the empty app used in the test. Its package was com.example.gaojianwu.myapplication and its PID was 5708. The first screenshot places it in the Foreground group with a value of 13910 kB:
After pressing Back, another adb shell dumpsys meminfo snapshot shows:
The same PID remains, now under Cached, at 12337 kB. This shows process retention, not continuous CPU execution. These groups represent process importance, not CPU scheduling priority; the values are PSS in this output format, not Java heap sizes.
Back normally handles screen or task navigation rather than killing the whole process. Android 12 (API 31) changed the default for root launcher activities declaring ACTION_MAIN and CATEGORY_LAUNCHER: Back moves their task to the background instead of finishing the activity. Other activities and custom app handling must be considered separately. See tasks and the back stack.
Using the Task Manager
Removing a recent-task card is different from Force Stop in Settings. OEM task managers may additionally clean up processes, while services or other components may keep an app process needed. One ROM’s behavior is not a universal Android rule.
On the Meizu MX4 Pro used then, opening the same test app and clearing it through the task manager produced this output:
I concluded at the time that the test process had ended. The crop itself only shows that PID 5708 is absent from this excerpt; it cannot establish that every app process exited or that none can start again later.
Using ADB or Developer Tools
For development, adb shell am force-stop PACKAGE_NAME stops the specified app and sets the package’s stopped state. Replace PACKAGE_NAME with the real package name. This is stronger than ending a single PID.
Android 15 (API 35) requires direct or indirect user action to leave the stopped state and cancels the app’s pending intents on force-stop. Restart behavior after an ordinary process kill must not be treated as unrestricted auto-start after force-stop.
The old crop only shows part of a Logcat/ADB toolbar, without a button tooltip or result. It cannot establish that a particular button performs force-stop. Stopping an IDE run, terminating a process, and clearing logs are distinct actions.
2. Does Memory Not Increase Much Even After Closing Background Tasks?
When a process exits, its address space and private resources are reclaimed. A system “available memory” display need not increase immediately by the same amount. Shared pages may still have users, file pages may remain cached, and graphics buffers may still be held by system components or other consumers. Some resources remain until their last reference is released, while other processes can allocate memory concurrently.
Now take the Zhihu app from that time. These snapshots show memory before opening it, afterward, and after cleanup, using the kB units in the screenshots:
| Original snapshot | Free RAM | The separate free component |
|---|---|---|
| Before opening | 1837160 kB | 202620 kB |
| After opening | 1805784 kB | 37864 kB |
| After cleanup | 1862296 kB | 83500 kB |
Here, Free RAM includes cached pss + cached + free, not just unused pages. As a reference for this format, AOSP android-5.1.1_r1 sums cached-process PSS, kernel cache, and free memory. This does not identify the original device’s exact ROM version.
The total rises by 56512 kB after cleanup, not by the process’s 49907 kB. These snapshots show a change in aggregate accounting, not a one-for-one measurement of released app memory. Cached processes still occupy RAM; the system retains them as reclaimable candidates.
3. Does a Process Keep Running Even After Being “Closed” In the Foreground?
Process existence and continuous CPU execution are different. After Home or Back, a process may remain or later be reclaimed. Its importance depends on active components and dependencies, not just which navigation button was pressed.
- Back: navigates through screens or tasks, without guaranteeing process termination. Root launcher behavior changed in Android 12 as described above.
- Home: normally backgrounds the task for later return. Retention is not a permanent guarantee.
- Recent-task cleanup: task removal and process termination need separate confirmation; vendors may add policies.
- Force Stop: stops the app and sets the stopped state, unlike ordinary process reclamation.
The process lifecycle documentation says cached processes should stop work; from Android 13 (API 33), they may receive limited or no execution time. Music, navigation, and other necessary background work need components and APIs that comply with the relevant OS restrictions. Process existence alone does not guarantee continued work.
For normal use, switch with Home or gestures and use Back to navigate. Android Help says apps usually do not need to be closed. Repeatedly clearing all tasks merely to empty RAM can force extra initialization next time. If a particular app drains power, becomes unresponsive, or behaves unexpectedly in the background, investigate its settings or force-stop that app, keeping in mind that playback, uploads, or reminders may be interrupted.
What annoyed me in 2018 was apps waking one another: kill one, and another would quietly start it again, using resources all the same. That came from my experience then. Vendor policies differ, and the following historical illustration is not evidence of any app’s current behavior:
4. Do I Not Need to Close Apps Manually to Save Startup Time?
Retaining a process and an existing screen can avoid initialization work. That is the purpose of caching, but an existing process does not automatically mean a hot start, and process creation is not the only startup cost.
Android can reclaim processes based on importance and memory pressure. Apps should release unnecessary resources without relying on a guaranteed low-memory warning before termination; trimming caches does not guarantee survival. From Android 14 (API 34), onLowMemory() is never called, and several running/severe-background onTrimMemory() levels are no longer delivered; the obsolete method/constants were deprecated in API 35. TRIM_MEMORY_UI_HIDDEN and TRIM_MEMORY_BACKGROUND retain their lifecycle meanings. See ComponentCallbacks2 and the updated trim-memory article.
The following complaint is from 2018. I mentioned apps using 100–400 MB without recording full measurement conditions, so those figures are not a current benchmark.
But—and there always seems to be a but—real apps did not all behave as neatly as the design hoped. I singled out Moji Weather for using around 400 MB. Sorry, Moji, there I go again.
You are reading a book when a WeChat message arrives. Switch over to reply, take a photo, send it to a friend, perhaps post on Weibo, then go back to your book: the reader has been killed and is loading again. For crying out loud.
That experience can involve memory pressure, app behavior, or OEM policy. Stopping unnecessary heavy work may help, but clearing every cached process also removes the reader. Apps need state restoration, and no policy can guarantee that an “important” app is never killed.
The startup-state guide distinguishes common cases:
- Cold start: create a process, then initialize the app, activity, and UI.
- Warm start: for example, reuse the process but recreate the target activity.
- Hot start: for example, return an existing process and activity to the foreground, possibly with resume, layout, and draw work.
Using the car analogy: a cold start includes starting the engine, while a hot start begins with the vehicle ready. It cannot predict timings or assign the entire difference to process creation through Zygote.
Quick Q&A
- How does Android manage memory? GC handles unreachable Java/Kotlin heap objects, native allocations have their own release mechanisms, and the kernel can reclaim file pages or use configured zRAM. Under sustained pressure, lower-importance processes can be killed. Android 10 added PSI-based pressure monitoring to
lmkd, and Android 11 improved its treatment of thrashing, subject to kernel/device configuration. See AOSP lmkd. GC, page reclaim, and process termination are different operations. - How much does one app use? Identify all its processes and choose a metric. RSS counts resident pages and repeats shared pages across processes; PSS apportions shared pages among their users; USS counts private resident pages. Java heap size, native allocations, PSS, and graphics memory are not interchangeable or necessarily additive. See
dumpsys meminfo. - How much does the system use? Do not subtract a few app figures from total RAM. System processes, kernel memory, file cache, graphics buffers, and shared/reserved regions have different accounting, sometimes with overlap. Compare a consistent system snapshot and check its field definitions; the old
Free RAMlabel includes cached memory. - How does memory affect experience? Insufficient capacity, oversized working sets, or frequent reclaim can cause reloads and waiting. Low free memory alone is not a fault, and cache occupancy is not a leak. Investigate whether unneeded objects or allocations remain retained.
- How should ordinary users manage it? Switch apps normally instead of routinely clearing all tasks. Investigate specific misbehaving apps, while preserving background functions you need, such as music, navigation, or uploads.
- How much RAM should a new phone have? The old 6/8 GB advice is outdated. Needs depend on multitasking, games, local models, and the device’s retention policy. Virtual memory expansion is not equivalent to the same capacity of physical RAM. This article is not a new device buying guide.
For development, these read-only entry points separate app and system views. Replace PACKAGE_NAME and inspect relevant PIDs for multiprocess apps; output varies with Android version:
1 | adb shell dumpsys meminfo PACKAGE_NAME |
For Java/Kotlin leaks, inspect an Android Studio heap dump from a debuggable app or use LeakCanary’s reference-path analysis. Perfetto heapprofd can profile native allocations on Android 10 and later; on production user builds, the target app must be profileable or debuggable. Sampled allocations are neither total resident memory nor a Java reference graph. System-pressure analysis needs process exits, reclaim, and a timeline, rather than one screenshot.
Related Memory Articles
- Java memory optimization
- Android resource memory management
- Android memory guidance
- onTrimMemory
- Understanding Overdraw
- Overdraw, part 1
- Overdraw, part 2
- MAT introduction
- Advanced MAT
- Bitmap inspection in MAT
- Thoughts on Android fluency
About Me && Blog
Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”
- Blogger Intro
- Blog Content Navigation: A guide for my blog content.
- Curated Excellent Blog Articles - Android Performance Optimization Must-Knows
- Android Performance Optimization Knowledge Planet: The paid community stopped operating in 2026 and no longer accepts new members; this link preserves its history.
One walks faster alone, but a group walks further together.
