blindfold wrote: > Aaargh! Thank you for this post, as it led me to fix a memory leak > where my app would consume 50K more with every run. I was looking into > all sorts of context leaks, but it was just that threads are not > automatically killed when pressing the back button to "exit" the app, > so if one launches a thread in onCreate(), one adds about 10K per run, > and DDMS will show a growing pile of threads as the run count > increases...
I try to use queues for controlling work done in background threads, mostly because that's how I was controlling background threads in pre-Android development. LinkedBlockingQueue is a great choice, though there are plenty of others in java.util.concurrent. (java.util.concurrent, by the way, written by Doug Lea, author of the book and the extract of same that M. Perrot linked to) So, in onDestroy(), I just pop my own KillEvent object on the queue(s) and, once the queues get to that message, they terminate their own threads simply by falling out of the queue-processing loop. So long as your queues don't get backed up too deep, you should be OK, and I think there's a priority queue implementation in java.util.concurrent as well if your threads still aren't closing up shop fast enough. -- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 2.0 Published! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
