I don't think your idea is going to work well too. The problem is,
there are some applications that need to run in the background (and
i'm not talking about the system applications here).

Let's assume you got some kind of scheduler which shall notify a user
when a certain event or time occurs.
Let's say a the user has a date at 18:00 and wants to be notified
17:35 to get out for the bus so he don't miss it. Now you use an
scheduler application you found at the android market. Now it's 17:20
and you're bored, so you think: Mh why not play a bit <insert random
game name here> before i have to go out for the bus.

So if the game get exclusive rights, this would mean that the
schedular app/background service would stop to work. Now if it's 17:35
the user won't get an notification, because the background process was
stopped. The user misses his bus and fucks up his date. Not really
something you want your users to happen, do you?

Wouldn't it be possible to simply let the GC process (of the other
applications) running with some low priorities and much slower, while
an application is in the foreground which needs much resources?

I mean, it doesn't matter if the GC of the other process (which caused
the GC) is done in 118ms or in 1180ms? It's in background anyways, so
that this wouldn't effect the focused activity?

On Mar 26, 8: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- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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