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
-~----------~----~----~----~------~----~------~--~---

Reply via email to