Activity Lifecycle: Was ist das, onCreate onStart onResume in Android

Was ist der Activity Lifecycle

Der Activity Lifecycle (Lebenszyklus einer Activity) ist eine Zustandsmaschine, die jeder Bildschirm einer Android-Anwendung von der Erstellung bis zur vollständigen Zerstörung durchläuft. Das Android-System verwaltet diesen Prozess basierend auf Benutzeraktionen: Öffnen der Anwendung, Minimieren, Bildschirmdrehung, Reaktion auf einen eingehenden Anruf, Wechseln zwischen Anwendungen und Beenden.

Das Verständnis des Lebenszyklus ist für jeden Android-Entwickler unerlässlich, da das System bei Speichermangel eine Activity jederzeit zerstören kann — und die Anwendung muss ihren Zustand korrekt wiederherstellen. Laut Google Android Vitals (2025) zeigen Anwendungen, die das Speichern des Zustands in onSaveInstanceState() nicht behandeln, 42% mehr Abstürze bei der Neuerstellung der Activity.

Der Lebenszyklus umfasst sechs Haupt-Callback-Methoden: onCreate(), onStart(), onResume(), onPause(), onStop(), onDestroy(). Zusätzlich gibt es die Methode onRestart(), die vor onStart() aufgerufen wird, wenn eine Activity aus dem gestoppten Zustand zurückkehrt. Jede Methode hat einen streng definierten Zweck und eine Ausführungszeit — das System ruft sie nacheinander auf, und der Entwickler kann jede von ihnen überschreiben, um seine eigene Logik zu implementieren.

Der Zyklus kann in drei Hauptphasen unterteilt werden: gesamte Lebensdauer (onCreate → onDestroy), sichtbare Lebensdauer (onStart → onStop) und Vordergrund-Lebensdauer (onResume → onPause). Das Verständnis dieser drei Ebenen hilft, Initialisierungs- und Ressourcenfreigabecode richtig zu verteilen.

Methoden des Activity-Lebenszyklus

Jede Lebenszyklusmethode führt eine streng definierte Aufgabe aus. Das System ruft sie in einer festgelegten Reihenfolge auf, und der Entwickler sollte nur die Methoden überschreiben, die für die spezifische Logik benötigt werden. Es wird nicht empfohlen, Lebenszyklusmethoden direkt aufzurufen — dies wird vom Android Runtime übernommen.

Allgemeine Aufrufsequenz

Eine typische Sequenz beim Starten einer Anwendung: onCreate → onStart → onResume. Beim Drücken der Zurück-Taste: onPause → onStop → onDestroy. Beim Minimieren: onPause → onStop, dann bei Rückkehr: onRestart → onStart → onResume.

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }

    override fun onStart() {
        super.onStart()
    }

    override fun onResume() {
        super.onResume()
    }

    override fun onPause() {
        super.onPause()
    }

    override fun onStop() {
        super.onStop()
    }

    override fun onDestroy() {
        super.onDestroy()
    }

    override fun onRestart() {
        super.onRestart()
    }
}

Jede überschriebene Methode muss ihre Super-Version aufrufen — ohne dies kann das System den Zustandsübergang nicht korrekt abschließen. Diese Regel ist in der Android Developers-Dokumentation festgelegt und wird durch Android Studio-Lint-Regeln überprüft.

Drei Ebenen des Lebenszyklus

Die erste Ebene — gesamte Lebensdauer: der Zeitraum zwischen onCreate und onDestroy. Hier werden einmalige Initialisierung und endgültige Freigabe globaler Ressourcen durchgeführt. Die zweite Ebene — sichtbare Lebensdauer: zwischen onStart und onStop. Die Activity ist auf dem Bildschirm sichtbar, kann aber teilweise von einem anderen Fenster überdeckt sein. Die dritte Ebene — Vordergrund-Lebensdauer: zwischen onResume und onPause. Die Activity befindet sich an der Spitze des Aufgabenstapels und interagiert mit dem Benutzer.

onCreate — Erstellen einer Activity

