FORUMS

What Do You Think About Fingerprint Scanners?

More and more phones are featuring fingerprint scanners, and with many promising … more

What’s Next for Samsung and Its Flagships?

If we were to say that the Galaxy S6 was a leap of faith made by Samsung, we … more

The Ultimate Showcase of dBrand Skins

In the search for ways to protect, accessorize, and personalize; a user has many options. One … more

Huawei’s Rapid Rise to Third Place in the Smartphone Race

Huawei has quickly grown to become one of the world’s biggest … more

Cached processes CPU usage

22 posts
Thanks Meter: 3
 
By julioromano, Junior Member on 26th August 2012, 09:46 AM
Post Reply Subscribe to Thread Email Thread
Hello everyone,
This is a question I've tried to search for an answer since quite some time but never found any so far.

It is happening on a stock HSPA+ Galaxy Nexus with JRO03C 4.1.1 Jelly Bean (bought from US play store).
Please note this behaviour was happening with Ice Cream Sandwich as well.

This happens with more than one app, but this time I'll focus on play.google.com/store/apps/details?id=com.merriamwebster
because it's free and I was able to reproduce this behaviour quickly.



Steps to reproduce:

-Open up Merriam Webster's app
-Write any word in the search box, than tap it in the drop down list that appears (you're brought to the word's dictionary page)
-Wait a few seconds then hit Android's home button on the bottom bar

Now check in Settings -> Apps -> Running:
You will see that the app is not on the running list but is in the cached processes list.

Now go to Developer Tools and enable "Show CPU usage" and hit home to show up the desktop.
You will see that com.merriam.webster is constantly using a small but not negligible percentage of cpu (its green bar is big enough to "highlight" the 'er' in .webster )

The only way to stop this is to stop the cached process in Settings -> Apps -> Running -> Show cached processes



I think the question now comes up by itself: "Aren't cached processes supposed not to use any CPU at all?"

Any info on the matter is appreciated.
Thanks
Last edited by julioromano; 26th August 2012 at 10:00 AM.
 
 
26th August 2012, 11:37 AM |#2  
VoiD_Dweller's Avatar
Senior Member
Flag Orlando, FL
Thanks Meter: 887
 
Donate to Me
More
I think they do but its really minimal and probably doesn't affect performance much at all..
26th August 2012, 11:55 AM |#3  
OP Junior Member
Flag Brescia
Thanks Meter: 3
 
More
Quote:
Originally Posted by VoiD_Dweller

I think they do but its really minimal and probably doesn't affect performance much at all..

Such a constant CPU usage, even if small, will prevent CPU from going to its sleep state. No sleep state = battery drain.
27th August 2012, 10:40 AM |#4  
OP Junior Member
Flag Brescia
Thanks Meter: 3
 
More
More on the matter...
I've been able to investigate the issue a little further:

Installing the ad-free version of the same app ( play.google.com/store/apps/details?id=com.merriamwebster.premium ) and trying to reproduce the same steps does NOT show the problem. The app is now sitting in the background without chewing CPU time.

The only difference among the 2 apps should be the fact that the paid one lacks the piece of code to retrieve and show the ads (is that made with google ads?).

This would at least point us to a culprit (the ad code).

Still I don't understand why a process which is show as cached by the system is able to use CPU cycles. This should not be possible according to Android OS Documentation.
27th August 2012, 11:28 AM |#5  
kuisma's Avatar
Senior Member
Flag Sweden
Thanks Meter: 193
 
More
Quote:
Originally Posted by julioromano

Still I don't understand why a process which is show as cached by the system is able to use CPU cycles. This should not be possible according to Android OS Documentation.

The app isn't cached, but running, the time it consumes CPU cycles. It's just that it's only running a fraction of a second at a time, so you don't see it. In between, the app stops itself, rendering a "cached process" until the next time it wakes up, due to an intent restarting the app for a short while again.
28th August 2012, 11:02 AM |#6  
OP Junior Member
Flag Brescia
Thanks Meter: 3
 
More
Quote:
Originally Posted by kuisma

The app isn't cached, but running, the time it consumes CPU cycles. It's just that it's only running a fraction of a second at a time, so you don't see it. In between, the app stops itself, rendering a "cached process" until the next time it wakes up, due to an intent restarting the app for a short while again.

