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

Why you don't need a task killer

Status
Not open for further replies.
Sorry for the copy pasta but this topic keeps coming up and I think a lot of it has to do with Google's missteps with UX design.
Anyways here's a post I made in another thread about the issue:

from: http://androidforums.com/android-ap...-wont-shut-off-stay-shut-off.html#post2636849

( Ardchoille, if you would like to incorporate any of this information in your guide, please feel free of course :) )


=============================


Just to explain a bit about what those apps are really doing when they look like they are turning themselves on all the time:

The Android OS has a list of "events" (called Intents) that it broadcasts when various things happen (such as Wi-Fi being enabled).

Apps are then allowed to "register" what's called a Broadcast Receiver to "listen" for the events.

When I say "listen" though, it's only in the metphorical sense, they dont do anything to actively listen or run. Instead, what happens is the Android OS will send out the event (called an Intent), and it will check a list of apps that have said they would like to be "woken up" and notified when that event occurs.

So in the example used above with doubleTwist, what is likely happening is that it registered for the WiFi-enabled Intent and is being woken up whenever your WiFi connects or re-connects.

This might seem like it could really use up resources, but in reality it doesnt. BroadcastReceivers are very simple tiny peices of code.

Going back to our doubleTwist example, what the code might look like:

Code:
if (WiFi==true)
{
  checkToSeeIfMusicNeedsSyncing();
}
else
{
//shutdown
return;
}
And that's it. It would use probably something like 0.00001% of your battery.

But the features it enables, are almost limitless. It gives apps very good ways to help the user automate things, help be polite to a user and not use up their 3G connection, and so on and so fourth.

Now of course not all apps are polite, and the way Dalvik handles processes, threads and services can be pretty complicated for any non-programmer to follow. However, hopefully this explanation will at least shed some light on Broadcast Recievers.

Anyways, it might be time to add a new guide to my list and I'll see if I can explain all those things in simple terms.

The basic components are:
-Activities
-Services
-BroadcastRecivers
-Intents
-Processes
-Threads

And while 99% of the time a task killer will do more harm than good (especially in Froyo and above), I will admit that Google made a serious error with regards to user experience (UX) design in explaining this. From a new user perspective, it looks as if all apps are all behaving badly all the time (hence why we get these posts). While in reality, badly behaved apps are actually few and far between. But it can be hard to tell the difference.

Also a good thing for new users to be pointed towards is the "what's been using the battery" feature in Android.

Home > Settings > About Phone > Battery use


anyways, hth.
 
I don't think it's a UX issue (implying that somehow the UI is to blame for it), I think it's the fact that Android allows task managers to be used on the phone in general. Removing their ability to function has steadily been increasing with each SDK release. In 2.2 they definitely took a step in the right direction by removing a lot of the ability to "kill" an app.

Also add "IntentService" to your list. It's a service that sits idle until a request tells it to do some work. I usually use them in coordination with broadcast receivers to off load the work.
 
I don't think it's a UX issue (implying that somehow the UI is to blame for it), I think it's the fact that Android allows task managers to be used on the phone in general. Removing their ability to function has steadily been increasing with each SDK release. In 2.2 they definitely took a step in the right direction by removing a lot of the ability to "kill" an app.

Also add "IntentService" to your list. It's a service that sits idle until a request tells it to do some work. I usually use them in coordination with broadcast receivers to off load the work.

I hear what you're saying and you have a good point I think.

but UX != UI

User eXperience designers usually are the guys doing flowcharts in visio, not User Interface designers. You probably already know that though but anyways, it was worth pointing out.

However, I still think the information they chose to display is part of what causes people to think inncorrectly about how Android memory and performance work. If you look at stock Gingerbread even, it shows me that my music app has been running for the past 174 hours. In that time I have listened to maybe 8 hours of music.

But Google isn't totally to blame, and in a lot of ways blame is a silly concept here, it's more about misunderstandings, miscommunications, and old outdated ideas from desktop computers. For years Windows and Apple computers worked that way, and still do, to some extent. So a little misunderstanding from new users is to be expected, but I think Google has some room to do more to explain how things are working.

Also, incidentally IntentService is just a subclass of Service :)
 
I hear what you're saying and you have a good point I think.

but UX != UI

