32

On Android, when I look into "Setting" -> "App", under the tab "running", I can see the memory is cut into to parts: "used memory" and "memory free", also the applications are either put into "used memory", or "memory free". The applications in "memory free" part are noted as "cached background process".

So, what are "cached background processes"? They are still in memory, rather than switched to "disk" (as desktops/laptops do), right? When the user tab one of these "cached background processes", it would be displayed immediately as it is still in memory, just like a running process, right?

What does Android do when it "cache" an application?

JackWM
  • 10,085
  • 22
  • 65
  • 92

3 Answers3

52

So, what are "cached background processes"?

Since you are asking for a technical interpretation of something listed in a device UI, the definition may vary by device, if device manufacturers elected to tinker with the Settings app.

That being said, "cached background processes" usually refers to processes that do not have a foreground activity and do not have a running service. These processes are kept in memory simply because we have enough memory to do so, and therefore, as you note, the user can switch back to these processes quickly. As Android starts to need more system RAM for yet other processes, the "cached background processes" tend to be the processes that get terminated to free up system RAM.

The pre-eminent example of a "cached background process" would be one where the user launched the app, poked around it briefly, then pressed HOME to return to the home screen. If the process does not have a running service, I would expect to find it listed as a "cached background process".

They are still in memory, rather than switched to "disk" (as desktops/laptops do), right?

Correct. Android devices do not use swap space.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Good explanation! I also noticed some data used by application may be lost when caching an application. E.g. I saw an Youbute video, then pressed "Home" button, then switched to the video back, and found it started loading from the beginning. Is this understanding right? – JackWM Jan 10 '13 at 14:13
  • 1
    @JackWM: That depends upon the app and how it was written. – CommonsWare Jan 10 '13 at 14:15
  • Okay, you mean this is specified by the App writers, right? through "onPause()" function? Is there any requirement on the data size that an App can maintain while being cached? – JackWM Jan 10 '13 at 14:17
  • @JackWM: "Is there any requirement on the data size that an App can maintain while being cached?" -- nothing different than when it is in the foreground. Apps *can* elect to trim their memory consumption when not in the foreground, and that *may* help keep their process around a bit longer, but there is nothing required. Beyond that, the heap size limit is the same for the process regardless of whether it is in the foreground or background. – CommonsWare Jan 10 '13 at 14:21
  • What do you mean "Android devices do not use swap space"? I think the fact that an app can be killed when memory is low, but can be reconstructed with previous state means Android use swap somehow. Isn't it a swap? Android system do provide chances to conserve current state, and restores it when user comes back. – 김준호 Apr 30 '14 at 13:45
  • Confer Robert Love's article also. http://blog.rlove.org/2010/04/why-ipad-and-iphone-dont-support.html – 김준호 Apr 30 '14 at 13:46
  • @김준호: "What do you mean "Android devices do not use swap space"?" -- Android devices do not normally ship with a Linux swap partition or swapfile. "Isn't it a swap?" -- swap is conventionally defined as paging RAM to disk. You are welcome to define swap however you like. – CommonsWare Apr 30 '14 at 13:48
  • @CommonsWare OK, maybe I misunderstood it. Then I'm just wondering, where does Android save data when background process get killed? In Robert's article, it said "multitasking is feasible even on a device with limited memory and ***no swap***". Could you shed some light on this? – 김준호 Apr 30 '14 at 14:13
  • @김준호: "Then I'm just wondering, where does Android save data when background process get killed?" -- the saved instance state `Bundle` and so forth are held in a core OS process. That is part of the reason why a `Bundle` can only hold onto data that can be converted into byte arrays for passing across process boundaries. – CommonsWare Apr 30 '14 at 14:22
  • @CommonsWare : My android application doesn't contains any service so when i press the home key and go to "Apps" ==> "cache background process" there my app is listed but it is showing around 400 to 500 MB . It is too high and this is varies with the device. I have total 5-6 screens in my application. How can i reduce the showing memory amount ? Please help. – Manish Agrawal Apr 07 '15 at 10:14
