onRestart — Wiederherstellung von Activity im Lebenszyklus

onRestart — das Wesen der Methode im Android-Lebenszyklus

onRestart — eine Callback-Methode, die Android strikt vor onStart aufruft, wenn eine Activity aus dem unsichtbaren Zustand Stopped zurück in den sichtbaren Zustand zurückkehrt. Diese Methode ist einzigartig, da sie nur aufgerufen wird, wenn die Activity erneut angezeigt wird — bei der ersten Erstellung der Instanz beginnt die Sequenz mit onCreate und überspringt onRestart. Der vollständige Zyklus: onCreate → onStart → onResume (erster Start) oder onRestart → onStart → onResume (erneute Anzeige).

Aus Sicht des Android-Systems ist onRestart eine Optimierung, die es der Activity ermöglicht, sich auf ihre Rückkehr vorzubereiten: Daten aus dem Repository aktualisieren, UI-Zustand synchronisieren, Netzwerkkonnektivität prüfen. Im Gegensatz zu onResume, das jedes Mal aufgerufen wird, wenn die Activity den Fokus erhält (auch bei Rückkehr aus einem Dialog oder Systemmenü), wird onRestart nur während eines vollständigen Ausblend- und Rückkehrzyklus ausgelöst. Dies macht onRestart zum idealen Ort für „schwere“ Aktualisierungsvorgänge, die bei teilweisem Fokusverlust nicht erforderlich sind.

Gemäß der Spezifikation des Android Activity-Lebenszyklus kann das Zeitintervall zwischen onStop und onRestart von einigen Sekunden (der Benutzer hat schnell gewechselt) bis zu mehreren Stunden (die App war im Hintergrund und der Benutzer kehrte zurück) reichen. Während dieser Zeit könnten sich Daten in einer entfernten Quelle (API, DB) geändert haben, daher ist onRestart ein natürlicher Punkt, um die Aktualität zu prüfen.

Wann onRestart aufgerufen wird: Bedingungen und Reihenfolge

onRestart wird nur aufgerufen, wenn eine Activity aus dem Zustand Stopped zurückkehrt, in den die Activity eingetreten ist, nachdem onStop aufgerufen wurde. Nachfolgend sind alle Szenarien aufgeführt, die zu onRestart führen.

Aufrufszenarien von onRestart:

• Rückkehr von einer anderen Activity — der Benutzer hat eine neue Activity geöffnet (z. B. auf eine Benachrichtigung getippt) und dann zurück navigiert („Zurück“ gedrückt). Stack: MainActivity.onPause → MainActivity.onStop → SecondActivity wird erstellt → Benutzer drückt „Zurück“ → SecondActivity.onPause → SecondActivity.onStop → SecondActivity.onDestroy → MainActivity.onRestart → MainActivity.onStart → MainActivity.onResume.
• Rückkehr aus der Minimierung — der Benutzer hat die App minimiert (Home) und ist nach einiger Zeit zurückgekehrt. CurrentActivity.onPause → CurrentActivity.onStop → (App im Hintergrund) → Benutzer kehrt zurück → CurrentActivity.onRestart → CurrentActivity.onStart → CurrentActivity.onResume.
• Rückkehr vom Sperrbildschirm — der Sperrbildschirm überlagert die Activity; nach dem Entsperren erhält die Activity onRestart, wenn eine erhebliche Zeit vergangen ist (mehr als 5 Sekunden).
• Rückkehr von einer über Intent gestarteten App — Kamera, Galerie, Browser — jede Drittanbieter-App, die über startActivityForResult() oder ActivityResultLauncher gestartet wurde.

Wann onRestart NICHT aufgerufen wird: bei Bildschirmdrehung (die Activity wird zerstört und über onCreate neu erstellt), bei Rückkehr aus einem Dialogfeld (die Activity geht nicht in onStop, nur onPause → onResume), bei Prozessabbruch (die Activity wird neu erstellt).

onRestart vs onCreate: Was wählen