User eXperience designers usually are the guys doing flowcharts in visio, not User Interface designers. You probably already know that though but anyways, it was worth pointing out.

However, I still think the information they chose to display is part of what causes people to think inncorrectly about how Android memory and performance work. If you look at stock Gingerbread even, it shows me that my music app has been running for the past 174 hours. In that time I have listened to maybe 8 hours of music.

But Google isn't totally to blame, and in a lot of ways blame is a silly concept here, it's more about misunderstandings, miscommunications, and old outdated ideas from desktop computers. For years Windows and Apple computers worked that way, and still do, to some extent. So a little misunderstanding from new users is to be expected, but I think Google has some room to do more to explain how things are working.

Also, incidentally IntentService is just a subclass of Service :)

UI and UX are pretty synonymous. It's all semantics, haha. For once I support the idea of why Apple hid away a lot of the core information from basic users. ;)

Also IntentService definitely is a subclass, it's just that it's unique in its own right since it's not physically doing any work until you tell it to (and buffers up requests in a queue), unlike a normal service class which is expected to be constantly running. It's hard to explain to some folks that just because a service is running, it doesn't mean it's actually doing any work. ;)
 
You keep talking about RUNNING apps, even if the difference between inactive "cached" apps and running ones has been explained over and over again.

Do you really fail to see the difference?

People have also asked you to post those apps that slow down your device. You don't answer.

For me, task killers do more harm than good (own experience).

If you don't come up with some examples, I don't see any benefit in following this thread any longer.

Best of luck with your task killer.

You should try ATK. It works great. When I kill 30 apps at a time ATK doesn't designate whether they are cache or running. The simple answer is that the phone runs significantly faster after I close apps (hitting the ATK widget or letting it do an auto-kill through the day).

Here is example: After I run task killer it closes all of the apps on the phone that aren't on the I ran benchmarks (as I've discussed) and saw a 20-30% improvement in the benchmarkets after closing the apps.

As I've said a few times, ATK works because it lets you set up a fixed ignore list (stopping it from closing apps that you don't want it to close)
 
You should try ATK. It works great. When I kill 30 apps at a time ATK doesn't designate whether they are cache or running. The simple answer is that the phone runs significantly faster after I close apps (hitting the ATK widget or letting it do an auto-kill through the day).

Here is example: After I run task killer it closes all of the apps on the phone that aren't on the I ran benchmarks (as I've discussed) and saw a 20-30% improvement in the benchmarkets after closing the apps.

As I've said a few times, ATK works because it lets you set up a fixed ignore list (stopping it from closing apps that you don't want it to close)

Who knew ATK had a marketing department...
 
I think letting the system handles when to claim resources is better approach. (like in programming, GC vs manual garbage collection). but android gives manual management if you need.
Even with safe kill, it's still not a good approach, because android process has its own virtual machine. And when you kill it, and need it back later, you need to boot it up again. and it consumes more resources.

No problem! As I've said a few times in the post, that although Android does a great job of multitasking, performance can be improved with having few apps running/in cache. As an additional point, Google is putting task killer in Android and Motorola already does so on many of their phones. I like ATK better though.
 
And.... you still just don't get it. Many people have told you repeatedly in this thread, and posted screen shots as proof. Just because apps are "running" or cached or whatever you decide you want to call it (I'll let you pick the word, because you don't really understand the meaning of it anyway) there is no CPU usage.

If there is no CPU being used, how is performance being degraded "because we only have 1 CPU in the phone"???

The screen shots didn't prove anything. They were simply showing that users running and cached apps. He doesn't choose to use a task killer.

I think you may have a misunderstanding if you don't you don't think running apps use CPU. The running apps run in memory and use CPU. When you are running many apps it takes more CPU resources (both in actually running the apps and in managing apps to/from cache). Generally speaking, more open apps = less performance on the runnng apps.
 
...from the Book of Technology in a letter to the pedestrians, 14:18-27

18. And lo, the Archangel Google did appear before the Alliance
of the Open Handsetand spake unto them, "Go forth and spread
the news of source code without restriction and make thee thine
handsets for the masses. Do this and thy profits shall soar to
the heavens."


