10.05.2012 12:25, Johan Appelgren написал:
Perhaps the Processes and Threads section in the Dev Guide could make
it more clear that it is up to each app to stop its background threads
Just to add some perspective:
Every Android application has a bunch of Binder threads that are created
by "the system", and stay around when the app goes into foreground or
gets paused.
They are not locked/suspended/prevented from running in some way, but,
in absence of things to do, these threads just sit on a wait primitive,
and do not consume the CPU or battery.
The UI thread is the same way, its processing loop stays around ready
for when/if the app is resumed or a service / receiver event.
WebView also has a worker thread that stays around but is supposed to be
doing nothing (which is actually not always the case, but that's a
bug... very unfortunate, but a bug).
So, just like "process being in memory" is not necessarily the same as
"process consuming the CPU"...
.. "a thread that exists within the app's process" is not necessarily
the same as "a thread that's computing Pi to a million digit precision,
loading all CPU cores as much as it can".
and otherwise ensure they don't do anything when they're not in the
foreground then? Seems like a fairly common mistake that is difficult
for most users to understand, they just notice that their phone gets
slower over time.
Which is why, I guess, some games recommend that you force stop all
cached processes before playing. Not very user friendly.
It might have something to do with potential GC events in background
processes, and these games trying to achieve very high frame rates, and
having next to no spare cycles in their input/game/render loops.
--
Kostya Vasilyev
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
