• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Best Auto App Killer app

Jiayu

Lurker
hi ive had my droid forr about a month now and have tried juice defender ultimate and also auto task killer pro to kill my apps when i turn my screen off. i was wondering if theres any better solution to close your apps after you exit out of them without having to manually do it as it really bugs me how apps dont auto close themselves
 
While I agree you don't need an auto task killer, I don't see anything wrong with killing apps you don't use often.
Personally, I force close apps that I don't use often, doing that stops the apps from starting again until I launch them myself.
That way, the only apps Android keeps in memory are apps I use regularly.
 
Using a task killer is much worse than just letting them be. Those apps aren't using battery, they're just temporarily stored to quickly access them if needed. If they aren't needed (Or if another app you're using needs it), that memory is released.

Android is designed to handle its own memory, and it does it quite well.

Don't fight against it, just let it do its thing :)
 
oh thank you! very helpful :) is this why advanced task killer pro lists way more apps than the basic task manager that comes preinstalled on my phone? because all these apps are cached rather than running? this makes me feel much better as i assumed not having a task manager would really drain the battery hard
edit: sorry didnt see the last two replies as i never refreshed the thread whilst looking at the mods link, rxpert basically answered this post lol


thanks guys great forum!
 
Using a task killer is much worse than just letting them be. Those apps aren't using battery, they're just temporarily stored to quickly access them if needed. If they aren't needed (Or if another app you're using needs it), that memory is released.

Android is designed to handle its own memory, and it does it quite well.

Don't fight against it, just let it do its thing :)

All operating systems are designed to handle memory, some do it better than others.
Unlike the Android masses, I personally think it's stupid for an OS to randomly start apps that I'm not going to use. It is much more efficient to keep apps I will use in memory and avoid the swapping of apps I won't use.
 
Unlike the Android masses, I personally think it's stupid for an OS to randomly start apps that I'm not going to use. It is much more efficient to keep apps I will use in memory and avoid the swapping of apps I won't use.
It's *not* more efficient. To fully explain exactly why would take a long technical explanation and a decent understanding of Linux/Andriod internals. If you really want to know Google is your friend, I'm not into it here.

To the OP: Uninstall Juice Defender, it's crap. Uninstall the task killer, it's even worse. Relax and enjoy your phone.

Linux user #266351. Android since v1.0
 
Juice Defender is not a task killer. It just turns off data when your screen is off and turns data back on when your screen is off.

It does not kill running apps.
 
Juice Defender is not a task killer. It just turns off data when your screen is off and turns data back on when your screen is off.

It does not kill running apps.

Yes, and its the task killer that most people replying to this thread have recommended against.

Personally, I recommend staying away from juice defender as well but thats more of a preference and not as clear cut.

Task killers are just bad.:)
 
I generally leave it to android to manage, but for a few apps that constantly run multiple processes in the background, stitcher radio etc... I use GMD gesture control, it has a function where you assign a gesture to instantly kill the app. I use the paid version but I think it's also in the free version.
 
I never used a task killer, but if there's an app open that's a battery hog, a simple going into open apps and force stop will suffice enough.
 
It's *not* more efficient. To fully explain exactly why would take a long technical explanation and a decent understanding of Linux/Andriod internals. If you really want to know Google is your friend, I'm not into it here.

To the OP: Uninstall Juice Defender, it's crap. Uninstall the task killer, it's even worse. Relax and enjoy your phone.

Linux user #266351. Android since v1.0

Whatever dude.
I'm so sick of sheep spewing the same crap about this.

It is more efficient to keep apps in memory that I will be using instead of swapping apps I won't, that's just common sense.

It makes me laugh when someone like yourself tries the "It's technical so I won't go into BS".
I've been dealing with various flavors of Unix since the early 90's.
I'm a certified IBM AIX specialist. I build AIX virtual lpars that share memory, cpu, and network with many other lpars on the same managed system, thru VIO. I manage 3 power 740's, 2 550's, 3 520's, and a 750. I do performance/tuning, LPM, taught myself HACMP, WAS, etc. I've done Solaris, HP-UX, svr4, and even PrimeOS, and OpenVMS.

The only way non system processes start on my servers is if they are started in /etc/inittab, rc scripts, job scheduler, or manually.
I don't have to read what others have spewed to understand resource management, I get paid well for it and on a much larger scale than that of Android.

But like I said, whatever dude. I'll let you all continue following blindly behind the masses accepting their explanations.
 
