State Restoration in mobilen Anwendungen: Was es ist, Mechanismus und Funktionsprinzip

Was ist State Restoration?

State Restoration (Zustandswiederherstellung) ist ein Systemmechanismus, der es ermöglicht, den aktuellen Zustand der Benutzeroberfläche einer Anwendung zu speichern und nach Beendigung oder Neustart wiederherzustellen. Wenn ein Benutzer eine Anwendung minimiert oder das System sie zur Freigabe von Ressourcen schließt, erfasst State Restoration die wichtigsten UI-Parameter und speichert sie in einem verschlüsselten Speicher.

Ohne State Restoration verlieren Benutzer beim Wechseln zwischen Anwendungen alle nicht gespeicherten Daten. Beispielsweise ein ausgefülltes Feedback-Formular, eine lange Suchanfrage oder eine teilweise angesehene Nachrichtenliste — all dies verschwindet beim Neustart. State Restoration löst dieses Problem, indem es automatisch den Zustand des ViewControllers oder der Activity im Moment des Minimierens erfasst.

Der Mechanismus arbeitet auf Systemebene und wird von beiden wichtigen mobilen Plattformen unterstützt. iOS bietet State Restoration über NSUserActivity und das UIStateRestoring-Protokoll, während Android es über SavedStateHandle in den Jetpack-Architekturkomponenten und ViewModel bereitstellt. Die Implementierung unterscheidet sich, aber das Konzept ist identisch.

Wie funktioniert State Restoration?

Der State Restoration-Prozess ist in zwei Phasen unterteilt: Speichern und Wiederherstellen. In der Speicherphase ruft das System die entsprechenden Lebenszyklusmethoden auf, in denen die Anwendung den aktuellen UI-Zustand in eine kompakte Darstellung serialisieren muss. In der Wiederherstellungsphase übergibt das System die gespeicherten Daten zurück, und die Anwendung deserialisiert sie, um die UI wiederherzustellen.

Mechanismus zum Speichern des Zustands

Das Speichern wird vom System initiiert, wenn die Anwendung in den Hintergrund wechselt oder ein Signal für eine bevorstehende Beendigung erhält. Unter iOS wird die Methode encodeRestorableState des UIViewController aufgerufen; unter Android wird onSaveInstanceState der Activity oder das Speichern über SavedStateHandle ausgelöst. Die Daten werden in ein Format serialisiert, das primitive Typen unterstützt: Zeichenketten, Zahlen, Byte-Arrays und Parcelable-Objekte.

Die Menge der gespeicherten Daten sollte minimal sein — das System legt Beschränkungen für die Größe des gespeicherten Zustandsbundles fest. Unter Android beträgt das Limit etwa 50 KB pro Prozess. Eine Überschreitung des Limits führt zu einer TransactionTooLargeException. Daher empfehlen Architekten, nur Identifikatoren und Schlüssel zu speichern und die vollständigen Daten bei der Wiederherstellung aus dem persistenten Speicher zu laden.

Wiederherstellen der UI aus dem gespeicherten Zustand

Bei der Wiederherstellung übergibt das System das gespeicherte Datenbundle beim Start an die Anwendung. Unter iOS wird die Methode decodeRestorableState aufgerufen; unter Android wird onRestoreInstanceState oder das Lesen aus SavedStateHandle verwendet. Die Anwendung extrahiert Identifikatoren und Schlüssel aus dem Bundle und stellt die UI wieder her: Bildlaufposition, ausgewählte Elemente, eingegebene Daten.

Es ist wichtig zu beachten, dass die Wiederherstellung in einem neuen Prozess erfolgen kann. Wenn die Anwendung vollständig aus dem Speicher entladen wurde, wird der Prozess neu erstellt, und alle Objekte im Speicher fehlen. Daher muss der Zustand serialisierbar und unabhängig vom Laufzeitkontext der vorherigen Sitzung sein. Dies ist besonders kritisch für große Formulare mit mehreren Eingabefeldern und lange mehrseitige Oberflächen.

class MainActivity : AppCompatActivity() {
    private var searchQuery: String = ""

    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        outState.putString("search_query", searchQuery)
    }

    override fun onRestoreInstanceState(savedState: Bundle) {
        super.onRestoreInstanceState(savedState)
        searchQuery = savedState.getString("search_query", "")!!
        restoreSearchUI(searchQuery)
    }
}

State Restoration auf iOS und Android

Die Implementierung von State Restoration unterscheidet sich erheblich zwischen den Plattformen. iOS verwendet einen deklarativen Ansatz über Storyboards und UIKit-Protokolle, während Android einen imperativen Ansatz über Activity-Lebenszyklusmethoden und Jetpack-Architekturkomponenten verwendet. Die Wahl des Ansatzes hängt von der Zielplattform und der Anwendungsarchitektur ab.

State Restoration unter iOS (UIKit)

Unter iOS basiert State Restoration auf drei Komponenten: UIApplication verwaltet den Gesamtprozess, UIViewController implementiert das UIStateRestoring-Protokoll und NSUserActivity speichert Daten für die Navigationswiederherstellung. Zum Aktivieren müssen Sie restorationIdentifier für UIViewController festlegen und encodeRestorableState sowie decodeRestorableState implementieren.