This might be a possible explanation, however installing the ad-free version of the app eliminates this odd behaviour.
Does this mean that some ad library code is buggy and can actually cause CPU hogging?
It makes no sense to wake up a process via intent every fraction of a second when it's UI (and hence the ads) is not displayed at all.
28th August 2012, 11:15 AM |#7  
kuisma's Avatar
Senior Member
Flag Sweden
Thanks Meter: 193
 
More
Quote:
Originally Posted by julioromano

This might be a possible explanation, however installing the ad-free version of the app eliminates this odd behaviour.
Does this mean that some ad library code is buggy and can actually cause CPU hogging?
It makes no sense to wake up a process via intent every fraction of a second when it's UI (and hence the ads) is not displayed at all.

Not every fraction of a second, just once in a while, enough for the process to stay alive. Also, at a closer look, I see no reason why a cached process shouldn't be able to consume CPU cycles. Just because the Android app terminated, I see nothing that hinders the JVM (DVM) to keep threads going. Not for very long, though, since the ActivityManager loves to slay cached processes. Where in the Android OS Documentation did you find the claims this isn't possible?

Why the ad code behaves this way, you'll have to ask them about. There can me many different reasons. Checking availability of new ads, internal administration, collecting usage statistics ... just to mention a few.
28th August 2012, 11:26 AM |#8  
OP Junior Member
Flag Brescia
Thanks Meter: 3
 
More
[QUOTE=kuisma;30812577]Not every fraction of a second, just once in a while, enough for the process to stay alive. Also, at a closer look, I see no reason why a cached process shouldn't be able to consume CPU cycles. Just because the Android app terminated, I see nothing that hinders the JVM (DVM) to keep threads going. Not for very long, though, since the ActivityManager loves to slay cached processes. Where in the Android OS Documentation did you find the claims this isn't possible?

Here: developer.android.com/guide/components/processes-and-threads.html

Code:
Empty process
A process that doesn't hold any active application components. The only reason to keep this kind of process alive is for caching purposes, to improve startup time the next time a component needs to run in it. The system often kills these processes in order to balance overall system resources between process caches and the underlying kernel caches.
This means to me that a cached process is an "Empty process".
Not having active components means no CPU usage.
I understand that from a UNIX point of view its process and pid will still be visible when typing "ps aux" in a console, but this process should not maintain a stable CPU usage around 5% (such as the one I wrote about in the first post of this thread) no matter what.
28th August 2012, 11:44 AM |#9  
kuisma's Avatar
Senior Member
Flag Sweden
Thanks Meter: 193
 
More
Quote:
Originally Posted by julioromano

Quote:
Originally Posted by kuisma

Not every fraction of a second, just once in a while, enough for the process to stay alive. Also, at a closer look, I see no reason why a cached process shouldn't be able to consume CPU cycles. Just because the Android app terminated, I see nothing that hinders the JVM (DVM) to keep threads going. Not for very long, though, since the ActivityManager loves to slay cached processes. Where in the Android OS Documentation did you find the claims this isn't possible?

Here: developer.android.com/guide/components/processes-and-threads.html

Quote:

Empty process
A process that doesn't hold any active application components. The only reason to keep this kind of process alive is for caching purposes, to improve startup time the next time a component needs to run in it. The system often kills these processes in order to balance overall system resources between process caches and the underlying kernel caches.

This means to me that a cached process is an "Empty process".
Not having active components means no CPU usage.
I understand that from a UNIX point of view its process and pid will still be visible when typing "ps aux" in a console, but this process should not maintain a stable CPU usage around 5% (such as the one I wrote about in the first post of this thread) no matter what.

I agree that "empty process" here means "cached process", but I see no claim that this process must not contain a worker thread, and not consume CPU. "Empty" is in the context of Android app level, i.e. contains no activity or service (no context), not OS level.

But you can always test this quite easy. Create an app with an activity only starting a worker thread, then terminating. See if the worker thread still consumes CPU during its existence as a cached process. I believe it will. Of course, this is an artificial construct, not very useful since it doesn't have any context and can not interact with Android. Still, performing gc, updating singeltons etc, are still very possible tasks for such a worker thread.