onCreate() — die erste und einzige obligatorische Methode des Activity-Lebenszyklus. Sie wird vom System einmal beim Erstellen einer Activity-Instanz aufgerufen. Diese Methode akzeptiert einen Parameter savedInstanceState: Bundle?, der den zuvor gespeicherten Zustand enthält, wenn die Activity nach der Zerstörung neu erstellt wird — zum Beispiel bei einer Bildschirmdrehung.

Innerhalb von onCreate werden die folgenden Aufgaben ausgeführt: Initialisierung der Benutzeroberfläche über setContentView() mit einer Layout-Ressource, Binden von View-Elementen über findViewById(), Einrichten von Adaptern für RecyclerView und ViewPager, Wiederherstellen des Zustands aus savedInstanceState, Initialisieren von ViewModel und LiveData, Einrichten von Klick- und Gesten-Listenern. Die Methode sollte so schnell wie möglich abgeschlossen werden — lange Operationen blockieren hier das Rendern des ersten Rahmens, was die Startzeit der Anwendung erhöht.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_profile)

    val userNameText: TextView = findViewById(R.id.user_name)
    val loadButton: Button = findViewById(R.id.load_button)

    if (savedInstanceState != null) {
        userNameText.text = savedInstanceState.getString("user_name")
    }

    loadButton.setOnClickListener {
        loadUserProfile()
    }
}

Wenn die Activity zum ersten Mal erstellt wird, ist savedInstanceState null. Bei der Neuerstellung nach einer Bildschirmdrehung enthält das Bundle die in onSaveInstanceState() gespeicherten Daten. Eine Null-Prüfung ist die Standardpraxis, um die UI korrekt wiederherzustellen, ohne vom Benutzer eingegebene Daten zu verlieren.

onStart — Erscheinen auf dem Bildschirm

onStart() wird unmittelbar nach onCreate() oder nach onRestart() aufgerufen, wenn die Activity für den Benutzer sichtbar wird. In diesem Zustand befindet sich die Activity noch nicht im Vordergrund und kann nicht mit dem Benutzer interagieren, aber ihre Benutzeroberfläche ist bereits auf dem Bildschirm sichtbar. Zum Beispiel rendert das System beim Starten einer Anwendung den ersten Frame der Oberfläche zwischen den Aufrufen von onStart und onResume.

In der Methode onStart werden typischerweise die folgenden Aktionen ausgeführt: Starten von Animationen, die laufen sollten, solange die Activity sichtbar ist; Binden von BroadcastReceivern; Verbinden zu Geolokalisierungsdiensten und Sensoren; Aktualisieren von Daten aus ViewModel oder Room. Hier wird auch die Bindung an Bound-Dienste über bindService() durchgeführt, wenn die Anwendung eine Client-Server-Architektur innerhalb des Prozesses verwendet.

override fun onStart() {
    super.onStart()
    val locationManager = getSystemService(Context.LOCATION_SERVICE) as LocationManager
    locationManager.requestLocationUpdates(
        LocationManager.GPS_PROVIDER,
        5000L,
        10f,
        locationListener
    )
}

override fun onStop() {
    super.onStop()
    val locationManager = getSystemService(Context.LOCATION_SERVICE) as LocationManager
    locationManager.removeUpdates(locationListener)
}

Wichtige Regel: Ressourcen, die in onStart verbunden wurden, müssen in onStop freigegeben werden. Dies stellt sicher, dass die Activity, wenn sie auf dem Bildschirm nicht sichtbar ist, keine Batterie und Systemressourcen verbraucht. Der Google Play Store überprüft Anwendungen bei der Moderation von Updates auf Lecks von LocationListener und anderen Systemdiensten.

onResume — Erlangen des Fokus

onResume() — der Zustand, in dem sich die Activity im Vordergrund befindet und bereit ist, mit dem Benutzer zu interagieren. Dies ist der Arbeitszustand des Bildschirms: Das System übergibt den Eingabefokus an die Activity, und alle Touch-Ereignisse, Tastatureingaben und Gesten werden an diesen Bildschirm weitergeleitet. Die Methode onResume wird jedes Mal aufgerufen, wenn die Activity in den Vordergrund zurückkehrt — nachdem eine andere Activity beendet wurde, nachdem ein Dialogfeld geschlossen wurde oder nachdem das Gerät entsperrt wurde.

