Wird das RAM knapp? Von Taskkillern und anderen bösen Buben

Sehr gut geschrieben - warum nicht als Blog veröffentlicht? :-)

Lässt sich gut lesen

Vielen Dank!

einfach nur hervorragend, Izzy! Mehr braucht man dazu nicht zu sagen.

Sehr cool und wirklich hilfreich für viele Anfänger.
Ich fände es cool, wenn Izzys Beiträge einen extra Bereich kriegen würde, da wenn das so weitergeht, besteht die erste Seite des "Apps" Forum nur noch aus gepinnten Beiträgen und des weiteren wären die Beiträge auch noch einfacher zu finden. Ist aber nur meine Meinung ;-)
Noch mals Izzy, sehr sehr cool gemacht ;-)

— geändert am 08.11.2010, 13:22:05

Wow wirklich schön geschrieben. Denke dieser Thread wird mein neuer "Darauf verlinke ich bei unwissenden Task-Killernutzern"-Tread

@Evelyn habe dich erst nach Izzys Post erkannt

Moooment! Wir sind hier nicht bei Windows, wo ein Programm gestartet wird und daraufhin den Speicher blockiert und die CPU mit Leerlauf-Zyklen belastet!
Und es gibt nur einen "echten" "Auto-Start-Hook".
Was hier woh eher gemeint ist: Android schickt bei bestimmten Ereignissen sogenannte "Broadcasts" und die Apps können sagen, auf welche sie reagieren wollen. Z.B. System wurde hochgefahren (der "echte Autostart"), SD rein/raus, Bildschirm an/aus, SMS empfangen, etc. Je nach Benachrichtigung passiert das nur, wenn ein laufender Dienst dafür registriert wurde oder - weitaus häufiger - immer, d.h., bei Bedarf wird die App in den Speicher geladen. Es wird dann nur die Benachrichtigung abgearbeitet, und sofern nicht z.B. ein Dienst gestartet oder weitere Benachrichtigungen eingeplant wurden, passiert danach überhaupt nichts mehr bis die App wegen Speichermangel gekickt oder wieder benötigt wird.
In den meisten Fällen ist die sinnvollste Lösung, in den Einstellungen dafür zu sorgen, dass beim "normalen" Autostart eben kein Dienst gestartet bzw. kein regelmäßige Benachrichtigungen eingeplant werden. Dann dauert halt das Hochfahren eine Nanosekunde länger und der Task erscheint in der "Taskliste" (eher Speicherbelegung) bis er vom System geputzt wurde, aber das stört nicht wirklich...
Die "Autostarts" (=Benachrichtigungs-Empfangs-Wünsche) einfach zu entfernen kann dafür sorgen, dass die Anwendungen nicht mehr richtig funktionieren - denn das System benachrichtigt diese dann auch nicht mehr, wenn sie laufen. Wie gesagt, Android macht da keinen Unterschied. Im Normalfall sollte das Abarbeiten so einer Benachrichtigung auch nicht lange dauern, und sofort danach kann Android die App ja auch schon wieder aus dem Speicher werfen.
Richtig ist aber, dass es ggf. etwas dauern kann, wenn z.B. nach "SD wurde eingesteckt" (wird auch nach einem Reboot signalisiert) 10 Apps damit loslegen die gesamte Karte nach neuen Liedern, eBooks, Navi-Karten, ... zu durchsuchen. Das ist dann einfach schlechter Programmierstil, den aber leider auch Androids systemeigene Medienbibliothek an den Tag legt.

Ach ja, und mal generell zum Speichermangel-Problem: Dass eine Anwendung wegen Speichermangel nicht starten kann, kann seit Android 2.0 überhaupt nicht vorkommen und bei älteren Versionen nur wenn der Speicher komplett voll ist mit Diensten, die von sich behaupten "Vordergrunddienste" zu sein (d.h., der Benutzer weiß, dass da was läuft, und es sollte nicht unterbrochen werden). Weil das zu oft mißbraucht wurde, können das seit Android 2.0 nur Dienste behaupten, die ein Icon in der Benachrichtigungsleiste haben, und auch diese werden mittlerweile wenn nötig "gekillt" - wenn auch erst, wenn sonst nichts mehr geht.

