Apps korrekt beenden - das warum und wie ..

Da mir in der letzten Zeit immer öfter Apps begegnen, die nicht korrekt oder gar nicht beendet werden, möchte ich hier mal in Kürze vorstellen warum man das tun sollte und wie man es tun kann.

Kurz zur Geschichte:
In der heutigen Zeit begegnet einem als Programmierer immer öfter Software, die sich aufgrund der stark gesunkenen Speicherpreise in keinster Weise mehr um Dinge wie Heap, Memory und Rechenleistung kümmern. Standardargument der meisten Programmierer : Ist ja eh genug Mem vorhanden .. da brauch ich mich heutzutage nicht mehr drum kümmern.

Stimmt das so ?
Nun ja .. das ist so ein Ding mit dem Speicher ... Theoretisch hat der Entwickler schon recht.

ABER: Meistens vergessen die Entwickler dabei zwei wesentliche Dinge. Erstens bewegt man sich heutzutage meistens in multiuser/multitasking Umgebungen.
Das bedeutet : Ich teile meinen Applikationsspeicher mit anderen Applikationen und/oder Threads, ausserdem belaste ich den Garbage Collector der JVM (Java Virtuellen Maschine) .

Ein Segen von Java, nämlich die Objektorientierung, kann in kritischen Fällen hier zum echten Hund werden. Einerseits gepriesen und viel verwendet, kann andererseits die gefankenlose Verwendung von Objekten schnell zum echten Speicherfresser werden. So Objekte können nämlich bei schlechter Planung ganz schnell ganz groß werden, ohne das man das im Single-User Testfall zunächst bemerkt.

Aber ich will nun nicht zu weit ins theoretische abschweifen ... zurück zum Thema.

Was kann ich also tun:
Zunächst etwas sehr simples, die eigene Anwendung zur rechten Zeit korrekt beenden und somit der JVM
erlauben aufzuräumen. Konkret also dem Garbage Collector zu ermöglichen, benötigen Speicher von nicht mehr
benötigten Variablen, Objekten und so weiter freizuräumen.

Den korrekten Zeitpunkt, wann eine App. beendet werden kann sollte jeder Programmierer kennen. Grob dann, wenn
die App. alle Aufgaben erledigt hat und die Lifetime der Activity beendet ist.

Wie das korrekt geht:

Ganz einfach, an der oder den richtigen Stellen eines oder beides der folgenden Dinge tun:

1. Aufruf der Methode
Die Methode ist aus dem Paket android.app.Activity und propagiert das Ende der Activity an mögliche Aufrufer. Bestenfalls also an
das Betriebssystem selbst. Jedenfalls werden hiernach die benutzten Ressourcen finalisiert und freigegeben.

Es gibt auch noch Methoden um andere Activitys zu beenden, bzw. diese Events abzufragen. Darum soll es hier aber nicht gehen.

2. Zusätzlich kann man noch aufrufen.
Diese Methode aus dem Paket java.lang.System beendet relativ hart die momentane JVM und gibt Ressourcen wieder frei.
Ruft man vorher noch runFinalizersOnExit(true); auf, werden vor dem beenden der App. sämtliche Objekte hart vom
Garbage Collector erfasst, dereferenziert und finalisiert. Das sollte allerdings nur in echten Härtefällen
erfolgen, da ein Garbage Collector Lauf ein sogenanntes Dead Second bewirkt. Die Dead Second bedeutet nichts anderes
als das während des Garbage Collector Laufs die gesamte JVM STEHT weil nichts anderes mehr geht und NUR GC betrieben
wird. Dieser Prozess hat in jeder JVM TOP Priorität und kann in Härtefällen schon mal mehrere Minuten dauern.
Also VORSICHT mit dieser Option, auch wenn sie sicher alles wegputzt.

Also Leute .. finish(); und System.exit(0); tun nicht weh, das geht sogar in EINER ZEILE ... ;)

Warum ist das auf Systemen wie dem Android so wichtig?

Garbage Collection bedeutet CPU Zeit, Cpu Zeit = AkkuLeistung und AKKU .. hamma wenig
Wenig Speicher bedeutet mehr Garbage Collection, mehr Garbage Collection mehr CPU ... usw.