onRestart und onCreate sind zwei verschiedene Ansätze zur Wiederherstellung einer Activity. Die Wahl zwischen ihnen hängt davon ab, ob die Activity vollständig zerstört oder nur versteckt wurde.

Auswahlregel: Führen Sie die View-Initialisierung und das LiveData/StateFlow-Abonnement in onCreate durch (oder onViewCreated für Fragment). Datenaktualisierungen, Listen-Neuladen und Zustandsprüfungen — in onRestart. Wenn Daten über ViewModel geladen werden, kann onRestart einfach die refresh()-Methode auf dem ViewModel aufrufen, und die View abonniert die aktualisierten Daten über einen reaktiven Stream.

Google empfiehlt: duplizieren Sie die onCreate-Logik nicht in onRestart. Extrahieren Sie refresh()-Methoden in ViewModel, die aktuelle Daten laden, und rufen Sie sie in onRestart auf. Dies bewahrt eine saubere MVVM-Architektur und eliminiert Code-Duplikation.

Anwendungsfälle von onRestart: Daten- und UI-Aktualisierung

onRestart ist der ideale Ort für Vorgänge, die jedes Mal bei der Rückkehr zum Bildschirm ausgeführt werden sollten, aber beim ersten Öffnen nicht benötigt werden. Hier sind typische Szenarien:

• Liste aus DB oder API aktualisieren — der Benutzer ging zu einer anderen Activity, änderte dort Daten, kam zurück — die Liste sollte aktuell sein. Rufen Sie viewModel.refreshItems() in onRestart auf.
• Autorisierungsprüfung — wenn die Activity längere Zeit versteckt war, könnte das Zugriffstoken abgelaufen sein. onRestart ist der Punkt, um die Token-Gültigkeit zu prüfen und zum Anmeldebildschirm umzuleiten.
• UI-Zustandssynchronisation — Themenwechsel, Sprachänderung, Aktualisierung der Einstellungen — Änderungen sollten bei Rückkehr zum Bildschirm übernommen werden.
• Medien-Neuladen — wenn die Activity Inhalte anzeigt, die sich geändert haben könnten (Nachrichtenfeed, Wechselkurse, Wetter), aktualisieren Sie die Daten in onRestart.
• Netzwerkkonnektivitätsprüfung — bei Rückkehr aus dem Offline-Modus sollte die Activity die Netzwerkverfügbarkeit prüfen und die UI umschalten.
• Animationswiederherstellung — in onStop freigegebene Animationen sollten in onRestart vor onStart neu gestartet werden.

Was in onRestart NICHT zu tun ist: Views nicht neu initialisieren — sie sind lebendig, da die Activity nicht zerstört wurde. LiveData nicht erneut abonnieren — das Abonnement in onCreate ist noch aktiv. Keine neuen Fragments erstellen — sie befinden sich bereits im FragmentManager.

onRestart und Prozessabbruch: eine wichtige Ausnahme

Die wichtigste Ausnahme: onRestart wird nicht aufgerufen, wenn der App-Prozess vom System beendet wurde. Dies ist ein entscheidender Punkt, den Entwickler oft übersehen, wenn sie sich bei der Zustandswiederherstellung auf onRestart verlassen.

Beim Prozessabbruch:

• Die App war im Hintergrund, Android hat den Prozess beendet, um Speicher freizugeben.
• Der Benutzer kehrt zurück — das System startet einen neuen Prozess.
• Die Activity wird neu erstellt: onCreate(Bundle) → onStart → onResume.
• onRestart wird NICHT aufgerufen — für das System ist dies eine neue Activity-Instanz.

Wie man sich dagegen schützt: Speichern Sie kritische Zustände immer in onSaveInstanceState(Bundle) (wird vor onStop aufgerufen) oder verwenden Sie SavedStateHandle in ViewModel. Überprüfen Sie in onCreate savedInstanceState: wenn es nicht null ist, stellen Sie den Zustand aus Bundle wieder her; wenn es null ist, laden Sie frische Daten.