Whatever dude. Not gonna argue qualifications. I'll just say I started on Novell. But as a certified Unix pro, you should well know that the obvious or common sense answer is not always the correct one, particularly when dealing with Android since it's operation differs considerably from other 'nix variations.

I'm out.

Linux user #266351. Android since v1.0
 
I don't know anything about Linux; personal experience with my Androids have taught me that battery life is better without task killers or juice defenders.
This sheep will continue to follow the masses and let my smart phone operate how it was designed to.
 
Whatever dude. Not gonna argue qualifications. I'll just say I started on Novell. But as a certified Unix pro, you should well know that the obvious or common sense answer is not always the correct one, particularly when dealing with Android since it's operation differs considerably from other 'nix variations.

I'm out.

Linux user #266351. Android since v1.0

There is no way that starting random apps is better than only starting apps that you're going to use, plain and simple.
How on earth does it make sense for the OS to launch a live wallpaper, soundhound, calculator, etc, into memory when I'm not going to use it? That's ridiculous.

I also don't understand why people who spew this rhetoric never acknowledge that if you force close a user app, that app will NEVER start again until you start it manually.

That's why I always state that an auto task killer is bad because it will keep killing apps at will, which can reduce battery life, but killing them on your own, even if it's a task killer that you use to kill it, is not the same as automatically killing them.
There is a difference.

I don't use live wallpapers, twitter, rsa, citrix receiver, google+, etc, all that often, so after I use them I force close them. They will not start again until I start them.
That leaves room for apps like Dolphin, terminal emulator, go sms (apps I use daily) to be in memory all the time.
 
How on earth does it make sense for the OS to launch a live wallpaper, soundhound, calculator, etc, into memory when I'm not going to use it? That's ridiculous.

A wallpaper, live or otherwise, will only be 'loaded' if it's explicitly requested to do so. Similarly anything loaded by the OS is either required by something else already running, or has been told to do so by the user. An app that remains idle beyond a certain threshold will be closed by the OS memory management routines anyway.

if you force close a user app, that app will NEVER start again until you start it manually.

That's not necessarily true. If you force-close a user app that is configured to poll for updates every 15min then that app will restart because it thinks you want it to.

I don't doubt your extensive background in 'nix systems, but Android isn't Unix; it was designed and built from the ground up to run optimally on mobile memory-constrained devices. See here for confirmation straight from the horse's mouth i.e. Google's own software engineers.

-----------------------------------------------------------------------
Finally, can I ask that all contributors treat each other with the respect required by our Site Rules? Differences of opinion are part and parcel of life, but insulting and/or denigrating others for simply disagreeing will not be tolerated.
 
A wallpaper, live or otherwise, will only be 'loaded' if it's explicitly requested to do so. Similarly anything loaded by the OS is either required by something else already running, or has been told to do so by the user. An app that remains idle beyond a certain threshold will be closed by the OS memory management routines anyway.



That's not necessarily true. If you force-close a user app that is configured to poll for updates every 15min then that app will restart because it thinks you want it to.

I don't doubt your extensive background in 'nix systems, but Android isn't Unix; it was designed and built from the ground up to run optimally on mobile memory-constrained devices. See here for confirmation straight from the horse's mouth i.e. Google's own software engineers.

-----------------------------------------------------------------------
Finally, can I ask that all contributors treat each other with the respect required by our Site Rules? Differences of opinion are part and parcel of life, but insulting and/or denigrating others for simply disagreeing will not be tolerated.

There are only a few live wallpapers that I actually use. If I stop using them and don't force stop them, the OS will randomly load them again at some point as it will any app that you've ever opened.

Yes, apps you have set to auto update will start again, that's a given so I didn't bother to state it, I don't speak to adults in micro details.

My extensive Unix background isn't stated in an effort to say I know android better, it's for those who claim they don't want to get technical as if I am incapable of keeping up with it.
It's also done to show that I do know about computer resource efficiency since I handle it every day on servers that costs hundreds of thousands of dollars.

There is no way starting apps I'm not going to use is more efficient than only starting apps that I will use.

I'm not saying what android does doesn't work, I'm saying it isn't nearly as efficient as what the masses keep saying.

I would much rather have the ability to tell my system what apps to start than having it choose on my behalf.
Give me RC scripts and inittab any day over randomly starting apps.
 
Yes, apps you have set to auto update will start again, that's a given so I didn't bother to state it, I don't speak to adults in micro details.

