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 Umstellungen erfolgen. Außerdem wird beschrieben, wie Sie diese Umstellungen handhaben können.
Weitere Informationen zu Aktivitätsstatus finden Sie unter Aktivitätslebenszyklus. Informationen dazu, wie Sie mit der Klasse ViewModel den Aktivitätslebenszyklus verwalten können, finden Sie in der ViewModel-Übersicht.
Konfigurationsänderung erfolgt
Es gibt eine Reihe von Ereignissen, die eine Konfigurationsänderung auslösen können. Das vielleicht auffälligste Beispiel ist der Wechsel zwischen Hoch- und Querformat. Andere Fälle, die zu Änderungen an der Konfiguration führen können, sind Änderungen der Spracheinstellungen oder des Eingabegeräts.
Bei einer Konfigurationsänderung wird die Aktivität gelöscht und neu erstellt. Dadurch werden in der ursprünglichen Aktivitätsinstanz die folgenden Callbacks ausgelöst:
Eine neue Instanz der Aktivität wird erstellt und die folgenden Callbacks werden ausgelöst:
Verwenden Sie eine Kombination aus ViewModel-Instanzen, der Methode onSaveInstanceState() oder nichtflüchtigen lokalen Speicher, um den UI-Status einer Aktivität auch bei Konfigurationsänderungen beizubehalten. Wie diese Optionen kombiniert werden sollten, hängt von der Komplexität der UI-Daten, den Anwendungsfällen für Ihre App und der Geschwindigkeit des Abrufs im Vergleich zur Arbeitsspeichernutzung ab. Weitere Informationen zum Speichern des Aktivitäts-UI-Status finden Sie unter UI-Status speichern.
Umgang mit Mehrfenstermodus
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 laufende Aktivität einer Konfigurationsänderung und durchläuft so die oben beschriebenen Lebenszyklusübergänge.
Dieses Verhalten tritt auch auf, wenn die Größe einer App, die sich bereits im Mehrfenstermodus befindet, geändert wird. Ihre Aktivität kann die Konfigurationsänderung selbst verarbeiten oder dem System ermöglichen, die Aktivität zu löschen und mit den neuen Dimensionen neu zu erstellen.
Weitere Informationen zum Mehrfensterlebenszyklus finden Sie in der Erläuterung zum Mehrfensterlebenszyklus auf der Seite Unterstützung des Mehrfenstermodus.
Im Mehrfenstermodus ist zwar zwei Apps für den Nutzer sichtbar, aber nur die App, mit der er interagiert, befindet sich im Vordergrund und ist fokussiert. Diese Aktivität befindet sich im Status „Fortsetzen“, während die App im anderen Fenster im Status „Pausiert“ ist.
Wenn der Nutzer von App A zu App B wechselt, ruft das System in App A onPause() und in App B onResume() auf. Jedes Mal, wenn der Nutzer zwischen Apps wechselt, wechselt er zwischen diesen beiden Methoden.
Weitere Informationen zum Mehrfenstermodus findest du unter Unterstützung des Mehrfenstermodus.
Aktivität oder Dialogfeld wird im Vordergrund angezeigt
Wenn eine neue Aktivität oder ein neues Dialogfeld im Vordergrund angezeigt wird und die laufende Aktivität teilweise teilweise verdeckt, verliert die abgedeckte Aktivität den Fokus und wechselt in den Status „Pausiert“. Dann ruft das System dafür onPause() auf.
Wenn die abgedeckte Aktivität in den Vordergrund und wieder fokussiert wird, ruft das System onResume() auf.
Wenn eine neue Aktivität oder ein neues Dialogfeld im Vordergrund angezeigt wird, der Fokus darauf gelegt wird und die laufende Aktivität vollständig abdeckt, verliert die abgedeckte Aktivität den Fokus und wechselt in den Status „Angehalten“. Das System ruft dann schnell nacheinander onPause() und onStop() auf.
Wenn dieselbe Instanz der abgedeckten Aktivität in den Vordergrund zurückkehrt, ruft das System für die Aktivität onRestart(), onStart() und onResume() auf. Wenn es sich um eine neue Instanz der abgedeckten Aktivität handelt, die in den Hintergrund tritt, ruft das System nicht onRestart() auf, sondern nur onStart() und onResume().
Nutzer tippt oder tippt auf „Zurück“
Wenn sich eine Aktivität im Vordergrund befindet und der Nutzer auf „Zurück“ tippt oder auf „Zurück“ tippt, geht die Aktivität durch die Callbacks onPause(), onStop() und onDestroy() über. Die Aktivität wird gelöscht und aus dem Back Stack entfernt.
Standardmäßig wird der onSaveInstanceState()-Callback in diesem Fall nicht ausgelöst. Bei diesem Verhalten wird davon ausgegangen, dass der Nutzer auf „Zurück“ tippt und nicht erwartet, zur selben Instanz der Aktivität zurückzukehren.
Sie können jedoch die Methode onBackPressed() überschreiben, um benutzerdefiniertes Verhalten zu implementieren, z. B. um ein Dialogfeld einzublenden, in dem der Nutzer aufgefordert wird, zu bestätigen, dass er die App beenden möchte.
Wenn Sie die Methode onBackPressed() überschreiben, empfehlen wir dringend, weiterhin super.onBackPressed() über die überschriebene Methode aufzurufen. Andernfalls könnte das Systembackverhalten für den Nutzer zu Störungen führen.
System beendet den App-Prozess
Wenn eine App im Hintergrund läuft und das System Arbeitsspeicher für eine App im Vordergrund freigeben muss, kann das System die Hintergrund-App beenden. Wenn das System eine App beendet, gibt es keine Garantie, dass onDestroy() in der App aufgerufen wird.
Weitere Informationen dazu, wie das System entscheidet, welche Prozesse gelöscht werden sollen, finden Sie unter Aktivitätsstatus und Ausschluss aus dem Arbeitsspeicher und Prozesse und Anwendungslebenszyklus.
Informationen zum Speichern des Aktivitäts-UI-Status nach dem Beenden des App-Prozesses durch das System finden Sie unter Vorübergehenden UI-Status speichern und wiederherstellen.