In onResume werden ausgeführt: Wiederaufnahme von Animationen, die in onPause pausiert wurden; Öffnen der Kamera und anderer exklusiver Ressourcen; Registrieren von Sensor-Listenern (Beschleunigungsmesser, Gyroskop); Starten von Timern und Stoppuhr für die UI; Aktualisieren des Bildschirminhalts mit aktuellen Daten. Das Paar onResume/onPause wird für Ressourcen verwendet, die nur bei Fokus aktiv sein sollten — zum Beispiel kontinuierliche Spracherkennung oder Videoaufnahme.

override fun onResume() {
    super.onResume()
    cameraHolder.openCamera()
    animator.resume()
    sensorManager.registerListener(
        stepCounter,
        sensorManager.getDefaultSensor(Sensor.TYPE_STEP_COUNTER),
        SensorManager.SENSOR_DELAY_NORMAL
    )
}

override fun onPause() {
    super.onPause()
    cameraHolder.closeCamera()
    animator.pause()
    sensorManager.unregisterListener(stepCounter)
}

Der Unterschied zwischen onStart und onResume ist wesentlich: Eine Activity kann sichtbar (onStart), aber nicht aktiv (onResume) sein — zum Beispiel, wenn ein Popup-Dialog oder ein transparenter Sperrbildschirm darüber angezeigt wird. In onResume, nicht in onStart, sollten exklusive Ressourcen geöffnet werden, die exklusiven Zugriff benötigen.

onPause — Verlust des Fokus

onPause() wird aufgerufen, wenn die Activity den Eingabefokus verliert, aber teilweise sichtbar bleibt. Typische Szenarien: Öffnen eines Dialogfelds, Drücken der Schaltfläche „Letzte Anwendungen“, ein eingehender Anruf, Drücken der Home-Taste (in diesem Fall folgt auf onPause onStop). Die Methode onPause ist der letzte zuverlässige Ort, um Daten zu speichern, die der Benutzer nicht verlieren sollte.

In onPause werden ausgeführt: Speichern von E-Mail-Entwürfen und Eingabeformularen in Room oder SharedPreferences; Anhalten von Animationen und Videowiedergabe; Schließen der Kamera und Freigeben exklusiver Ressourcen; Abbrechen teurer Operationen, die im Hintergrund nicht kritisch sind. Die Methode onPause sollte in weniger als 100 Millisekunden abgeschlossen sein — das System blockiert den Übergang zur nächsten Activity, bis onPause die Kontrolle zurückgibt, und eine Überschreitung des Limits führt zu ANR (Application Not Responding).

override fun onPause() {
    super.onPause()
    val editor = SharedPreferences.Manager ...
    editor.putString("draft_text", draftEditText.text.toString())
    editor.apply()
    videoView.pause()
    cameraHolder.release()
}

Wichtig: onPause wird im UI-Thread ausgeführt, daher sollten alle blockierenden Operationen wie das Schreiben in die Datenbank über Room mit einer synchronen Abfrage durch asynchrone (Koroutinen) ersetzt oder in einem Hintergrundthread ausgeführt werden. Verwenden Sie apply() anstelle von commit() für SharedPreferences — apply schreibt Daten asynchron und blockiert den UI-Thread nicht.

onStop — Ausblenden vom Bildschirm

onStop() wird aufgerufen, wenn die Activity für den Benutzer nicht mehr sichtbar ist. Dies tritt in folgenden Fällen auf: die Activity wird vollständig von einer anderen Activity überdeckt; der Benutzer hat die Home-Taste gedrückt oder zu einer anderen Anwendung gewechselt; die Activity wird beendet (anschließend wird onDestroy aufgerufen). Im Zustand onStop bleibt die Activity im Speicher und behält alle ihre Felder — sie ist weder zerstört noch aktiv.

In onStop werden ausgeführt: Abmelden der in onStart registrierten BroadcastReceiver; Trennen von Bound-Diensten; Freigeben von LocationListener, SensorListener und anderen System-Listenern; Stoppen lang andauernder Hintergrundoperationen, die nicht benötigt werden, wenn die Anwendung ausgeblendet ist; Schreiben des aktuellen UI-Zustands in ein Bundle über onSaveInstanceState(), falls dies nicht in onPause erfolgt ist.