Laut Google Android Vitals erfolgen etwa 7% der Rückkehr zu einer Activity nach längerer Zeit im Hintergrund nach einem Prozessabbruch. Das bedeutet, dass jede 15. Activity, die onRestart hätte aufrufen sollen, tatsächlich durch onCreate geht. Das Ignorieren dieses Szenarios ist eine der Hauptursachen für „leerer Bildschirm nach Rückkehr“-Fehler.

Codebeispiele mit onRestart in Kotlin

Beispiel 1: onRestart mit Listenaktualisierung über ViewModel

Die Activity ruft viewModel.refreshTasks() in onRestart auf, um die Aufgabenliste nach der Rückkehr vom Bearbeitungsbildschirm zu aktualisieren.

class TaskListActivity : AppCompatActivity() {
    private val viewModel: TaskViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_task_list)
        viewModel.tasks.observe(this) { tasks ->
            Log.d("TaskList", "${tasks.size} Aufgaben erhalten")
        }
    }

    override fun onRestart() {
        super.onRestart()
        Log.d("TaskList", "onRestart: Aufgabenliste wird aktualisiert")
        viewModel.refreshTasks()
    }
}

class TaskViewModel : ViewModel() {
    private val _tasks = MutableLiveData<List<Task>>()
    val tasks: LiveData<List<Task>> get() = _tasks

    fun refreshTasks() {
        viewModelScope.launch {
            _tasks.value = TaskRepository().getAllTasks()
        }
    }
}

ViewModel.refreshTasks() lädt aktuelle Daten aus dem Repository. LiveData benachrichtigt die Activity automatisch über Datenänderungen — die UI wird ohne zusätzlichen Code aktualisiert. onRestart erstellt kein neues Abonnement — es wurde bereits in onCreate eingerichtet.

Beispiel 2: onRestart mit Autorisierungsprüfung

Die Activity prüft die Token-Gültigkeit bei der Rückkehr und leitet bei Bedarf zur Anmeldung weiter.

class ProfileActivity : AppCompatActivity() {
    private val authManager = AuthManager()
    private val launcher = registerForActivityResult(
        ActivityResultContracts.StartActivityForResult()
    ) { Log.d("Profile", "Vom Anmeldebildschirm zurückgekehrt") }

    override fun onRestart() {
        super.onRestart()
        if (!authManager.isTokenValid()) {
            Log.d("Profile", "Token abgelaufen — Weiterleitung zur Anmeldung")
            launcher.launch(Intent(this, LoginActivity::class.java))
        }
    }
}

class AuthManager {
    fun isTokenValid(): Boolean {
        val expiry = SharedPreferencesManager().getTokenExpiry()
        return System.currentTimeMillis() < expiry
    }
}

Wenn der Benutzer die App für längere Zeit minimiert hat und nach Ablauf des Tokens zurückgekehrt ist, leitet onRestart ihn zum Anmeldebildschirm weiter. Dies verhindert API-Fehler beim Versuch, eine Anfrage mit einem abgelaufenen Token durchzuführen. Hinweis: Die Prüfung erfolgt in onRestart, nicht in onResume, um eine unnötige Prüfung bei Rückkehr aus einem Dialog zu vermeiden.

Beispiel 3: onRestart in Fragment mit ViewLifecycleOwner

Das Fragment verwendet onRestart über LifecycleObserver, um Daten zu aktualisieren.

class FeedFragment : Fragment() {
    private val viewModel: FeedViewModel by viewModels()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        viewLifecycleOwner.lifecycle.addObserver(object : LifecycleObserver {
            @OnLifecycleEvent(Lifecycle.Event.ON_RESTART)
            fun onRestart() {
                Log.d("FeedFragment", "onRestart über LifecycleObserver")
                viewModel.refreshFeed()
            }
        })
    }
}

Anstatt onRestart in Fragment zu überschreiben, wird LifecycleObserver verwendet — ein flexiblerer Ansatz, der das Hinzufügen von Lebenszyklus-Ereignislogik ohne Vererbung ermöglicht. ViewLifecycleOwner stellt sicher, dass der Observer innerhalb des View-Bereichs lebt (er überlebt onDestroyView nicht).