Das weitaus größere Problem bei Android ist der Speicherverbrauch einer App selbst. Google hat nämlich den Hauptspeicherbedarf einer App auf 16MB begrenzt (ohne den App-Code selbst, also "nur" für Objekte und Variablen), selbst wenn noch 2GB frei wären - mit 27 Bildern in HVGA-Größe (320*480*4 Byte pro Pixel) ist der erlaubte Speicher also schon voll, andere interne Daten gar nicht mitgerechnet. Bei manchen (W)VGA-Geräten wurde dieses Limit auf 24MB erhöht. Damit sollte wohl gewährleistet werden, dass das System nicht durch Apps mit Speicherloch lahmgelegt wird.
Dazu kommen noch ein paar Systembugs und hinterlistige Fallstricke, die schnell mal dafür sorgen, dass der Speicher schneller vollläuft (z.B. kein Recycling von Element-Views in ausklappbaren Listen, Referenz-Kreisschlüsse durch interne Referenzen in Android-Klassen, etc.), und schon hat man einen Absturz wegen Speichermangels obwohl doch scheinbar so viel frei ist...

Mein Milestone hat sich mehrmals am Tag rebootet - dachte erst es wäre ein Feature bis ich den AdvancedTaskManager deinstalliert habe -> Keine Reboots mehr, RAM zu genüge vorhanden und der Akku wird auch nicht schneller leer.

MEIN(!) FAZIT: Autokill braucht kein Mensch!

Ach ja, und noch eine Zusammenfassung zum Task-/Speichermanagement, dass ich demletzt in 'nem anderen Forum gepostet hab. Vielleicht hilft's ja dem ein oder anderem beim Verständnis...

- Was man in den meisten Taskmanagern sieht, sind die Anwendungen, die im Speicher liegen. Sie "laufen" aber (meistens, mehr dazu später) nicht und werden vom System entfernt, wenn es Speicher benötigt.
- Das Entfernen aus dem Speicher dauert nicht so lange wie bei Windows 3.x sondern geschieht meist unmerkbar schnell
- Eine Android-App macht nur etwas, wenn sie sichtbar ist, ein Hintergrunddienst läuft (dafür gibt's 'ne eigene Liste in den Einstellungen) oder gerade eine Nachricht (Android-Slang: "Broadcast-Intent") abgehandelt wird
- Solche Nachrichten werden z.B. nach dem Hochfahren, beim Entfernen/Einschieben einer Speicherkarte, beim Empfangen einer SMS, Ein-/Ausschalten des Bildschirms und vielen anderen Ereignissen gesendet; die Apps können angeben, welche davon sie empfangen wollen. Ist die App nicht im Speicher, wird sie dafür geladen. Außerdem können Apps zeitgesteuert, auch regelmäßig (z.B. alle 5 Minuten), "eigene" Nachrichten vom System senden lassen.
- Es gibt keine einfache Möglichkeit festzustellen, ob und wie oft eine App etwas im Hintergrund macht.
- Bis einschließlich Android 2.1 wurden beim "Killen" eines Tasks auch die von diesem angewiesenen zeitgesteuerten Nachrichten entfernt, wodurch z.B. Wecker oder Profiltools nicht mehr funktionierten. Bei Android 2.2 wurde das von Google geändert, da dieses Verhalten zu viele Probleme bereitete (v.a. durch "Autokiller").
- Es gibt seit Android 2.2 also keine Möglichkeit, über das System regelmäßige Hintergrundjobs zu beenden. Da muss man schon die Einstellungen der App anpassen oder sie deinstallieren...
- "lange Home drücken" bringt keine Taskliste, sondern die zuletzt gestarteten Apps, egal ob diese laufen bzw. im Speicher liegen oder nicht
- Es gibt derzeit keine Möglichkeit, in Android Tasks aus Anwendersicht zu verwalten, also z.B. eine Art "Alt-Tab" zwischen den Apps, die man gerade "offen hat"