Ihr seht, dass sich soetwas sehr schnell aufschaukeln kann. Also denkt auch an Euer Android
und den armen Akku. Aber vor allem an die User die sich ärgern warum das Ding wieder mal
so elendiglich langsam geworden ist. Es liegt (vielleicht) auch mit an Euch ;)

In diesem Sinne, happy coding.

Nächstes Mal beschreibe ich dann wie man völlig simple mal nen Quit Menü in seine Apps einbauen
kann. Bis dahin ..

lg
voss

Danke Kevin,

aber sagt doch einfach Jörg ..

lg
Voss

Ok Sir Kevin

Um zum Thema zurückzukommen



lg
Voss

— geändert am 21.06.2009, 17:59:45

Auf dem G1 läuft die sogn. Dalvik VM die gemeinsam mit dem darunterliegenden Linux-Kernel
so ausgelegt wurde, dass jede Applikation in einer eigenen VM-Instanz, bzw. einem eigenständigen
Linux Prozess läuft.
Diese VM, der Applikation wird mit einem system.exit(0) beendet, nichts anderes. Dabei werden
natürlich auch alle, wirklich alle Threads die mit dieser Applikation verknüpft sind, hart beendet.

Sollte eine Applikation derartige asynchrone Threads laufen haben muss man sich natürlich darum
kümmern diese vorher sauber zu beenden. Das finish() beendet lediglich die aktuelle Activity und die
mit ihr verbundenen laufenden Aktivitäten. Nicht unbedingt Threads die noch laufen und dann vielleicht
später noch nicht freigegebene Referenzen auf dem Stack hinterlassen.

Jedenfalls werden keinerlei andere VMs von dem in Deiner VM aufgerufenen system.exit() beeinflusst.

System.exit ist aus der java.lang.system und das ist dokumentiert, unter anderem, in der Android Developer
referenz unter: http://d.android.com/reference/java/lang/System.html#exit(int)

system.exit(0) geht absolut sicher, dass wirklich alles aufgeräumt wird durch den GC.
Das ist bei einem finish() nicht immer so unbedingt gesichert. Je nach Code implementierung eben.

voss

Keine Ahnung,

ich würde aber vermuten, dass die mit system.exit() ebenfalls gekillt werden.

voss

Hallo Abraxas,

natürlich nicht jede Applikation da gebe ich Dir völlig Recht
... theoretisch zumindest aber dazu gleich mehr.

Der Entwickler einer Applikation muss ja den Lebenszyklus seiner Anwendung genau
kennen. Nicht jede Anwendung arbeitet nun mit Threads und Hintergrundausführung.
Bspw. hab ich eine kleine App. geschrieben die nix anderes tut, als Wlan ein oder
auszuschalten. Die braucht theoretisch nicht mal ne View, weil sie über einen view-unabhängigen
Toast nur eine kurze Bestätigung dessen ausgibt was sie nun gemacht hat.
Die wird sofort nach Ausführung wieder korrekt beendet und dümpelt nicht länger
im Speicher herum.

Schreibe ich nun aber eine Applikation die auf SystemBroadcasts reagiert oder eine Api
für andere Applikationen bereitstellt, dann muss ich mir ggf. sehr wohl Gedanken darum
machen ob überhaupt und wann ich eine Applikation wie beende. Gebe ich dem Benutzer die Möglichkeit
über einen Quit Button, mache ich das von einem Systemzustand abhängig, oder gar von der
Anwesenheit anderer Applikationen im Prozesskontext, oder oder oder.

Ich wurde bis jetzt mangels entsprechender Herausforderung noch nicht direkt mit dem
LifeCycle Konzept von Android konfrontiert, werde aber jetzt wohl daran gehen müssen
dieses näher zu ergründen weil ich so einen Background task benötigen werde.
Ich werd dann mal berichten was ich mir da so zu ausgedacht habe.

Das mit der Backtaste .. ist sicherlich auch Teil des gesamten Android LifCycle
Managements. Hier kommen die Funktionen onDestroy onPause onRestart und wie sie
heissen ins Spiel. Diese sollten in einem vernünftigen APplikationsdesign sicherlich
eingang finden und sind wichtig für die User-Experience beim Erleben der Anwendung.
Im Android kann eine Applikation ja auch jederzeit vom System beendet werden, wenn
der Speicherplatz ausgeht. Um so wichtiger ist das also.

