The battery power frob is great! But I think it may already be good enough to serve for this purpose. The apps that are consuming the most battery power, and the apps that are consuming the most CPU, are typically the same set.
I'm not arguing against your suggestion -- even if they were always the same set, it would be more clear for the users. But we can educate users to look there now for a clue to this information, even if it's not perfect. On May 4, 12:06 pm, Tomáš Hubálek <[email protected]> wrote: > I think that cure can be the same approach as when battery is out of > power. There is button Why? and it shows major consumers of the power. > > I think that Google could include in Android also some tool that shows > major CPU & Memory eaters. Users after this info will decide whether > they want such a greedy apps or not. > > Tom > > On 4 kvě, 19:52, 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 > 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
