Verschiedene Ereignisse, einige vom Nutzer und einige vom System ausgelöst, können dazu führen, dass ein
Activity von einem Status in einen anderen übergeht. In diesem Dokument werden einige häufige Fälle beschrieben, in denen solche Übergänge auftreten, und wie Sie damit umgehen.
Weitere Informationen zu Aktivitätsstatus finden Sie unter Der Aktivitätslebenszyklus. Informationen dazu, wie Sie mit der Klasse ViewModel den Lebenszyklus von Aktivitäten
verwalten können, finden Sie in der Übersicht zu ViewModel.
Bei den meisten Aktivitätsänderungen müssen Sie nicht direkt auf Callbacks im Aktivitätslebenszyklus reagieren. Da Compose Benutzeroberflächen aus dem Status neu erstellt, können Sie die
automatische Neuzusammensetzung nutzen, indem Sie den Status an einem
geeigneten Ort speichern, z. B. in rememberSaveable oder ViewModel.
Konfigurationsänderung
Es gibt eine Reihe von Ereignissen, die eine Konfigurationsänderung auslösen können. Das vielleicht bekannteste Beispiel ist der Wechsel zwischen Hoch- und Querformat. Weitere Fälle, die zu Konfigurationsänderungen führen können, sind Änderungen an den Spracheinstellungen oder am Eingabegerät.
Wenn eine Konfigurationsänderung auftritt, wird die Aktivität zerstört und neu erstellt. Dadurch werden die folgenden Callbacks in der ursprünglichen Aktivitätsinstanz ausgelöst:
Eine neue Instanz der Aktivität wird erstellt und die folgenden Callbacks werden ausgelöst:
In Compose ist es nicht üblich, direkt mit diesen Callbacks zu interagieren. Verwenden Sie stattdessen die Lifecycle API, um Statusänderungen zu beobachten. In Compose können Sie LocalLifecycleOwner.current verwenden, um den aktuellen Lebenszyklus abzurufen und einen Beobachter hinzuzufügen, damit Sie auf Ereignisse reagieren können.
Verwenden Sie eine Kombination aus ViewModel-Instanzen, rememberSaveable oder persistentem lokalen Speicher, um den UI-Status einer Aktivität bei Konfigurationsänderungen beizubehalten.
Wie Sie diese Optionen kombinieren, hängt von der Komplexität Ihrer UI-Daten, den Anwendungsfällen für Ihre App und der Abwägung zwischen Abrufgeschwindigkeit und Arbeitsspeichernutzung ab. In den meisten Anwendungsfällen sollten Sie den Status in ein ViewModel verschieben und rememberSaveable verwenden, um sicherzustellen, dass der Status sowohl bei Konfigurationsänderungen als auch bei vom System initiierten Prozessbeendigungen beibehalten wird. Weitere Informationen zum Speichern
des UI-Status Ihrer Aktivität finden Sie unter UI-Status speichern.
Wenn eine Aktivität aufgrund einer Konfigurationsänderung neu erstellt wird, wird die ursprüngliche Zusammensetzung verworfen. Durch die Verwendung von ViewModel oder rememberSaveable wird der UI-Status in der neuen Zusammensetzung wiederhergestellt.
Weitere Informationen finden Sie unter Lebenszyklus in Jetpack Compose und Status und Jetpack Compose.
Fälle im Mehrfenstermodus verarbeiten
Wenn eine App in den Mehrfenstermodus wechselt, der in Android 7.0 (API-Level 24) und höher verfügbar ist, benachrichtigt das System die ausgeführte Aktivität über eine Konfigurationsänderung. Dadurch werden die zuvor beschriebenen Lebenszyklusübergänge durchlaufen.
Dieses Verhalten tritt auch auf, wenn die Größe einer App geändert wird, die sich bereits im Mehrfenstermodus befindet. Ihre Aktivität kann die Konfigurationsänderung selbst verarbeiten oder das System die Aktivität zerstören und mit den neuen Abmessungen neu erstellen lassen.
Weitere Informationen zum Lebenszyklus im Mehrfenstermodus finden Sie in der Erläuterung des Lebenszyklus im Mehrfenstermodus unter Mehrfenstermodus unterstützen.
Im Mehrfenstermodus sind zwar zwei Apps für den Nutzer sichtbar, aber nur die App, mit der der Nutzer interagiert, befindet sich im Vordergrund und hat den Fokus. Diese Aktivität befindet sich im Status „Wieder aufgenommen“, während sich die App im anderen Fenster im Status „Pausiert“ befindet.
Wenn der Nutzer von App A zu App B wechselt, ruft das System onPause für
App A und onResume für App B auf. Es wechselt zwischen diesen beiden Methoden, wenn der Nutzer zwischen den Apps wechselt.
Weitere Informationen zum Mehrfenstermodus finden Sie unter Mehrfenstermodus unterstützen.
Aktivität oder Dialogfeld im Vordergrund
Wenn eine neue Aktivität oder ein neues Dialogfeld im Vordergrund angezeigt wird, den Fokus übernimmt und die ausgeführte Aktivität teilweise verdeckt, verliert die verdeckte Aktivität den Fokus und wechselt in den Status „Pausiert“. Anschließend ruft das System onPause für sie auf.
Wenn die verdeckte Aktivität wieder in den Vordergrund zurückkehrt und den Fokus wiedererlangt, ruft das
System onResume auf.
Wenn eine neue Aktivität oder ein neues Dialogfeld im Vordergrund angezeigt wird, den Fokus übernimmt und die ausgeführte Aktivität vollständig verdeckt, verliert die verdeckte Aktivität den Fokus und wechselt in den Status „Beendet“. Das System ruft dann in schneller Folge
onPause und onStop auf.
Wenn dieselbe Instanz der verdeckten Aktivität wieder in den Vordergrund zurückkehrt, ruft das
System onRestart, onStart und onResume für die
Aktivität auf. Wenn eine neue Instanz der verdeckten Aktivität in den Hintergrund wechselt, ruft das System nicht onRestart, sondern nur onStart und onResume auf.
Die Neuzusammensetzung wird nicht durch Dialogfelder beeinflusst, die im Vordergrund angezeigt werden. Bei Nebeneffekten, die mit dem Lebenszyklus zusammenhängen, z. B. Flows und Animationen, sollten jedoch
APIs verwendet werden, die den Lebenszyklus berücksichtigen (z. B. collectAsStateWithLifecycle), um
die Arbeit bei Bedarf automatisch zu pausieren und fortzusetzen. Weitere Informationen finden Sie unter Status
und Jetpack Compose.
Nutzer tippt oder wischt auf „Zurück“
Wenn sich eine Aktivität im Vordergrund befindet und der Nutzer auf „Zurück“ tippt oder wischt, durchläuft die
Aktivität die onPause, onStop und
onDestroy Callbacks. Die Aktivität wird zerstört und aus dem Back-Stack entfernt.
In einer App mit einer einzelnen Aktivität, wie den meisten Compose-Apps, wird der Status von rememberSaveable nicht beibehalten, wenn die zusammensetzbare Funktion aus dem Back-Stack der Navigation entfernt wird. Wenn der Nutzer auf „Zurück“ tippt, wird nicht erwartet, dass er zur selben Instanz zurückkehrt. Daher wird der gesamte Status gelöscht.
Wenn Sie ein benutzerdefiniertes Verhalten für „Zurück“ implementieren möchten, z. B. ein Dialogfeld anzeigen, in dem der Nutzer bestätigen muss, dass er Ihre App beenden möchte, verwenden Sie die NavigationEventHandler API.
System beendet App-Prozess
Wenn sich eine App im Hintergrund befindet und das System Speicher für eine App im Vordergrund freigeben muss, kann das System die Hintergrund-App beenden. Wenn das System eine App beendet, wird onDestroy in der App nicht garantiert aufgerufen.
Weitere Informationen dazu, wie das System entscheidet, welche Prozesse beendet werden sollen, finden Sie unter Aktivitätsstatus und Entfernen aus dem Speicher und Prozesse und App Lebenszyklus.
Informationen zum Speichern des UI-Status Ihrer Aktivität, wenn das System den App- Prozess beendet, finden Sie unter Vorübergehenden UI-Status speichern und wiederherstellen.