1. Are you ready for the Galaxy S20? Here is everything we know so far!
Thread Status:
Not open for further replies.

Why you don't need a task killer

Discussion in 'Android Apps & Games' started by ardchoille, May 13, 2011.

  1. alostpacket

    alostpacket Over Macho Grande?

    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 (Text):
    1. if (WiFi==true)
    2. {
    3.   checkToSeeIfMusicNeedsSyncing();
    4. }
    5. else
    6. {
    7. //shutdown
    8. return;
    9. }
    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:

    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.

    ardchoille likes this.

    1. Download the Forums for Android™ app!


  2. Scythe

    Scythe Well-Known Member

    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.
  3. alostpacket

    alostpacket Over Macho Grande?

    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 :)
  4. Scythe

    Scythe Well-Known Member

    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. ;)
  5. HankAtrix

    HankAtrix Well-Known Member

    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)
  6. Scythe

    Scythe Well-Known Member

    Who knew ATK had a marketing department...
  7. HankAtrix

    HankAtrix Well-Known Member

    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.
  8. HankAtrix

    HankAtrix Well-Known Member

    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.
  9. vosg

    vosg Android Expert

    Let's give up.
    aysiu likes this.
  10. lunatic59

    lunatic59 Moderati ergo sum

    ...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

    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.
  11. @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.
  12. HankAtrix

    HankAtrix Well-Known Member

    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

    Attached Files:

  13. ElasticNinja

    ElasticNinja Android Expert

  14. ardchoille

    ardchoille Android Expert
    Thread Starter

    If you want proof, see the OP.

    </broken record>
    Usta, _mw_ and ElasticNinja like this.
Similar Threads - Why don't need
  1. Drchiefd113
  2. kumaranil13k
  3. kumaranil13k
  4. dorlow
  5. JimmyPixel3a
  6. iliji
  7. dontpanicbobby
  8. FensterBaron29
  9. User123app
  10. HeartOnFire69

Share This Page