Beende ich meinen Applikationstask, und kümmere mich um korrekte Rückgabewerte,
dann beende ich wirklich nur meinen eigenen Kontext. Das andere muss die aufrufende
App. erledigen. Hier muss der onResume Zweig korrekt implementiert sein.

Beende ich eine Applikation mit finish() wird ja das Activity Result vom System
automatisch an ggf. meine Activity aufrufende Intents an den onActivityResult Handler
zurückpropagiert. Hierfür gibt es auch die Methode setResult() die eben diese Parameter
setzt.

Alles in allem denke ich und weiss aus Beruflicher Erfahrung, dass Applikationsdesign
kein einfaches Geschäft ist und sich hinter einer vermeintlich einfachen Anwendung
viele Detailfragen verbergen, die zunächst oft ausser Acht gelassen werden und erst
viel zu spät im Entwicklungsprozess aufpoppen. Dann ist es jedoch oft aus Kostengründen
kaum noch möglich, dass App. Design noch auf die richtige Schiene zu bringen und man
beginnt sich mit Workarounds zu behelfen, die einem das Leben richtig schwer machen
und der Experience der Applikation nicht wirklich förderlich sind.

Ich hab ja auch geschrieben, dass dieser öffnende Thread erst der Anfang wäre. Ich denke
dass wir gerade mit kritischen Anmerkungen wie jetzt von Dir, oder wie von MacSystems
alle gemeinsam die Möglichkeit haben viel voneinander zu lernen und unserer Erfahrungen
und bereits erlebten Fussfallen auszutauschen.

Ich für meinen Teil finde es jedenfalls ungemein hilfreich mit Euch über diese Dinge
diskutieren zu können und sich auszutauschen.

lg
Voss

*Handschüttel*

Die tun sich aber auch leichter es "anders" zu machen Markus.

Da gibt es genügend Beispiele.

Der HomeButton ist als einziger HardwareButton offiziell nicht abzufangen,
an gewisse Phone Funktionen, wie bspw. das Auflegen kommt man nicht heran,

Wie ich in den letzten Tagen feststellen konnte, werden sehr wohl einige Applikationen von Google
korrekt beendet, ohne dabei jedoch einen offiziellen Quit Button anzubieten.

Die Applikationen wie bspw. Google Maps dümpeln nach dem drücken auf den Homebutton noch kurz als IDLE auf der Applications-Liste umeinander nachdem sie vorher ForeGround oder BackGround Status hatten.

Das passiert in dieser Geschwindigkeit nur dann wenn der GarbageCollector (der zu dieser Zeit keine Speicher freischaufeln muss weil genügend da ist) die Objekte finalisieren kann.

Das bedeutet aber, dass automatisch bei bestimmten Stati der App. an bestimmten Stellen oder Laufzeitpunkten einfach ein finish eingebaut wurde.

Ich für meinen Teil finde es allerdings eher ungut, weil damit die Kontrolle über diese Dinge dem Anwender entzogen wird. Wehtun würde es bei den meisten Apps jedenfalls nicht.

Alles nur dem GC zu überlassen der "IRGENDWANN" aufräumt .. (selbst wenn man Ihn explizit aufruft) ist keine best Practice .. gerade wenn man bedenkt das darunter unter Umständen andere Applikationen und auch die Akkulebenszeit leiden muss.

Jeder der sich mal längere Zeit mit Profiling von Applikationen in Multiuser/Multitaskingumgebungen befasst hat, wird das bestätigen können.

Das mit dem "besser oder richtig machen" sehe ich in sofern nicht unbedingt als ein valides Argument an.
Die Googelianer haben einfach andere Möglichkeiten, oder sagen wir einfachere Möglichkeiten an gewisse Dinge heranzukommen. Wenn ein Programmierer oder ein Team etwas macht, muss es nicht heißen das man es nicht anders auch machen könnte. Vielleicht sogar besser ;)

Vielleicht hab ich letzteres aber auch schon einfach zu oft erlebt ..

lg
Voss