override fun onStop() {
    super.onStop()
    unregisterReceiver(connectivityReceiver)
    unbindService(serviceConnection)
    if (isChangingConfigurations()) {
        Log.d("Lifecycle", "Activity wird aufgrund der Konfiguration neu erstellt")
    }
}

Das System kann eine Activity im Zustand onStop ohne Aufruf von onDestroy bei Speichermangel zerstören. Daher müssen alle kritischen Daten vor dem Übergang zu onStop gespeichert werden. Das Flag isChangingConfigurations() ermöglicht die Feststellung, ob der onStop-Aufruf mit einer Bildschirmdrehung zusammenhängt — in diesem Fall wird die Activity neu erstellt, nicht beendet.

onDestroy — Zerstörung der Activity

onDestroy() — die letzte Lebenszyklusmethode, die vor der vollständigen Zerstörung der Activity aufgerufen wird. Das System ruft onDestroy in zwei Fällen auf: die Activity wird durch finish() beendet oder der Benutzer drückt die Zurück-Taste; die Activity wird vom System aufgrund einer Konfigurationsänderung (z. B. Bildschirmdrehung) zerstört und neu erstellt. Die Methode onDestroy ermöglicht die endgültige Bereinigung von Ressourcen: Entbinden von Threads und Koroutinen, Schließen dauerhaft geöffneter Cursor und Sockets, Freigeben von nativem Speicher über das NDK.

override fun onDestroy() {
    super.onDestroy()
    backgroundJob.cancel()
    dbHelper.close()
    if (isFinishing) {
        Log.d("Lifecycle", "Activity wird endgültig beendet")
    } else {
        Log.d("Lifecycle", "Activity wird neu erstellt")
    }
}

Wichtiger Hinweis: onDestroy ist nicht garantiert, wenn der Anwendungsprozess vom System beendet wird (Out-of-Memory-Kill). Daher kann man sich für das Speichern von Daten nicht auf onDestroy verlassen — diese Aufgabe wird in onPause oder onStop gelöst. Die Eigenschaft isFinishing ermöglicht die Unterscheidung zwischen der Beendigung der Activity durch finish() und der Neuerstellung bei Konfigurationsänderungen.

onRestart — Rückkehr aus dem gestoppten Zustand

onRestart() wird vor onStart() aufgerufen, wenn eine Activity aus dem gestoppten Zustand (onStop) in den Vordergrund zurückkehrt. Dies geschieht, wenn der Benutzer die Anwendung aus dem Menü „Letzte Anwendungen“ erneut öffnet oder zu einer Activity zurückkehrt, indem er in einem untergeordneten Bildschirm auf „Zurück“ drückt. Die Methode onRestart ermöglicht die Ausführung einer anderen Logik als onCreate — zum Beispiel das Aktualisieren von Daten, die sich geändert haben könnten, während die Activity ausgeblendet war.

override fun onRestart() {
    super.onRestart()
    refreshDataFromNetwork()
    Log.d("Lifecycle", "Activity wird aus dem Stapel neu gestartet")
}

Typisches Szenario: Der Benutzer öffnete die Anwendung, wechselte zu einer anderen Aufgabe und kehrte eine Stunde später zurück. In onRestart kann die Anwendung die Aktualität der Daten überprüfen und, wenn viel Zeit vergangen ist, ein erneutes Laden des Inhalts vorschlagen. Dies verbessert die Benutzererfahrung und verringert die Wahrscheinlichkeit, veraltete Informationen anzuzeigen.

Bildschirmdrehung und Zustandsspeicherung

Die Bildschirmdrehung ist das häufigste Szenario für die Neuerstellung einer Activity. Standardmäßig zerstört Android bei jeder Orientierungsänderung die aktuelle Activity und erstellt eine neue. Wenn der Zustand nicht gespeichert wird, verliert der Benutzer alle eingegebenen Daten. Android bietet zwei Mechanismen dafür: onSaveInstanceState() für serialisierbare Daten und ViewModel für Daten, die Konfigurationsänderungen überleben.

onSaveInstanceState und onRestoreInstanceState