Und warum läuft es bei mir dann nicht flüssig?
Klar habe ich einiges in der Whitelist, und hatte bisher auch keine anderen Probleme, ich bekomme E-Mails, Anrufe, SMS, Spiele laufen.

Hallo, danke für die Beiträge.

Ich möchte nur mal ergänzen, dass das Samsung Galaxy S i9000 (und vermutlich auch das Galaxy Tab) von Samsung aus standardmäßig einen Taskmanager haben, in dem vom User aufgerufene Apps beendet werden können oder sogar der RAM bereinigt werden kann, ohne dass Probleme entstehen.

Gerade wenn man viel offen hat und es langsam wird, ist diese Methode prima.

Ich habe auch einen Taskmanager auf meinem DHD, allerdings schiesst der nix automatisch ab sondern wenn dann mache ich das nur manuell selber. Ich habe einfach ein besseres Gefühl Abends bevor es ins Heiabettchen geht bestimmte Sachen abzuschiessen und dann in Ruhe zu schlafen.

Irgendwie verstehe ich jetzt auch nicht wirklich den Sinn von dem Multitasking, wenn APPS ja nur im RAM ruhig schlummern und keinerlei Aktivität haben wie wirkt das sich auf Multitasking aus?

Hat da einer mal eine einfache und verständliche Antwort drauf? Eventuell ist das eine etwas dumme Frage aber ich lasse mich gerne belehren

Danke für den Artikel. Nun einiges mehr klar

Naja, wie mans nimmt...
Ich meinte eher das "Task-Management", wie mans von Windows gewohnt ist und was z.B. bei webOS richtig gut gelöst ist: Also hauptsächlich für die Übersicht "was mache ich gerade", wo ein geschlossenes Fenster möglicherweise im Tray aktiv bleibt, aber beim Umschalten zwischen den Tasks nicht stört. Bei Android wird die Anwendung beim Killen gnadenlos aus dem Speicher geworfen, während sie bei nahezu jedem modernen Desktopsystem auch gecached wird - nur eben unsichtbar für den User. Und sobald sie auf irgendeine Nachricht reagiert hat und danach im Speicher liegt, scheint sie zu "laufen". Eigentlich bräuchte man aber eher eine Liste, die Apps vom ersten Erscheinen eines Fensters bis zum "Beenden" auflistet, egal ob sie gerade im Speicher liegt oder nicht.
Beim Verwalten der "Hintergrundjobs" dagegen bietet Android keine Möglichkeit, einzusehen, was über den "AlarmManager" eingeplant wird. (Für Fortgeschrittene: sowas wie cron oder AT, für andere: startet Aktionen zeitgesteuert.) Und das Beenden von Hintergrundjobs ist je nach App und Androidversion unmöglich oder sehr "rücksichtslos".

Tja, vor Android sind alle gleich, da werden halt bevorzugt überladene Riesenapps gekillt. Selbst wenn sie der Home-Ersatz vom Hersteller sind. ;-)

