[Vibrant General] masterotaku:
Guess it's time to chime in again here. I wrote a rather lengthy post earlier in the thread about why I choose to not use task killing applications.

Given that we're all running on battery operated devices, it would seem that the overriding goal of such software would be to extend or maximize battery life. Correct me if there is some other primary goal here.

In this regard the problem isn't really task killers at all. It's rather what we choose to do with them, what apps we choose to install, and the degree to which we pay careful attention to what these apps are doing.

Task killers can (if one is not careful) lead to a false sense of control. There is the assumption that having control over background service and application management is a good thing, simply because you can control it. However, if you fail to understand what you are doing and fail to grasp the interdependency of many apps and services (even 3rd party ones) you can indeed create more problems than you are trying to solve.

People make statements that seem qualitative, yet are really anecdotal owing to a poor understanding of what things really mean.

"Now I have 160megs free, instead of 34!!". On the surface, this would seem to be a good thing. So someone kills a bunch of apps and goes "HOORAY!" I have more memory NOW. The mistaken belief here is that more free memory is intrinsically a good thing.

Oftentimes however within seconds that free memory begins immediately reverting itself to a lowered state. Why? This goes back to app and service interdependency. Killing, for instance, a social networking application that uses the system's background syncing system is going to do little except insure that the applications reloads itself fairly soon as it's sync schedule dictates. Would it have been better to just leave it alone? Well here again there is no clear answer. It DEPENDS ON THE APP ITSELF. In general however, one could say that it's a bit pointless to kill an app that is going to merely relaunch itself. And, if the given application does run efficiently, it's altogether likely that simply reducing it's sync interval would go a long way towards being A BETTER IDEA in the first place. And a live re-sync of most of those sorts of apps takes seconds should this be inconvenient.

"I killed all apps and my Quadrant Score jumped 200 points!!!" If this impresses you, you are failing to understand what a benchmark is, why benchmarking is done, and what it means in the real world. Technology reviewers (I did this sort of thing in the PC universe for over 10 years professionally) routinely kill applications and/or use specific OS scenarios for benchmarking to squeeze the best numbers possible out of benchmark evaluations. But, they do not do this for e-peen reasons. They do it for consistency and fairness when evaluating things in relative terms. Benchmarking a platform to get a fair comparison of its capabilities and USING a platform are two entirely different things. And keep in mind that 10-20 minutes later in order to get that same uber-awesome-sauce score increase you're going to have to kill everything again. If staring at bar charts is your thing, have at it, but this is a complete waste of time reason.

At the end of the day the thread is asking the wrong question. Task killers can be useful, providing you understand what you are doing. Can they make matters worse? Definitely. It all depends on you.

The more important issue is how do we manage battery life effectively. Monitoring battery use statistics, paying attention to partial wake usage, reducing SNS application update intervals, noticing the supposedly "off" phone in your pocket frying your thigh...etc...these things will likely go further in the long run towards maximizing the potential of your smartphone.

If you keep having to kill the same apps over and over again to achieve effective battery life, you have to consider asking WHY you have to do this. Two aspects of the Android Market play into the answer to this question. First, there is little in the way of oversight so it's entirely likely a great looking and functioning app can indeed be buggy enough (or coded poorly enough) to be a bad idea for battery life. Secondly, apps are in a more fluid state of development for Android than any other mobile platform...i.e. apps gets updated more frequently. And these updates can bring bad with the good. If an app is indeed a "keeper" (and this is a uniquely personal decision), then it may be in your best interest to put up with having to kill it occasionally to use it. Again this is a CHOICE.

I choose to make other app choices when I encounter these sorts of issues generally speaking. And I note with a bit of irony that I still refrain from using task killers and task managers, given my nature. I've been a "tweaker" of all things gadgety and computery for almost 30 years (built my first computer in 1982, back when a soldering iron was not optional). What this long history has taught me however, is that I am the number one cause of my gadget grief.

I get about a day and a half use out of my Vibrant at this point, running Eugene's Vibrant6 release, and this is with moderate use. My phone doesn't spend all it's time in my holster either. But my results are anecdotal and irrelevant, as I'm sure I'm not running the same apps as everyone else. The only core Vibrant application I can comment on as being a potential battery problem is the default messaging client. It appears to cause excessive screen-wake-time when using notifications that HandcentSMS (my preferred messaging app) does not. Just throwing that out there.

One thing I can say, is that I do not run task killers to achieve the battery life I have. In my experience they are not necessary if you pay attention to what's going on with your phone and take steps to manage any issues that arise. The choices of applications and widgets you run are what impact your battery life. Batteries are used by things that use them. This is sort of obvious isn't it? So solutions to battery life issues have to start with YOU and YOUR CHOICES first.