Återställning av tillstånd i mobilapplikationer: vad är det, mekanism och funktionsprincip

Vad är State Restoration?

State Restoration (återställning av tillstånd) är en systemmekanism som gör det möjligt att spara det aktuella tillståndet för applikationens användargränssnitt och återställa det efter avslutning eller omstart. När användaren minimerar applikationen eller systemet stänger den för att frigöra resurser, registrerar State Restoration UI:s nyckelparametrar och sparar dem i en krypterad lagring.

Utan State Restoration förlorar användaren all osparad data vid växling mellan applikationer. Till exempel ett ifyllt kontaktformulär, en lång sökfråga eller en delvis visad nyhetslista — allt försvinner vid omstart. State Restoration löser detta problem genom att automatiskt registrera tillståndet för ViewController eller Activity vid minimeringstillfället.

Mekanismen fungerar på systemnivå och stöds av båda stora mobilplattformarna. iOS tillhandahåller State Restoration via NSUserActivity och protokollet UIStateRestoring, och Android via SavedStateHandle i Jetpack-arkitekturkomponenterna och ViewModel. Implementeringen skiljer sig, men konceptet är identiskt.

Hur fungerar mekanismen för State Restoration?

State Restoration-processen delas in i två faser: spara (save) och återställa (restore). I sparasfasen anropar systemet motsvarande livscykelmetoder där applikationen måste serialisera det aktuella UI-tillståndet till en kompakt representation. I återställningsfasen skickar systemet tillbaka den sparade datan och applikationen deserialiserar den för att återställa UI.

Mekanism för att spara tillstånd

Spara initieras av systemet när applikationen går över till bakgrundsläge eller när den får en signal om förestående avslutning. I iOS anropas metoden encodeRestorableState i UIViewController, i Android onSaveInstanceState i Activity eller sparande via SavedStateHandle. Data serialiseras till ett format som stöder primitiva typer: strängar, siffror, byte-arrayer och Parcelable-objekt.

Mängden sparad data bör vara minimal — systemet inför begränsningar för storleken på det sparade paketet. I Android är gränsen cirka 50 KB per process. Överskridande av gränsen leder till undantaget TransactionTooLargeException. Därför rekommenderar arkitekter att endast spara identifierare och nycklar, och ladda fullständig data från permanent lagring vid återställning.

Återställa UI från sparat tillstånd

Vid återställning levererar systemet det sparade datapaketet till applikationen vid startögonblicket. I iOS anropas metoden decodeRestorableState, i Android onRestoreInstanceState eller läsning från SavedStateHandle. Applikationen extraherar identifierare och nycklar från paketet och återställer UI: rullningsposition, valda element, inmatad data.

Det är viktigt att ta hänsyn till att återställning kan ske i en ny process. Om applikationen har avlastats helt från minnet, skapas processen på nytt och alla objekt i minnet saknas. Därför måste tillståndet vara serialiserbart och oberoende av körningskontexten från föregående session. Detta är särskilt kritiskt för stora formulär med många inmatningsfält och långa flersidiga gränssnitt.

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 på iOS och Android

Implementeringen av State Restoration skiljer sig avsevärt mellan plattformarna. iOS använder ett deklarativt angreppssätt via storyboard och UIKit-protokoll, medan Android använder ett imperativt angreppssätt via Activitys livscykelmetoder och Jetpack-arkitekturkomponenter. Valet av angreppssätt beror på målplattformen och applikationens arkitektur.

State Restoration i iOS (UIKit)

I iOS är State Restoration uppbyggt på tre komponenter: UIApplication hanterar den övergripande processen, UIViewController implementerar protokollet UIStateRestoring och NSUserActivity lagrar data för återställning av navigering. För att aktivera måste du ställa in restorationIdentifier i UIViewController och implementera encodeRestorableState och decodeRestorableState.

iOS sparar automatiskt tillståndet för navigeringskontrollen (UINavigationController) och alla inkapslade ViewController, om de har restorationIdentifier inställt. Systemet hanterar navigeringsstacken och återställer den i ursprungligt skick. Data inuti kontrollerna (inmatad text, rullningsposition) måste dock explicit sparas av utvecklaren.

State Restoration i Android (SavedStateHandle)

I Android är den moderna ansatsen till State Restoration baserad på SavedStateHandle — en komponent från AndroidX Lifecycle-biblioteket. SavedStateHandle är tillgänglig inuti ViewModel och sparar och återställer automatiskt data vid konfigurationsändring (skärmrotation) och vid omstart av processen. Data lagras i Bundle och serialiseras automatiskt.

SavedStateHandle beter sig som en nyckel-värde-lagring med stöd för LiveData. Vid konfigurationsändring sparas och återställs data automatiskt. För att stödja omstart av processen måste ViewModel skapas via SavedStateViewModelFactory — detta gör att ViewModel kan överleva fullständig avslutning av applikationen.

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
    }
}

Implementera State Restoration i kod

Praktisk implementering av State Restoration kräver hänsyn till flera aspekter: val av rätt lagring, bestämning av mängden data att spara och testning av olika avslutningsscenarier. Låt oss titta på steg-för-steg-implementeringen för en Flutter-applikation med hjälp av paketet state_restoration.

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 ?? '';
  }
}

Vid implementering är det viktigt att komma ihåg sparandets gränser. Inte varje UI-fält behöver återställas. Rullningsposition i en lång lista — ja. Tillfälligt animationstillstånd — nej. Utvecklaren bör medvetet välja vilken data som är kritisk för användarupplevelsen och vilken som säkert kan återställas utan förlust av bekvämlighet.

Testning av State Restoration är en separat uppgift som kräver simulering av processavslutning. På Android kan detta göras via kommandot adb shell am kill, på iOS via simulering av avslutning i Xcode. UI-testramverk som Espresso och XCTest tillhandahåller speciella metoder för att kontrollera tillståndsåterställning.

Bästa praxis för State Restoration

Första regeln — spara identifierare, inte data. Istället för att spara ett komplett objekt med hundratals fält, spara dess unika identifierare och ladda vid återställning aktuell data från databasen eller API. Detta sparar utrymme i Bundle och garanterar att data är aktuell vid återställningstillfället.

Andra regeln — testa alla scenarier. Kontrollera återställning efter skärmrotation, efter minimering och återkomst efter en timme, efter att applikationen stängts av systemet på grund av minnesbrist. Varje scenario kan bete sig olika beroende på operativsystemets tillstånd och tillgängliga resurser.

Tredje regeln — använd systemmekanismer, inte egna. iOS och Android tillhandahåller inbyggda API:er för State Restoration som är optimerade för den specifika plattformen. Egen implementering via SharedPreferences eller UserDefaults kan leda till synkroniseringsproblem och oväntat beteende vid återställning.

Fjärde regeln — hantera frånvaro av tillstånd. Vid första start eller efter rensning av data kan tillstånd saknas. UI måste fungera korrekt i ursprungligt skick utan att kasta undantag. Kontrollera all sparad data för null före användning och tillhandahåll standardvärden.

Femte regeln — dokumentera sparade nycklar. När det finns dussintals skärmar i projektet och varje sparar flera fält, uppstår kaos utan centraliserad nyckelhantering. Skapa en enhetlig klass eller fil med nyckelkonstanter för State Restoration i varje modul. Detta förenklar underhållet och förhindrar oavsiktlig överskrivning av data vid omfaktorisering.