Multitasking ist bei Android nicht ganz trivial. Um die Ressourcen so weit wie möglich zu schonen, gibt es vier Fälle (die letzten beiden sind technisch nahezu gleich gelöst):
1. Der sichtbare Teil von Anwendungen (schimpft sich bei Android "Activities"). Dieser wird nur ausgeführt, solange die App wirklich sichtbar ist - ansonsten könnte er ja in den allermeisten Fällen ohnehin nur auf Eingaben warten, die es nie geben wird. Aufs Multitasking haben derart schlafende Apps keinerlei Einfluss, sie werden komplett ignoriert. Sie liegen nur solange wie möglich im Speicher um ggf. schneller wiederhergestellt zu werden.
2. Hintergrunddienste müssen explizit als solche programmiert werden. Sie haben auch eine "Warteschleife", die Meldungen abarbeitet, ähnlich wie Windows-Anwendungen. Wenn der Dienst aber nicht "richtig arbeitet", braucht diese üblicherweise kaum bemerkbar CPU. Störender kann schon eher sein, dass Android laufende Dienste erst killt und den Speicher freigibt, wenn dem System der Speicher ansonsten extrem knapp wird.
3. Reagieren auf bestimmte Systemereignisse. Dafür wird die App wenn nötig auch in den Speicher geladen. Abgearbeitet wird aber nur der Ereignis-Handler, ein richtiger "Programmstart" muss das nicht sein. Es kann z.B. einfach ein Flag gesetzt werden, dass beim nächsten Start nach dem Einschieben einer (neuen?) SD deren Inhalt kurz geprüft werden soll, oder auch gar nichts geschehen. Es kann aber in Einzelfällen auch das volle Programm loslegen, z.B. wenn ein Medienplayer nach dem Druck auf eine Headset-Taste startet.
4. Eingeplante Ereignisse. Üblicherweise plant eine App Benachrichtigungen an sich selbst ein, die um eine bestimmte Zeit (z.B. Wecker) oder regelmäßig (z.B. Tweet-Check alle 15 Minuten) abgearbeitet werden (wahlweise auch, wenn der Bildschirm ausgeschaltet ist). Theoretisch wäre es aber auch möglich, dass z.B. eine Twitter-App den Standard-Musikplayer alle 10 Minuten startet.

Hoffe, das macht's etwas verständlicher...

Das (und das "User-Taskmanagement") habe ich hier auch versucht, den Leuten von Google klar zu machen. Ich befürchte aber, das war mit deren Denkweise inkompatibel... Naja, vielleicht war's wenigstens ein Schubs in die richtige interne Diskussionsrichtung.

Die Antwort auf Heikos Post hatte ich geschrieben, während du deinen verfasst hast. Ich glaube, zusammen passt das ganz gut - Regelfall und Ausnahmen...

Also wer mir in Essen (NRW) ein Milestone 2.1 zeigt das direkt nach dem booten schnell ist, dann... hm, bin ich verwundert xD
Zu den restlichen Punkten muss ich zustimmen, Android managed das selber, und die meisten Apps die gelistet sind nehmen höchstens etwas Ram, nur CPU Time wäre wirklich schlimm^^ Was ich zT noch beobachte ist das der akku schneller leergesaugt wird - wo es aber sicher oft einen bestimmtn übeltäter gibt xD

Sollte kein großes Problem sein. Einfach nicht allzu viele Apps installieren, die nach dem Booten irgendwas aufwendigeres treiben, dann noch die SD nicht übermäßig vollstopfen, damit Androids Medien-Indizierung nicht ewig läuft, und schon ist das Gerät nach dem Booten genauso schnell oder langsam wie nach einem "Komplettkill". Vermutlich sogar minimal schneller, weil manche Apps noch im Speicher liegen statt neu geladen werden zu müssen.

Den Akku ziehen dann aber die Apps, die wirklich etwas machen - ob nun im Hintergrund oder nicht (v.a. Spiele saugen oft gewaltig...).
Allerdings ist das mit dem Akkuverbrauch generell sehr undurchsichtig. Da scheint's oft auch von den Treiber-Implementierungen der Geräte abzuhängen - ich könnte mir vorstellen, dass v.a. SD-Leser und die Steuerung der Prozessorgeschwindigkeit große Unterschiede ausmachen. Da wird in den Foren oft diesselbe App mal als übelster Akkufresser bezeichnet, während andere nicht den geringsten Mehrverbrauch feststellen können.

Kurz nochmal zum Thema Multitasking und App im Hintergrund:

Nehmen wir mal an ich lade eine vollgepackte Webseite, das Laden dauert mir zu lange und ich drücke die Hometaste um in der Zeit schnell das Wetter anzusehen, was passiert nun im Hintergrund mit dem Laden der Webseite?