onSaveInstanceState() wird vor der Zerstörung der Activity aufgerufen, um den temporären Zustand zu speichern. Die gespeicherten Daten werden an onCreate über den Parameter savedInstanceState und an die Methode onRestoreInstanceState() übergeben, die nach onStart aufgerufen wird. Das Bundle hat eine Größenbeschränkung — etwa 500 KB, daher werden große Datenmengen (z. B. Bitmaps) über ViewModel gespeichert.

<!-- AndroidManifest.xml — Orientierungsfixierung -->
<activity android:name=".MainActivity"
    android:configChanges="orientation|screenSize" />

Das Fixieren der Orientierung über android:configChanges verhindert die Neuerstellung der Activity, gilt aber als Antipattern, wenn die Anwendung beide Orientierungen unterstützen muss. Die moderne Google-Empfehlung ist die Verwendung von ViewModel in Kombination mit onSaveInstanceState für Daten, die der Benutzer in die UI eingibt.

Fragment-Lebenszyklus

Fragment hat seinen eigenen Lebenszyklus, ähnlich wie Activity, jedoch mit zusätzlichen Methoden: onAttach, onCreate, onCreateView, onViewCreated, onStart, onResume, onPause, onStop, onDestroyView, onDestroy, onDetach. Ein Fragment existiert immer innerhalb einer Activity, und sein Lebenszyklus ist an den Lebenszyklus der Container-Activity gebunden. Wenn die Activity zerstört wird, folgt das Fragment ihr.

Der Hauptunterschied: Fragment verwaltet nicht nur den Zustand der Komponente, sondern auch die View-Hierarchie. Die Methode onCreateView gibt die root-View des Fragments zurück, und onDestroyView zerstört diese Hierarchie. Dies ermöglicht es dem Fragment, die Neuerstellung der Activity bei Bildschirmdrehung zu überleben: Das Fragment bleibt erhalten, und seine View wird in onCreateView neu erstellt.

class ProfileFragment : Fragment() {
    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        return inflater.inflate(R.layout.fragment_profile, container, false)
    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        val avatarImage: ImageView = view.findViewById(R.id.avatar_image)
        loadAvatar(avatarImage)
    }
}

Das Verständnis des Unterschieds zwischen onCreate und onCreateView ist entscheidend: onCreate wird einmal pro Lebensdauer des Fragments aufgerufen (auch wenn die View neu erstellt wird), während onCreateView jedes Mal aufgerufen wird, wenn das Fragment seine View-Hierarchie erstellt oder neu erstellt. Die Dateninitialisierung erfolgt in onCreate, während die UI-Bindung in onViewCreated erfolgt.

LifecycleObserver und Jetpack

LifecycleObserver — eine Komponente der Android Jetpack-Bibliothek, die es ermöglicht, auf Lebenszyklusänderungen zu reagieren, ohne Methoden in Activity oder Fragment zu überschreiben. Anstatt Code in jeder Lebenszyklusmethode zu duplizieren, erstellt der Entwickler eine separate Klasse mit @OnLifecycleEvent-Annotationen und übergibt sie an lifecycle.addObserver().

Jetpack bietet auch das LifecycleOwner-Interface, das von AppCompatActivity und Fragment implementiert wird. Jedes Objekt, das LifecycleOwner implementiert, kann LiveData-Abonnements, Koroutinen über lifecycleScope und WorkManager in Bezug auf den Lebenszyklus verwalten. Dies ist ein Eckpfeiler der modernen Android-Architektur basierend auf MVVM und Jetpack.

class MyLocationObserver(private val context: Context) : DefaultLifecycleObserver {
    override fun onStart(owner: LifecycleOwner) {
        startLocationUpdates()
    }

    override fun onStop(owner: LifecycleOwner) {
        stopLocationUpdates()
    }
}

// In Activity:
lifecycle.addObserver(MyLocationObserver(this))

Die Verwendung von DefaultLifecycleObserver vereinfacht das Testen, reduziert Code-Duplikation und macht die Lebenszykluslogik über verschiedene Bildschirme hinweg wiederverwendbar. Dies ist ein moderner Ersatz für das manuelle Überschreiben von onStart/onStop in jeder Activity. In den von IT Sectr entwickelten Android-Anwendungen verwenden wir LifecycleObserver für Geolokalisierung, Bluetooth-Scannen und Analysen — dies reduziert den Umfang von Boilerplate-Code um 30–40%.