Dianne Hackborn wrote:
> On Mon, Mar 15, 2010 at 3:34 PM, Mark Murphy <mmur...@commonsware.com
> <mailto:mmur...@commonsware.com>> wrote:
>
> Hmmmm...the upshot of this is that pretty much anything using
> AlarmManager for scheduled operations will, at least briefly, steal CPU
> time from foreground operations. If the alarm routes to an
> IntentService, the "heavy lifting" will still be done at low priority.
> But, those who elect to implement more smarts directly in the
> BroadcastReceiver will run at foreground priority for that work.
>
>
> Very true, though applications are strongly encouraged to keep the work
> done as a result of receiving a broadcast short and focused, and this is
> semi-enforced through the timeout (currently 10 seconds) until the
> system gives up on the app finishing.
Yeah, but, from the standpoint of a real-time game, 10 seconds of
sub-par frame rates would be unpopular. Heck, this whole thread was
triggered by complaints about lag issues that I suspect are a lot
shorter than 10 seconds in duration.
Hence, it's a fine topic for me to yammer about on blogs, in books, in
training, on random street corners ("The End Is Near! And Write
Efficient BroadcastReceivers, Dammit!")...
If you think of other scenarios where processes/threads in the
background class get promoted to foreground status, besides the ones you
mentioned, please let us know!
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://twitter.com/commonsguy
Android Online Training: 26-30 April 2010: http://onlc.com
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