Kann man das wirklich Multitasking nennen?

Mir wiederspricht es auch das ich Apps nicht einfach so beenden kann, ich mag die Bevormundung von Android auch nicht wirklich und deshalb nutze ich schonmal einen Taskkiller.

Ich kann mit dem Android "Multitasking" nicht wirklich etwas anfangen.

— geändert am 09.11.2010, 10:45:12

Vielleicht kommt das ja nochmal.

Im Moment gibt es da zwei Probleme, die das "komplette" Multitasking (noch) nicht zulassen.

Zum einen die Hardware, die das aktuell nicht lange mitmachen würde. Nicht nur zu wenig Speicher, ich denke auch die CPU wäre schnell am Ende. Aber daran wird ja fleißig gearbeitet. Die "kleinen Dinger" werden immer schneller.
Zum anderen aber auch der Akku, der für solche Sachen imho viel zu schwach ist. Wenn der Akku im Moment ca. einen Tag hält, würde er mit "komplettem" Multitasking wahrscheinlich gerade mal einen halben überstehen.

Wenn man jetzt manuell daran rumschraubt (RSS einfrieren, jenes beenden und Browser weiterlaufen lassen) wäre das ziemlich viel manueller Aufwand, weil man bei jedem Schließen entscheiden müsste, was man will.

Ich denke, im Moment ist die Android-Lösung ein sehr guter Kompromiss. Und m.E. immernoch das beste Multitasking, was es für Smartphones gibt. Aber wenn die Hardware besser wird, wird auch das ausgebaut. Da bin ich mir sicher.

Frank

Der Satz muss auf jeden Fall in die Warnung.



Da sind wir wieder beim allgemeinen Problem des Kapitalismus. Solange sich mit wenig Aufwand viel Geld verdienen lässt, brauche ich mir kein Bein ausreißen. Das kann ich alles in Ruhe vorbereiten und aus der Schublade ziehen, wenn die Stimmen zu laut werden

OK, genug abgeschweift. ich denke, es wird irgendwann kommen. Spätestens wenn der Druck der Konkurrenz zu groß wird. Aber bis dahin werden wir deinem Wildfire und meinem Magic die letzte Ruhe gegönnt haben und ein potenteres Phone unser Eigentum nennen.

Frank

Vielleicht "kloppen" wir uns jetzt nur um Begriffe, aber ganz so mag ich das nicht stehenlassen. Eine App ist nicht als "Service gekennzeichnet", ein Service ist optionaler Teil einer App.
Oder ums mal allgemeinverständlich auszudrücken: Im Beispiel mit dem Browser gibt es zwei Möglichkeiten:
1. Die Seite wird vom sichtbaren Teil der App geladen. In diesem Fall wird das Laden unterbrochen solange die App nicht sichtbar ist.
2. Es wird für das Laden der Seite ein Service gestartet (falls er nicht schon läuft) und dieser damit beauftragt, die Seite im Hintergrund zu laden. Ist die App nicht sichtbar, läuft dann auch wirklich nur dieser Teil der App (also das Laden der Seite, nicht der Darstellungsteil). Wenn der Dienst nicht läuft (weil z.B. gerade keine Seite geladen wird), macht der Browser im Hintergrund überhaupt nichts. Viele Apps stoppen die Dienste z.B. wenn das Hauptfenster mit der Zurück-Taste verlassen wurde.

Es liegt also ganz in der Hand des Programmierers, ob und was im Hintergrund weiter läuft.
Problematisch bei Android ist, dass man als Anwender wenig Einfluss darauf hat, wann etwas im Hintergrund weiter läuft (bzw. regelmäßig angestoßen wird). Das "Beenden mit Zurück" ist optional, nicht wirklich intuitiv und oft unpraktisch - etwa, wenn man beim Browser erst gefühlte 1024x zur vorherigen Seite kommt. Ein "Beenden"-Button bzw. Menü-Item ist unerwünscht. Google geht gar so weit, den "Abmelden"-Button bei der offiziellen Twitter-App als intuitives "jetzt bitte nicht mehr im Hintergrund checken" anzupreisen...