19. And then the Archangel did seek out the community of
development for without their praise and worship, the fruits of the
Alliance would surely be lost. And once more the voice of Google was
heard throughout the lands. "Rise up from thy parent's basements
and cleave unto thy coding ways for the light has surely come and
his name shall be Android."


20. With data center held on high, the Archangel did reach out with
his mighty network and did distribute kits of development to all who
were worthy. And these lowly folk were raised up from the depths and
did produce their applications and games and distributed them freely
to the market.

21. And the Archangel looked down and saw what they had done and
did bless them with the sweetness of productivity in the form of cupcakes,
doughnuts, eclairs, frozen yogurts, gingerbreads, honeycombs and ice
cream sandwiches. And the developers did partake of these treats and
were filled with the gratitude of the people.

22. But in to their midst came an insidious beast who vowed to turn the
wine of the community into deceptive vinegar. This beast was brought
to kill great quantities of the developers' wares with a single stroke
proclaiming knowledge of the error of the Archangel and his minions.

23. "Take heed unto me," cried the beast and he held a magicians
wand aloft. "With one stroke of my wand, I can eliminate all that which
has been constraining your feet in the muck of productivity. See me,
brethren, as I demonstrate the power of my might as relieve you from
unnecessary tasks."


24. And the beast did bring down his wand upon a group of developers
and did kill them.

25. The people did cry out unto the beast, "Oh why have you killed
these developers? What purpose should it serve?"
And the beast did
respond "The developers were unworthy in my eyes and served no
use for me. Now you may be free of their ways and manners and move
faster and more freely. Embrace me and this, too may be yours forever."

26. But the Archangel spoke down to the beast, "Leave thee demon,
for you have killed my useful developers and in my power I shall raise
them up again to once again be useful. Yours is the false prophecy of
efficiency and shall forever be cast down to the lowly task of utility and
maintenance."

27. And the Archangel did raise up the once killed developers and
reinstated them in the memory of Android. And the people saw the
power of Google and the futility of the beast and did cast his burdens
from their shoulders and were free of his false promises.

Thus sayeth the CIO, Amen.
 
@lunatic59 I don't think it's possible to win harder in one post than you just did right there lol.

I've been keeping up with this thread since the beginning and I just have to say, not only have I been enlightened on the details of lower level resource management in Android (which is awesome as I'm interested in diving into app and custom ROM development), but I am also amazed at how civil and intelligent (and patient lol) the discussion and debate has been. It makes me glad to be a part of this community for sure and says a ton about the quality of the membership here.
 
So you're killing 20-30 apps at a time and you have no idea whether or not they're actually running or cached? Do you not understand what you're doing, or do you enjoy making your system work harder?

Efficiency? If you kill running apps the system will have to reload them from scratch, they were running because the system needed them. When the system is done with them the system will move them from a running state to a cached state. Apps don't run indefinitely once they are launched unless they're part of a needed service. If you kill cached apps the system will just cache more apps to replace the ones you killed.

Improvement on performance and battery life? You're under the spell of power of suggestion.. some developers have a silver tongue and can get people to install and run almost anything.. it's called Social Engineering.

ATK has been downloaded 280,000 times? I'm sure there were more people than that who once believed the earth was flat. Not one of those people actually proved the earth was flat. Why did so many people follow that erroneous belief? Never underestimate the power of ignorance.

No, your phone does not have a task killer installed by default, your phone has a task manager installed by default, there's a huge difference. Third-party task killers are bad for android.

The point is you, the user, have no idea what the app that you're killing is doing. If an app is running, it's running for a reason and killing it will force the system to restart it - this is why people think they have a rogue app installed. If the app is cached, killing it will force the system to cache another app in its place.

I'm a developer for android and other platforms, I spend a lot of my time trying to overcome myths like third-party task killer benefits. I'm not trying to get you to buy or install anything.. I'm just amazed that you would ignore how the system really works.

Denial.. it ain't just a river in Egypt.

Good day :)

Atrix has an app killer as part of the base build. It is part of the task manager. They call is Auto End List. The a auto-end and states:
"Apps on this list end when the screen times out"
I've attached a picture
 

Attachments

  • Phone Pic with Task Killer.jpg
    Phone Pic with Task Killer.jpg
    122.5 KB · Views: 319
Status
Not open for further replies.
Back
Top Bottom