iOS speichert automatisch den Zustand des Navigationscontrollers (UINavigationController) und aller verschachtelten ViewController, wenn sie eine restorationIdentifier gesetzt haben. Das System verwaltet den Navigationsstapel und stellt ihn im ursprünglichen Zustand wieder her. Daten innerhalb der Controller (eingegebener Text, Bildlaufposition) müssen jedoch explizit vom Entwickler gespeichert werden.

State Restoration unter Android (SavedStateHandle)

Unter Android basiert der moderne Ansatz für State Restoration auf SavedStateHandle — einer Komponente aus der AndroidX Lifecycle-Bibliothek. SavedStateHandle ist innerhalb von ViewModel zugänglich und speichert und stellt Daten bei Konfigurationsänderungen (Bildschirmdrehung) und Prozessneustarts automatisch speichert und wiederherstellt. Die Daten werden in einem Bundle gespeichert und automatisch serialisiert.

SavedStateHandle verhält sich wie ein Schlüssel-Wert-Speicher mit LiveData-Unterstützung. Bei Konfigurationsänderungen werden Daten automatisch gespeichert und wiederhergestellt. Um einen Prozessneustart zu unterstützen, muss das ViewModel über SavedStateViewModelFactory erstellt werden — dies ermöglicht es dem ViewModel, ein vollständiges Beenden der Anwendung zu überleben.

class SearchViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    companion object {
        private val KEY_QUERY = string("search_query")
    }

    fun getSearchQuery(): String? = savedStateHandle[KEY_QUERY]

    fun saveSearchQuery(query: String) {
        savedStateHandle[KEY_QUERY] = query
    }
}

Implementierung von State Restoration im Code

Die praktische Implementierung von State Restoration erfordert die Berücksichtigung mehrerer Aspekte: die Wahl des richtigen Speichers, die Bestimmung der zu speichernden Datenmenge und das Testen verschiedener Beendigungsszenarien. Lassen Sie uns eine schrittweise Implementierung für eine Flutter-Anwendung mit dem Paket state_restoration durchgehen.

class RestorableSearchField extends RestorableProperty<String> {
  String _value = '';

  @override
  String get value => _value;

  @override
  void set value(String newValue) {
    if (_value != newValue) {
      _value = newValue;
      notifyListeners();
    }
  }

  @override
  String? toPrimitives() => _value;

  @override
  void fromPrimitives(String? data) {
    _value = data ?? '';
  }
}

Bei der Implementierung ist es wichtig, die Speichergrenzen zu beachten. Nicht jedes UI-Feld muss wiederhergestellt werden. Eine Bildlaufposition in einer langen Liste — ja. Ein temporärer Animationszustand — nein. Der Entwickler muss bewusst auswählen, welche Daten für die Benutzererfahrung kritisch sind und welche ohne Komfortverlust sicher zurückgesetzt werden können.

Das Testen von State Restoration ist eine separate Aufgabe, die das Simulieren der Prozessbeendigung erfordert. Unter Android kann dies über den Befehl adb shell am kill erfolgen; unter iOS durch die Simulationsbeendigung in Xcode. UI-Testframeworks wie Espresso und XCTest bieten spezielle Methoden zur Überprüfung der Zustandswiederherstellung.

Bewährte Praktiken für State Restoration

Die erste Regel — speichern Sie Identifikatoren, nicht Daten. Anstatt das vollständige Objekt mit hundert Feldern zu speichern, speichern Sie seinen eindeutigen Identifikator und laden Sie bei der Wiederherstellung die aktuellen Daten aus der Datenbank oder API. Dies spart Platz im Bundle und garantiert die Aktualität der Daten zum Zeitpunkt der Wiederherstellung.

Die zweite Regel — testen Sie alle Szenarien. Überprüfen Sie die Wiederherstellung nach einer Bildschirmdrehung, nach dem Minimieren und Zurückkehren eine Stunde später, nachdem das System die App aufgrund von Speichermangel beendet hat. Jedes Szenario kann sich je nach Betriebssystemzustand und verfügbaren Ressourcen unterschiedlich verhalten.

Die dritte Regel — verwenden Sie Systemmechanismen, keine eigenen. iOS und Android bieten integrierte APIs für State Restoration, die für ihre jeweilige Plattform optimiert sind. Eine benutzerdefinierte Implementierung über SharedPreferences oder UserDefaults kann zu Synchronisierungsproblemen und unerwartetem Verhalten bei der Wiederherstellung führen.

Die vierte Regel — behandeln Sie fehlenden Zustand. Beim ersten Start oder nach dem Löschen von Daten kann der Zustand fehlen. Die UI muss in ihrem ursprünglichen Zustand korrekt funktionieren, ohne Ausnahmen auszulösen. Überprüfen Sie alle gespeicherten Daten vor der Verwendung auf null und stellen Sie Standardwerte bereit.

Die fünfte Regel — dokumentieren Sie gespeicherte Schlüssel. Wenn ein Projekt Dutzende von Bildschirmen hat und jeder mehrere Felder speichert, entsteht ohne zentrales Schlüsselmanagement Chaos. Erstellen Sie eine einzelne Klasse oder Datei mit Schlüsselkonstanten für State Restoration in jedem Modul. Dies vereinfacht die Wartung und verhindert versehentliches Überschreiben von Daten bei der Refaktorisierung.