Wie gesagt, das muss man trennen.
Dienste und Nachrichten-Behandlung laufen mit einem "stinknormalen" Multitasking im Hintergrund, nur der Teil, der für die Darstellung nötig ist, wird "eingefroren". Wobei Android alles, was nicht explizit als "Hintergrundarbeit" programmiert wurde dem Darstellungsteil zuschlägt - aber das sind eher Entwickler-Details.

Wobei man ja auch "beendete" Apps intern erstmal nur "einfrieren" könnte und diese dann beim OOM-Aufräumen bevorzugt wegwerfen könnte.

Bei den meisten Apps wäre das auch kein Problem, viele haben ja gar keinen Hintergrunddienst. Die würden also genauso wie "eingefrorene" im Zweifelsfall gekickt und neu geladen.

— geändert am 09.11.2010, 11:39:07

Mir ging's halt vor allem darum, dass das "als Service gekennzeichnet" missverstanden werden kann. Hätte die ganze App so ein "Service-Flag", würden Browser, Mediaplayer, etc. ja auch im Hintergrund laufen, wenn sie gar nichts zu tun haben. Bei einem Dienst, der (hoffentlich...) nur bei Bedarf läuft, sehen CPU- und Speicherbedarf schon ganz anders aus.
Es ist in diesem Bereich aber wirklich schwer, ein sinnvolles Mittelmaß zwischen "stark vereinfacht für technische Laien" und "technisch korrekt für die Versierteren" zu finden.

Das, und außerdem möchte ich mich beim nächsten Start nicht von Hand neu anmelden.

So hier mal ein Screenshot nachdem ich mit der Hometaste die Androidpit APP "verlassen" habe da wunderte ich mich das das scrollen des APP Drawers etwas ruckeliger war als sonst, ein Blick was CPU braucht hat mir dann das hier gezeigt UND GENAU DESWEGEN nutze ich die Funktion APPS zu "killen".
Kein Wunder das ein Akku dann schön leergesaugt wird ohne das wirklich ein Nutzen dadurch entsteht und genau deswegen weil ich sowas "kille" hält mein DHD Akku auch 2 Tage trotz normaler Nutzung! Da ist es mir nun völlig egal wie intelligent Android Apps behandelt, auf das verlasse ich mich nicht.

Warum APPBRAIN APP MARKET nun auch CPU Leistung zieht obwohl ich das syncen der App auf MANUELL stehen habe verschliesst sich mir auch völlig, meine Konsequenz ist ich "kille" die APP damit Ruhe ist und meine CPU etwas für die Umwelt tut, nämlich Energie sparen

— geändert am 09.11.2010, 12:31:42

Sicher saugt die am AKKU, die verbraucht CPU siehst du das nicht? Nachdem "killen" der APP geht die CPU Belastung runter und zwar massiv runter!

RICHTIG in den Screenshot schauen gell?

Oder denkst du etwa ich wäre net blöd? *LOL*

Übrigens ich will jetzt nicht die APP von AndroidPIT hier negativ hinstellen, aber manchmal braucht die auch im Hintergrund ordentlich CPU und das mag ich nicht wenn es nicht nötig ist, macht die APP aber auch nicht immer, tun andere APPS auch hin ud wieder, warum weiss der Geier aber ich "kille" dann und gut ist, deshalb wird ein Taskmanager auf meinem DHD immer drauf bleiben, nicht um wild um mich zu schiessen aber um selber zu kontrollieren was abläuft und ich warte lieber 2 Sekunden länger auf das starten einer APP als das ich öfters aufladen muss.