Please remember that AF's very large membership encompasses people with all levels of experience. Newcomers to Android may well arrive at this topic via a search looking for advice.... the suggestion that, by not knowing something that wasn't actually explicitly stated, they are somehow not "adults" is both demeaning and at odds with Android Forums' ethos of friendly helpful support.
 
I think there are some assumptions being made and some conclusions being drawn from observation so let me see if I can explain what's going on with Android and preemptive caching.

First I'd recommend reading this article by Dianne Hackborn, a Google software engineer.

Android is a compact mobile OS. Unlike desktop OS's it doesn't have the luxury of space to load redundant apps or services. Because of this many of the necessary functions of the OS are part of one of the system apps and then called by others. Because each ROM is developed for specific devices these dependencies will vary by manufacturer and model. This is why it may appear that Android is randomly launching apps.

I can't tell you how many times I've had to help someone reflash their phone back to stock because they deleted a system app they though they didn't need because even though they never used it, it kept launching "all by itself." Apps like the mail client or Facebook or the Gallery etc. all can send messages, but there is only one message transport service within the OS. It may be part of the Facebook app. Every time you send a text or email, the OS calls for the message transport service which shows Facebook as running, even though you've never used it. Remove Facebook and you've removed the ability to send any message from any app. (Facebook is just used as an example).

On a desktop OS, each application can have their own discrete services which can be started and stopped on demand by the app. Removing Outlook won't disable messenger. (okay, it might, but that's Microsoft software ... installing Outlook might disable messenger ;) )

Android is an on-demand OS, meaning you expect events to happen immediately without having to wait for an app to launch or service to start. That's why Android wants to load up the free memory. Your phone rings when someone calls, alarms go off on time, news is updated when the screen comes on, etc. For this to happen smoothly, apps are cached based on a priority based hierarchy. I don't know the algorithms used so I can't tell you which gets loaded first or which get dropped first, but it's based on both last time an app is used and the frequency of its use. In that regard, killing off stuff may be counterproductive. If you kill an app that provides a service for another app because you don't use it, the next time you do need it, it will relaunch the killed service and then you'll kill it again. Rinse and repeat. This get's that "unused" app bumped up on the frequently used list meaning it gets a higher cache priority. Vicious circle that.

I only ever kill hung apps anymore and let Android do it's thing. There really hasn't been any performance issues that I've noticed.
 
I think there are some assumptions being made and some conclusions being drawn from observation so let me see if I can explain what's going on with Android and preemptive caching.

First I'd recommend reading this article by Dianne Hackborn, a Google software engineer.

Android is a compact mobile OS. Unlike desktop OS's it doesn't have the luxury of space to load redundant apps or services. Because of this many of the necessary functions of the OS are part of one of the system apps and then called by others. Because each ROM is developed for specific devices these dependencies will vary by manufacturer and model. This is why it may appear that Android is randomly launching apps.

I can't tell you how many times I've had to help someone reflash their phone back to stock because they deleted a system app they though they didn't need because even though they never used it, it kept launching "all by itself." Apps like the mail client or Facebook or the Gallery etc. all can send messages, but there is only one message transport service within the OS. It may be part of the Facebook app. Every time you send a text or email, the OS calls for the message transport service which shows Facebook as running, even though you've never used it. Remove Facebook and you've removed the ability to send any message from any app. (Facebook is just used as an example).

On a desktop OS, each application can have their own discrete services which can be started and stopped on demand by the app. Removing Outlook won't disable messenger. (okay, it might, but that's Microsoft software ... installing Outlook might disable messenger ;) )

Android is an on-demand OS, meaning you expect events to happen immediately without having to wait for an app to launch or service to start. That's why Android wants to load up the free memory. Your phone rings when someone calls, alarms go off on time, news is updated when the screen comes on, etc. For this to happen smoothly, apps are cached based on a priority based hierarchy. I don't know the algorithms used so I can't tell you which gets loaded first or which get dropped first, but it's based on both last time an app is used and the frequency of its use. In that regard, killing off stuff may be counterproductive. If you kill an app that provides a service for another app because you don't use it, the next time you do need it, it will relaunch the killed service and then you'll kill it again. Rinse and repeat. This get's that "unused" app bumped up on the frequently used list meaning it gets a higher cache priority. Vicious circle that.

I only ever kill hung apps anymore and let Android do it's thing. There really hasn't been any performance issues that I've noticed.

It seems to me that most of what you're referring to are system apps, which I have excluded in my discussions about this.

