I could understand if you were saying that you can't provide multi-tasking experience on a single-tasking OS, such as Windows 3.1, which required cooperative multitasking. But I find it hard to understand what are the practical and technical reasons behind your resistance to provide a single-tasking experience on a multi-tasking OS.
Cheers On Thu, Mar 26, 2009 at 9:50 PM, Stoyan Damov <[email protected]> wrote: > On Thu, Mar 26, 2009 at 8:26 PM, Dianne Hackborn <[email protected]> wrote: >> On Thu, Mar 26, 2009 at 10:19 AM, Stoyan Damov <[email protected]> >> wrote: >>> >>> So, ok, I *admit* other apps can't cause DIRECTLY a GC in my app, but >>> it doesn't matter to me because other apps can cause the system to >>> lack memory and perform GC and it would ask my app's process to do GC, >>> which is how I understand JBQ's explanation of "remote GC". >>> >>> So back to my point. I don't care what causes GC in *my* process. If >>> it's not me I DON'T want my process to be bothered at all. >> >> There is no way at all for other processes to cause your process to GC. >> What other processes -can- do is run some work -- any kind of work -- on a >> thread running at the same or higher priority as yours, causing you to have >> to share the CPU with them. GCs are irrelevant to the problem here. (But >> they -are- relevant to writing your own code so that you don't cause GCs to >> happen in your own process.) > > Dianne, I haven't taken any time to dig in Android, so I don't know > what and how works. > All I know is that when *ANOTHER* process kicks GC, it affects MY > process, and my game stutters at this EXACT moment. > My game, like I said many times, *only* allocates memory on startup, > and then uses object pools. > I know that, when for example, the myFaves service is not trying to > send the damn MMS my games works PERFECTLY smoothly. > When it stutters, I see that GC has kicked in in process with PID "X", > and that X is not my game's process' PID. > > I hope you get it know. > >> >> Currently our approach for scheduling is that apps doing background work on >> a thread should lower that thread's priority -- the standard applications on >> Android do this. This has holes however, and allows people to mistakenly do >> background work at a higher priority, so we should more strongly enforce the >> scheduling of processes that are not running the foreground UI. >> > > No, what you should do, and I mean Google behind Android, not you in > particular, is create an user experience SIMILAR to that on the > iPhone. > You can have the best of BOTH worlds and provide background processing > (i.e. as it works right now) AND on top of that implement "single > tasking" *experience*. > The implementation details are IRRELEVANT to all of us, users, and developers. > If you don't do it, I can bet my ass that Android, as a mobile device > OS, and especially as a smartphone OS will not last as long as people > "predicted". > > Cheers > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