EDIT:
Gerade sehe ich das es ein neues Update der AndroidPIT App gibt mit dem Recht "BEIM BOOTEN STARTEN" so wie ich das sehe war das vorher nicht so und GENAU deshalb werde ich die APP jetzt auch nicht updaten, wozu macht Ihr sowas? Ich nutze mein DHD nicht nur um AndroidPIT zu benutzen und sehe es auch nicht ein das es sich beim Booten automatisch startet, es läuft schon genug im Hintergrund was in meinen Augen nicht nötig ist. Sooo frei wie Android gerne hingestellt wird für den Nutzer ist es dann doch nicht, man sollte selber entscheiden dürfen was beim Booten automatisch gestartet werden darf, zumindest wenn es APPS sind die nicht wirklcih für das Android System benötigt werden.

— geändert am 09.11.2010, 13:03:28

Ich hab die ja nun nicht programmiert, aber ich würde vermuten, dass das entweder mit dem Market (Updates!) oder den Foren-Benachrichtigungen/PNs von AndroidPit zusammenhängt. Schau doch mal in die Einstellungen, ob sich da was machen lässt (verwende die App selbst nicht...).

Nun dafür müsste ich updaten und das tue ich erstmal nicht, es laufen schon genug Sachen nach dem Booten im Hintergrund die mich massiv stören werde jetzt nicht weiter meinen Akku belasten mit Dingen die nicht nötig sind. Dennoch Danke für den Hinweis.

Wenn ich ein Smartphone wollte was mich bevormundet hätte ich mir besser ein iPhone gekauft das kann das nämlich besser

— geändert am 09.11.2010, 13:06:47

Interessanterweise war in dem von mir verlinkten Thread im Google-Entwickler-Forum auch einer, der auch fürs iPhone programmiert. Die haben wohl seit iOS4 genau dasselbe Problem mit den Hintergrunddiensten. Es ist dort zwar nicht so viel möglich, bei dem was möglich ist, weiß aber auch kein User, was da eigentlich gerade seinen Akku leersaugt...

Es ist die APP "SYSTEM PANEL APP" und am linken Rand siehst du doch das die APP die CPU belastet und du darfst mir auch ruhig glauben nachdem die AndroitPIT APP von mir "gekilled" wurde das die CPU Belastung wieder auf normal Niveau ging. Ich kann ja hier nur ein statisches Bild zeigen aber die AndroitPIT App hat sehr viel CPU immHintergrund beansprucht, habe ja nun keinen Grund hier euch auf den Arm zu nehmen.

Die AndoidPIT APP hatte ein wenig CPU Schwankungenj der Screenshot zeigt das die APP CPU benötigt aber nicht ganz soviel wie oben die Anzeige das liegt einfach an der kleinen Verzögerung der Anzeige, aber die APP hat die CPU stark beansprucht, es geht ja jetzt auch nicht um die AndroidPIT APP sondern um den Sinn oder Unsinn eines Taskmanagers.

Autokill gibt es bei mir nicht nur manuell wird "gekilled".

EDIT
Nochmal für alle Zweifeler, sobald ich die AndroidPIT App beendet hatte gin gid eCPU Belastung wieder auf das normale Niveau runter, ich spekuliere hier nicht ich habs doch gesehen!

Nochmal EDIT
So wirkt das sich ja jetzt auch nicht immer aus, aber hin und wieder bemerke ich das APPS dann doch mehr tun als nur "eingefroren" meinen RAM "warm" zu halten, nicht das jetzt der Eindruck entsteht die AndroidPIT App ist hier der Maßstab!

— geändert am 09.11.2010, 14:01:25

Tja, und letztlich hängt's doch wieder an dem Problem, dass Android keine intuitive, einheitliche Methode für "App verlassen, bitte nichts weiter im Hintergrund tun" bietet...
Wobei natürlich schon mal interessant wäre, was die App da im Hintergrund treibt. Vermutlich einfach nur nach neuen Tests, Blogeinträgen, Updates, etc. suchen.

Nunja, und dazu noch ein paar ungeschickt programmierte Autostarts bzw. Ereignis-Behandlungsroutinen. Aber das Problem kennt man ja schon vom Desktop. ;-)