20

Why not look into the "Setting" app's source code.

In my Nexus 4, "Setting" -> "App" -> "Running" looks like below.

enter image description here enter image description here


Before getting started, there are five levels in the importance hierarchy in Android Process. These are

1) Foreground process,
2) Visible process,
3) Service process,
4) Background process,
5) Empty process

You can find more details at "Processes and Threads" document in Android Developer site.

I did look into code, and it turned out "SHOW CACHED PROCESSES" shows those processes whose importance hierarchy is equal to or lower than "Background process". On the other hand, "SHOW RUNNING SERVICES" shows those whose importance hierarchy is equal to "Visible process" or higher. I dropped some detail to clearly show main point. You can see the full source code of this part here.

try {
        final int numProc = mAllProcessItems.size();
        int[] pids = new int[numProc];
        for (int i=0; i<numProc; i++) {
            pids[i] = mAllProcessItems.get(i).mPid;
        }

        ...

        for (int i=0; i<pids.length; i++) {
            ProcessItem proc = mAllProcessItems.get(i);
            changed |= proc.updateSize(context, pss[i], mSequence);
            if (proc.mCurSeq == mSequence) {
                serviceProcessMemory += proc.mSize;
            } else if (proc.mRunningProcessInfo.importance >=
                    ActivityManager.RunningAppProcessInfo.IMPORTANCE_BACKGROUND) {
                backgroundProcessMemory += proc.mSize;
                MergedItem mergedItem;
                if (newBackgroundItems != null) {
                    mergedItem = proc.mMergedItem = new MergedItem(proc.mUserId);
                    proc.mMergedItem.mProcess = proc;
                    diffUsers |= mergedItem.mUserId != mMyUserId;
                    newBackgroundItems.add(mergedItem);
                } else {
                   ...
                }

               ...

            } else if (proc.mRunningProcessInfo.importance <=
                    ActivityManager.RunningAppProcessInfo.IMPORTANCE_VISIBLE) {
                foregroundProcessMemory += proc.mSize;
            }
        }
    } catch (RemoteException e) {
    }


So, back to your question,

They are still in memory, rather than switched to "disk" (as desktops/laptops do), right?

Yes, they are still in memory, but eventually Android system may need to remove old processes to reclaim memory for new or more important processes. To determine which processes to keep and which to kill, the system places each process into an "importance hierarchy".

When the user tab one of these "cached background processes", it would be displayed immediately as it is still in memory, just like a running process, right?

Right. For example, the only reason to keep "Empty process" alive is to improve startup time the next time a component needs to run in it.

What does Android do when it "cache" an application?

AFAIK, it simply do not kill the process and keep the resources to immediately respond to User when he/she comes back.

김준호
  • 15,997
  • 9
  • 44
  • 38
  • i have cleaner app thats releasing cache of running process how the y are doing can u pls tell me how can i find cache size for process and release cache size ?@Javatar @congliu – Erum Nov 24 '14 at 10:30
1

Process ranks

The Android operating system tries to maintain the application running for as long as possible, but when the available memory is low, it will try to free resources in the system by killing the processes with lower importance frst.

This is when process ranking comes into the picture; the Android processes are ranked in the next fve categories from the higher priority to the lower priorities:

  • Foreground process: This is a process that hosts an activity or service that the user is currently interacting with: a service started in the foreground or service running its life cycle callbacks
  • Visible process: This is a process that hosts a paused activity or service bounded to a visible activity
  • Service process: This is a process that hosts a service not bound to a visible activity
  • Background process: This is a process that hosts a non-visible activity; all background processes are sorted over a Least-Recently-Used (LRU) list, therefore, the most recently used processes are the last killed processes when they
  • Empty process: This is a process used to cache inactive Android components and to improve any component startup time

When the system reaches a point that it needs to release resources, the processes available to be killed will be sorted, taking into account the process rank, last used processes, and components running.

Source :

Asynchronous Android Programming - Second Edition - Helder Vasconcelos - July 2016