I'm talking user installed apps only. For example, if I use seesmic and don't use it again for 6 months, seesmic will be restarted by the OS periodically because I've used it in the past. However, if I force close seesmic, it will never start again until I start it.
It's the same with other user installed apps.
There are apps that I use daily, and there are apps I use very infrequently. There is no logical explanation for the infrequent apps to launch weekly or even monthly, but if you look, there they are.

It is much more efficient to launch the apps I use regularly instead of the apps I don't. That is why Unix has rc scripts (starts and kills), and inittab (starting at boot, only do it once, respawn) {start again if killed}, etc. It's to give the admin control over what is or isn't starting at any given time.
Android seems to have all apps set to respawn.

My problem is people constantly say don't kill apps, most who regurgitate that info don't even know why they're saying it other than that's what they were told. I base that assumption on the fact that whenever this debate gets going, not one person can neither see or admit that starting random apps isn't possibly more efficient than only starting apps that you use regularly.

The only problem with killing the apps is if you do it automatically, since android does launch apps on its own, having an auto task killer is counterproductive. I wouldn't use cron to run a script to constantly check for and kill an app, I would simply stop that app from starting.

However, force stopping an app is different. The app won't restart, so there is no battery drain because it isn't going to need to be killed again.
I compare killing vs force stopping to using kill on Unix with different flags.

The other problem is when closing an app on Android, the app doesn't fully exit, it's still in BG waiting for me to use it again later.
In Unix if you exit an app, it completely stops, there is no trace of it in memory, no cpu resources, and it even relinquishes any paging space it was using.

Yes, I know, Android is not exactly Unix, but resources are resources.

Perhaps the debate is as simple as some users like me wanting more control since I have that type of control on my servers at the office.

Again, I'm not saying Android's way doesn't work, but someone like me that is use to telling my servers what to do and when to do it, I find it hard to believe that there are those who are ok with their server (in this case android device) doing what it wants.

I'm also not alone.

Issue 14889 - android - Allow choosing the startup applications - Startup manager - Android - An Open Handset Alliance Project - Google Project Hosting
 
It seems to me that most of what you're referring to are system apps, which I have excluded in my discussions about this.

I'm talking user installed apps only. For example, if I use seesmic and don't use it again for 6 months, seesmic will be restarted by the OS periodically because I've used it in the past. However, if I force close seesmic, it will never start again until I start it.
It's the same with other user installed apps.
There are apps that I use daily, and there are apps I use very infrequently. There is no logical explanation for the infrequent apps to launch weekly or even monthly, but if you look, there they are.

I used system apps as an example because the removal or disabling of them causes the most problems, but it works the same for user installed apps. Again, I don't know what the algorithms or triggers are that determine what apps get preloaded into cache but I find it hard to believe that they are completely random selections. Android is designed to optimize memory based on a few assumptions. First, if you use an app, you are likely to use it again, so they will be kept cached (and shown as running, which is why it looks like an Android app never really stops). If you've used and app or service frequently, but haven't launched it, if there is free memory, it will attempt to preload it assuming you will be using it again. If an app shares a service and that service is started, apps that use it will be preloaded as well. It's not a perfect system, but for the vast majority of your average users, it works very well without any user interaction or configuration. That's really the point.

It is much more efficient to launch the apps I use regularly instead of the apps I don't. That is why Unix has rc scripts (starts and kills), and inittab (starting at boot, only do it once, respawn) {start again if killed}, etc. It's to give the admin control over what is or isn't starting at any given time.
Android seems to have all apps set to respawn.

Unlike a desktop or server OS, when an app is preloaded into memory, it's not actually running. The only resources consumed other then the memory space it occupies would be the processor cycles necessary to move the app into RAM. From that point, until you call the app, it has no impact on device resources. Android is designed to keep memory full, so if there is room to cache all used apps, it will do so. And if it sees additional resources, it will use those, too so that when you ask the device to perform a task it is poised to execute it immediately rather than waiting for programs and services to launch.

My problem is people constantly say don't kill apps, most who regurgitate that info don't even know why they're saying it other than that's what they were told.