Edit: But the ad software maintaining a 5% CPU usage as a background/cached process, I'm quite sure is due to low programming skills. But possible, yes indeed.
Last edited by kuisma; 28th August 2012 at 11:57 AM.
28th August 2012, 12:20 PM |#10  
OP Junior Member
Flag Brescia
Thanks Meter: 3
 
More
Quote:
Originally Posted by kuisma

But you can always test this quite easy. Create an app with an activity only starting a worker thread, then terminating. See if the worker thread still consumes CPU during its existence as a cached process. I believe it will. Of course, this is an artificial construct, not very useful since it doesn't have any context and can not interact with Android. Still, performing gc, updating singeltons etc, are still very possible tasks for such a worker thread.

I agree with your line of reasoning, sometime in the coming weeks I'll try to develop a test app and then I'll post my findings here.


What keeps me mumbling on this topic is the general approach to process management on Android:

Android has been thought from the ground up with mobile devices in mind: such devices must put their CPU in the highest possible of its sleep states for as much time as possible not only when the screen is off, but also during regular usage e.g. browsing a web page.
When you read an article on your browser app, you'll want only your display chewing up battery juice and your CPU as close to 0% as possible (unless you're scrolling or zooming, but let's say you're just reading a piece without touching the screen).

With this approach in mind it should be clear that the only processes that should be able to be put into execution by the OS's scheduler are those belonging to categories 1 to 4 ( developer.android.com/guide/components/processes-and-threads.html ).

From an OS perspective, cached processes (category 5) are useful to avoid wasting otherwise empty RAM so that recently used apps can be relaunched as quickly as possible.
But if cached processes are able to use CPU cycles then this is by no means useful to the OS (nor the device), because you'll have no longer needed processes causing your CPU to exit its much beloved sleep state.

In other words:
-Having processes sit in RAM without wasting CPU is ok because it speeds up the system when you reopen those apps and still, those processes will be purged when more RAM is needed (i.e. caching).
-Having processes sit in RAM wasting CPU is not ok because the benefits you gain from caching are offset by the increased battery drain.
28th August 2012, 12:33 PM |#11  
kuisma's Avatar
Senior Member
Flag Sweden
Thanks Meter: 193
 
More
Quote:
Originally Posted by julioromano

I agree with your line of reasoning, sometime in the coming weeks I'll try to develop a test app and then I'll post my findings here.


What keeps me mumbling on this topic is the general approach to process management on Android:

Android has been thought from the ground up with mobile devices in mind: such devices must put their CPU in the highest possible of its sleep states for as much time as possible not only when the screen is off, but also during regular usage e.g. browsing a web page.
When you read an article on your browser app, you'll want only your display chewing up battery juice and your CPU as close to 0% as possible (unless you're scrolling or zooming, but let's say you're just reading a piece without touching the screen).

With this approach in mind it should be clear that the only processes that should be able to be put into execution by the OS's scheduler are those belonging to categories 1 to 4 ( developer.android.com/guide/components/processes-and-threads.html ).

From an OS perspective, cached processes (category 5) are useful to avoid wasting otherwise empty RAM so that recently used apps can be relaunched as quickly as possible.
But if cached processes are able to use CPU cycles then this is by no means useful to the OS (nor the device), because you'll have no longer needed processes causing your CPU to exit its much beloved sleep state.

In other words:
-Having processes sit in RAM without wasting CPU is ok because it speeds up the system when you reopen those apps and still, those processes will be purged when more RAM is needed (i.e. caching).
-Having processes sit in RAM wasting CPU is not ok because the benefits you gain from caching are offset by the increased battery drain.

I agree with you. Mostly.

I don't really care if an app consumes CPU in the incarnation of a hidden (background) app, or as an cached app waking up by e.g. AlarmMamanger once in a while, or even as a cached app using a worker thread. If I need the app, and the app need the CPU time, so be it. But more often, those are badly written apps, and then I don't care about the details of their inner workings, I just uninstall them ...

Also, even processes sitting in RAM without consuming CPU can be a menace. Take my Xperia for example. In the last version of GB it started so much bloatware, that the limit of 15 hidden tasks was exceeded. But the tasks was sticky, i.e. required to restart in the case of termination. The result was that the phone constantly killed and restarted all the hidden tasks, draining the battery doing ... nothing! Only restarting all the bloatware, time after time after time..!
Last edited by kuisma; 28th August 2012 at 12:35 PM.

Read More
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes