While I agree that consuming a bunch of memory has an impact -- it means apps have to be killed and restarted more often, for example -- there's no connection to GC.
GC is something that happens entirely within your own process, and is not affected by memory usage by other processes. Allocating a bunch of memory in your process will trigger the GC. The fact that somebody else HAS a bunch of memory, but isn't running, will not. Nothing another process does will trigger a GC in the foreground app. On May 4, 10:52 am, Eric F <[email protected]> wrote: > On May 3, 11:59 pm, mort <[email protected]> wrote: > > > And what's wrong with "resource consuming"? I coud cache several MB of > > data in a non-running service, it wouldn't matter. Android would just > > kick it if the memory's required, and the service would just reload > > the data when it's restarted. > > It's similar with CPU usage. If your service happens to do something > > in the instance the task killer loads it, it'll be killed, even if it > > only does that on certain events or once a day? And some services just > > need to do more than others... > > Besides, most task managers only show the main application, not the > > service. So CPU usage alway is 0, and memory usage, as said, doesn't > > really matter. > > I don't think it's necessarily right to say "there's nothing wrong > with consuming a huge amount of memory if you're sleeping, because the > low memory killer can just remove you". > > It's been my experience that the user's experience on the phone is > largely correlated with memory and not CPU usage. When I am flipping > between activities, stuff feels significantly less responsive as I see > the GC run. Also, obviously if an activity has dropped out of memory > because of the low memory killer and it needs to be recreated there's > going to be slowdown. > > So for some service that is sleeping, but still in memory consuming a > large amount of RAM, you can only make the claim that it is "harmless" > if it doesn't cause extra GC in the foreground apps and also doesn't > cause a situation where some activity was killed by the low memory > killer instead of the service. Which I don't think is a claim you can > make about a resource intensive service that is just sleeping but not > stopped. Maybe Dianne could comment on that, maybe I'm wrong. But it > seems to me that you can't guarantee that more activities wouldn't be > able to fit in memory if the service was actually gone. > > Also, I didn't know that the application stop caused alarmmanager to > unschedule the app, that certainly makes the use of it almost > certainly not what the user wants. Perhaps it needs to stay in the API > to maintain compatibility, but it can cause a pop up with an extra > disclaimer. Kind of like .apk installs can only be initiated and not > completed without interaction with the platform. > > -E > > -- > 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 > athttp://groups.google.com/group/android-developers?hl=en -- 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