With Eclair and earlier versions of Android, apps that locked, crashed or went rogue we more common and needed to be killed. The "task killer" model was born out of that and it was the easy answer for people struggling to understand what was going on. Unfortunately FroYo introduced much better resource management and made task killers counterproductive. Many who had found them useful, continued to use them indiscriminately and blamed Android for the performance and resource issues. And, many carriers recommended to first tier support that a task killer was an easy way to solve customer problems (and some continue to do so.) It's similar to people who warm up their cars for 20 minutes on a cold day, even though with modern fuel injected cars using synthetic oil, even on the coldest day, one minute is sufficient. And then they complain that their mileage isn't as promised.

I base that assumption on the fact that whenever this debate gets going, not one person can neither see or admit that starting random apps isn't possibly more efficient than only starting apps that you use regularly.

Now here I have to take exception with that statement. On the face of it, it is an obvious truism, but there are two erroneous assumptions that make it inaccurate. The first is that Android is starting apps randomly. There is a priority to the selection of apps to get preloaded. I just don't know what it is, exactly. The second is the claim of efficiency. Granted there is a consumption of resources on the initial load, but from that point forward, the impact on the user is imperceptible. Your average user notices four things in terms of performance. One is battery life. Having cached apps (listed as running) has no impact whatsoever on the battery. It actually can be more efficient if the cached app is used or going to be used. Another is the speed at which apps launch and process. Again a preloaded app will respond more quickly, although once launched it's performance wouldn't be any different from an app that was started cold. Next is the smoothness, which most times is more a function of the GPU and CPU speeds. Finally is storage space, which is irrelevant to this discussion.

Android is designed for the overall general user experience, not for the power user who measures performance in clock cycles. The fact that it *can* be configured to accommodate the power user is more to Android's credit.

The only problem with killing the apps is if you do it automatically, since android does launch apps on its own, having an auto task killer is counterproductive. I wouldn't use cron to run a script to constantly check for and kill an app, I would simply stop that app from starting.

However, force stopping an app is different. The app won't restart, so there is no battery drain because it isn't going to need to be killed again.
I compare killing vs force stopping to using kill on Unix with different flags.

That comparison is accurate only if the Android app is actually running and not sitting in a cached state.

The other problem is when closing an app on Android, the app doesn't fully exit, it's still in BG waiting for me to use it again later.
In Unix if you exit an app, it completely stops, there is no trace of it in memory, no cpu resources, and it even relinquishes any paging space it was using.

Yes, I know, Android is not exactly Unix, but resources are resources.

Yes and no. With a desktop or server OS if you keep launching processes you will eventually reach a point where there aren't enough resources to proceed. Android will free up the resources necessary to execute the current task even if it means stopping services or dropping apps

Perhaps the debate is as simple as some users like me wanting more control since I have that type of control on my servers at the office.

Again, I'm not saying Android's way doesn't work, but someone like me that is use to telling my servers what to do and when to do it, I find it hard to believe that there are those who are ok with their server (in this case android device) doing what it wants.

I'm also not alone.

Issue 14889 - android - Allow choosing the startup applications - Startup manager - Android - An Open Handset Alliance Project - Google Project Hosting

What most who are saying about task killers, either automated or done on a task by task basis is that there really isn't any increased efficiency. Whatever gains you might see by tweaking the configuration you will lose in the administration of it. For the vast majority of Android users, the best course of action is "laissez faire".
 
I used system apps as an example because the removal or disabling of them causes the most problems, but it works the same for user installed apps. Again, I don't know what the algorithms or triggers are that determine what apps get preloaded into cache but I find it hard to believe that they are completely random selections. Android is designed to optimize memory based on a few assumptions. First, if you use an app, you are likely to use it again, so they will be kept cached (and shown as running, which is why it looks like an Android app never really stops). If you've used and app or service frequently, but haven't launched it, if there is free memory, it will attempt to preload it assuming you will be using it again. If an app shares a service and that service is started, apps that use it will be preloaded as well. It's not a perfect system, but for the vast majority of your average users, it works very well without any user interaction or configuration. That's really the point.

I understand the point of placing apps in a suspended state assuming I'm going to launch it again, which would make launching faster. I'm not debating that. Using your definition, the debate would be the algorithm.
I'm on call every 5 weeks, that is typically when I would use the rsa and citrix receiver apps. I see no reason why those two apps would again or still be in memory if I haven't used them in 5 weeks, yet Android will at some point launch them again or keep them in memory. I also agree that it works, it just isn't as efficient as completely stopping the app and letting me make the determination as to when it should be in memory.
I also think your "It's not a perfect system" line is what I was looking for, since many people who speak on this topic seem to imply that it is, which is my point.




