Възстановяване на състоянието в мобилните приложения: какво е, механизъм и принцип на работа

Какво е State Restoration?

State Restoration (възстановяване на състоянието) е системен механизъм, който позволява запазване на текущото състояние на потребителския интерфейс на приложението и възстановяването му след затваряне или рестартиране. Когато потребителят минимизира приложението или системата го затвори за освобождаване на ресурси, State Restoration записва ключовите параметри на UI и ги запазва в криптирано хранилище.

Без State Restoration потребителят губи всички незапазени данни при превключване между приложения. Например, попълнен формуляр за контакт, дълга заявка за търсене или частично прегледан списък с новини — всичко това изчезва при рестартиране. State Restoration решава този проблем, като автоматично записва състоянието на ViewController или Activity в момента на минимизиране.

Механизмът работи на системно ниво и се поддържа от двете основни мобилни платформи. iOS предоставя State Restoration чрез NSUserActivity и протокола UIStateRestoring, а Android — чрез SavedStateHandle в архитектурните компоненти на Jetpack и ViewModel. Имплементацията се различава, но концепцията е идентична.

Как работи механизмът на State Restoration?

Процесът на State Restoration се разделя на две фази: запазване (save) и възстановяване (restore). Във фазата на запазване системата извиква съответните методи на жизнения цикъл, в които приложението трябва да сериализира текущото състояние на UI в компактно представяне. Във фазата на възстановяване системата предава запазените данни обратно и приложението ги десериализира за възстановяване на UI.

Механизъм за запазване на състоянието

Запазването се инициира от системата при преминаване на приложението в фонов режим или при получаване на сигнал за предстоящо затваряне. В iOS се извиква методът encodeRestorableState в UIViewController, в Android — onSaveInstanceState в Activity или запазване чрез SavedStateHandle. Данните се сериализират във формат, поддържащ примитивни типове: низове, числа, байтови масиви и Parcelable обекти.

Обемът на запазените данни трябва да бъде минимален — системата налага ограничения върху размера на запазения пакет. В Android ограничението е приблизително 50 KB на процес. Превишаването на ограничението води до изключение TransactionTooLargeException. Затова архитектите препоръчват запазване само на идентификатори и ключове, а пълните данни да се зареждат от постоянното хранилище при възстановяване.

Възстановяване на UI от запазено състояние

При възстановяване системата предава запазения пакет с данни на приложението в момента на стартиране. В iOS се извиква методът decodeRestorableState, в Android — onRestoreInstanceState или четене от SavedStateHandle. Приложението извлича идентификаторите и ключовете от пакета и възстановява UI: позиция на превъртане, избрани елементи, въведени данни.

Важно е да се вземе предвид, че възстановяването може да се случи в нов процес. Ако приложението е напълно разтоварено от паметта, процесът се създава наново и всички обекти в паметта липсват. Следователно състоянието трябва да бъде сериализируемо и независимо от контекста на изпълнение на предишната сесия. Това е особено критично за големи формуляри с множество полета за въвеждане и дълги многостранични интерфейси.

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 на iOS и Android

Имплементацията на State Restoration се различава значително между платформите. iOS използва декларативен подход чрез storyboard и протоколи на UIKit, а Android — императивен подход чрез методите на жизнения цикъл на Activity и архитектурните компоненти на Jetpack. Изборът на подход зависи от целевата платформа и архитектурата на приложението.

State Restoration в iOS (UIKit)

В iOS State Restoration се основава на три компонента: UIApplication управлява общия процес, UIViewController имплементира протокола UIStateRestoring, а NSUserActivity съхранява данни за възстановяване на навигацията. За активиране трябва да зададете restorationIdentifier в UIViewController и да имплементирате encodeRestorableState и decodeRestorableState.

iOS автоматично запазва състоянието на навигационния контролер (UINavigationController) и всички вложени ViewController, ако имат зададен restorationIdentifier. Системата управлява стека за навигация и го възстановява в първоначалното му състояние. Въпреки това, данните вътре в контролерите (въведен текст, позиция на превъртане) трябва да бъдат изрично запазени от разработчика.

State Restoration в Android (SavedStateHandle)

В Android модерният подход към State Restoration се основава на SavedStateHandle — компонент от библиотеката AndroidX Lifecycle. SavedStateHandle е достъпен вътре в ViewModel и автоматично запазва и възстановява данни при промяна на конфигурацията (завъртане на екрана) и при рестартиране на процеса. Данните се съхраняват в Bundle и автоматично се сериализират.

SavedStateHandle се държи като хранилище ключ-стойност с поддръжка на LiveData. При промяна на конфигурацията данните автоматично се запазват и възстановяват. За поддръжка на рестартиране на процеса, ViewModel трябва да бъде създаден чрез SavedStateViewModelFactory — това позволява на ViewModel да оцелее при пълно затваряне на приложението.

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

Имплементация на State Restoration в код

Практическата имплементация на State Restoration изисква отчитане на няколко аспекта: избор на правилното хранилище, определяне на обема на запазените данни и тестване на различни сценарии на затваряне. Нека разгледаме имплементацията стъпка по стъпка за Flutter приложение с използване на пакета 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 ?? '';
  }
}

При имплементацията е важно да помните за границите на запазване. Не всяко UI поле трябва да бъде възстановявано. Позиция на превъртане в дълъг списък — да. Временно състояние на анимация — не. Разработчикът трябва съзнателно да избира кои данни са критични за потребителското изживяване и кои могат безопасно да бъдат нулирани без загуба на удобство.

Тестването на State Restoration е отделна задача, изискваща симулация на прекратяване на процес. На Android това може да се направи чрез командата adb shell am kill, на iOS — чрез симулация на прекратяване в Xcode. Рамките за UI тестване, като Espresso и XCTest, предоставят специални методи за проверка на възстановяване на състоянието.

Най-добри практики за State Restoration

Първо правило — запазвайте идентификатори, а не данни. Вместо да запазвате цял обект със стотици полета, запазете неговия уникален идентификатор, а при възстановяване заредете актуалните данни от базата данни или API. Това спестява място в Bundle и гарантира актуалност на данните в момента на възстановяване.

Второ правило — тествайте всички сценарии. Проверете възстановяването след завъртане на екрана, след минимизиране и връщане след час, след затваряне на приложението от системата поради липса на памет. Всеки сценарий може да се държи различно в зависимост от състоянието на операционната система и наличните ресурси.

Трето правило — използвайте системни механизми, а не собствени. iOS и Android предоставят вградени API за State Restoration, които са оптимизирани за конкретната платформа. Собствена имплементация чрез SharedPreferences или UserDefaults може да доведе до проблеми със синхронизация и неочаквано поведение при възстановяване.

Четвърто правило — обработвайте липса на състояние. При първо стартиране или след изчистване на данни състоянието може да липсва. UI трябва да работи правилно в начално състояние без да хвърля изключения. Проверявайте всички запазени данни за null преди използване и предвидете стойности по подразбиране.

Пето правило — документирайте запазените ключове. Когато в проекта има десетки екрани и всеки запазва няколко полета, без централизирано управление на ключовете възниква хаос. Създайте единен клас или файл с константи на ключове за State Restoration във всеки модул. Това опростява поддръжката и предотвратява случайно преписане на данни при рефакториране.