Unlike a desktop or server OS, when an app is preloaded into memory, it's not actually running. The only resources consumed other then the memory space it occupies would be the processor cycles necessary to move the app into RAM. From that point, until you call the app, it has no impact on device resources. Android is designed to keep memory full, so if there is room to cache all used apps, it will do so. And if it sees additional resources, it will use those, too so that when you ask the device to perform a task it is poised to execute it immediately rather than waiting for programs and services to launch.
It is actually running, it's taking memory, but not cpu. I have sar on my phone, and I also use vmstat, I can see that the memory is inuse, but unfortunately without svmon I can't see exactly which apps are using what amount of memory. Perhaps system tuner will show me I'll check it out.
As to not having to use cpu cycles to for that app, I disagree because it will have to swap that app for another. It's like watching vmstat on Unix, seeing it scanning for memory blocks no longer in use, and freeing those blocks. It may not be much, and the average user won't even notice, but that isn't my point, again, I know it works.


With Eclair and earlier versions of Android, apps that locked, crashed or went rogue we more common and needed to be killed. The "task killer" model was born out of that and it was the easy answer for people struggling to understand what was going on. Unfortunately FroYo introduced much better resource management and made task killers counterproductive. Many who had found them useful, continued to use them indiscriminately and blamed Android for the performance and resource issues. And, many carriers recommended to first tier support that a task killer was an easy way to solve customer problems (and some continue to do so.) It's similar to people who warm up their cars for 20 minutes on a cold day, even though with modern fuel injected cars using synthetic oil, even on the coldest day, one minute is sufficient. And then they complain that their mileage isn't as promised.
I totally understand that point and agree with it. I never advocate the use of auto task killer for that very reason, but it is different than force closing the app. In you ever used an aosp ROM, they usually provide a kill app function. That function actually force closes the app. If you open Dolphin for instance, then exit Dolphin, you can go into apps, and see that Dolphin is in fact still running. However, if you use the kill app function in an aosp ROM, then check Dolphin, it has been completely stopped because the force close option is greyed out.


Now here I have to take exception with that statement. On the face of it, it is an obvious truism, but there are two erroneous assumptions that make it inaccurate. The first is that Android is starting apps randomly. There is a priority to the selection of apps to get preloaded. I just don't know what it is, exactly. The second is the claim of efficiency. Granted there is a consumption of resources on the initial load, but from that point forward, the impact on the user is imperceptible. Your average user notices four things in terms of performance. One is battery life. Having cached apps (listed as running) has no impact whatsoever on the battery. It actually can be more efficient if the cached app is used or going to be used. Another is the speed at which apps launch and process. Again a preloaded app will respond more quickly, although once launched it's performance wouldn't be any different from an app that was started cold. Next is the smoothness, which most times is more a function of the GPU and CPU speeds. Finally is storage space, which is irrelevant to this discussion.
This again points to the swapping of apps that is needed in order to make that happen, and yes there are resources used to make that swap, albeit it miniscule, but for me, I would rather have complete control. Argumentative? Probably.

Android is designed for the overall general user experience, not for the power user who measures performance in clock cycles. The fact that it *can* be configured to accommodate the power user is more to Android's credit.
Agreed.

That comparison is accurate only if the Android app is actually running and not sitting in a cached state.
Covered above.

Yes and no. With a desktop or server OS if you keep launching processes you will eventually reach a point where there aren't enough resources to proceed. Android will free up the resources necessary to execute the current task even if it means stopping services or dropping apps
Every OS I've worked on scans and frees for unused memory blocks and puts that unused memory back into the pool, this is done every second throughout the time that the server is running. The only time it poses a problem is when there is a rogue app with a memory leak, that refuses to release its assigned memory or paging space.


What most who are saying about task killers, either automated or done on a task by task basis is that there really isn't any increased efficiency. Whatever gains you might see by tweaking the configuration you will lose in the administration of it. For the vast majority of Android users, the best course of action is "laissez faire".
I disagree with the first part simply because it is more efficient to have apps I am going to use in suspension instead of apps I'm not going to use, which is why I force close the apps that I don't use frequently. To me that makes better use of the memory because the only apps in suspension are the ones I use regularly.
I do agree with the last part of your statement.

Lastly, I have to say that I do appreciate finally having someone speak about the subject in an intelligent and articulate manner. It's refreshing considering that most simply say "it handles it better" with absolutely no explanation. I think that's what bothers me the most about this entire topic. I simply hate the herd mentality.
 
Back
Top Bottom