Restauração de Estado em aplicativos móveis: o que é, mecanismo e princípio de funcionamento

O que é State Restoration?

State Restoration (restauração de estado) é um mecanismo do sistema que permite salvar o estado atual da interface do usuário do aplicativo e restaurá-lo após a finalização ou reinicialização. Quando um usuário minimiza um aplicativo ou o sistema o fecha para liberar recursos, o State Restoration captura os parâmetros principais da UI e os salva em armazenamento criptografado.

Sem o State Restoration, os usuários perdem todos os dados não salvos ao alternar entre aplicativos. Por exemplo, um formulário de feedback preenchido, uma consulta de pesquisa longa ou uma lista de notícias parcialmente visualizada — tudo isso desaparece ao reiniciar. O State Restoration resolve esse problema capturando automaticamente o estado do ViewController ou Activity no momento da minimização.

O mecanismo funciona no nível do sistema e é suportado por ambas as principais plataformas móveis. O iOS fornece State Restoration via NSUserActivity e o protocolo UIStateRestoring, enquanto o Android fornece via SavedStateHandle nos componentes arquitetônicos Jetpack e ViewModel. A implementação difere, mas o conceito é idêntico.

Como funciona o State Restoration?

O processo de State Restoration é dividido em duas fases: salvamento e restauração. Na fase de salvamento, o sistema chama os métodos correspondentes do ciclo de vida, nos quais o aplicativo deve serializar o estado atual da UI em uma representação compacta. Na fase de restauração, o sistema retorna os dados salvos e o aplicativo os desserializa para restaurar a UI.

Mecanismo de salvamento de estado

O salvamento é iniciado pelo sistema quando o aplicativo vai para segundo plano ou recebe um sinal de finalização iminente. No iOS, o método encodeRestorableState do UIViewController é chamado; no Android, o onSaveInstanceState da Activity ou o salvamento via SavedStateHandle. Os dados são serializados em um formato que suporta tipos primitivos: strings, números, arrays de bytes e objetos Parcelable.

A quantidade de dados salvos deve ser mínima — o sistema impõe limites no tamanho do pacote de estado salvo. No Android, o limite é de aproximadamente 50 KB por processo. Exceder o limite causa uma exceção TransactionTooLargeException. Portanto, os arquitetos recomendam salvar apenas identificadores e chaves, e carregar os dados completos do armazenamento persistente na restauração.

Restaurando a UI a partir do estado salvo

Durante a restauração, o sistema passa o pacote de dados salvos ao aplicativo no momento da inicialização. No iOS, o método decodeRestorableState é chamado; no Android, o onRestoreInstanceState ou a leitura do SavedStateHandle. O aplicativo extrai identificadores e chaves do pacote e restaura a UI: posição de rolagem, itens selecionados, dados inseridos.

É importante observar que a restauração pode ocorrer em um novo processo. Se o aplicativo foi completamente descarregado da memória, o processo é criado novamente e todos os objetos na memória estão ausentes. Portanto, o estado deve ser serializável e independente do contexto de execução da sessão anterior. Isso é especialmente crítico para formulários grandes com múltiplos campos de entrada e interfaces longas de várias páginas.

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 no iOS e Android

A implementação do State Restoration difere significativamente entre as plataformas. O iOS usa uma abordagem declarativa por meio de storyboards e protocolos UIKit, enquanto o Android usa uma abordagem imperativa por meio de métodos do ciclo de vida da Activity e componentes arquitetônicos Jetpack. A escolha da abordagem depende da plataforma alvo e da arquitetura do aplicativo.

State Restoration no iOS (UIKit)

No iOS, o State Restoration é construído em três componentes: o UIApplication gerencia o processo geral, o UIViewController implementa o protocolo UIStateRestoring e o NSUserActivity armazena dados para restauração da navegação. Para ativá-lo, é necessário definir o restorationIdentifier no UIViewController e implementar encodeRestorableState e decodeRestorableState.

O iOS salva automaticamente o estado do controlador de navegação (UINavigationController) e todos os ViewControllers aninhados se eles tiverem um restorationIdentifier definido. O sistema gerencia a pilha de navegação e a restaura ao seu estado original. No entanto, os dados dentro dos controladores (texto inserido, posição de rolagem) devem ser explicitamente salvos pelo desenvolvedor.

State Restoration no Android (SavedStateHandle)

No Android, a abordagem moderna do State Restoration é construída no SavedStateHandle — um componente da biblioteca AndroidX Lifecycle. O SavedStateHandle é acessível dentro do ViewModel e salva e restaura automaticamente os dados em mudanças de configuração (rotação de tela) e reinicialização do processo. Os dados são armazenados em um Bundle e serializados automaticamente.

O SavedStateHandle se comporta como um armazenamento chave-valor com suporte a LiveData. Em mudanças de configuração, os dados são salvos e restaurados automaticamente. Para suportar a reinicialização do processo, o ViewModel deve ser criado via SavedStateViewModelFactory — isso permite que o ViewModel sobreviva à finalização completa do aplicativo.

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

Implementando State Restoration em código

A implementação prática do State Restoration requer considerar vários aspectos: escolher o armazenamento adequado, determinar a quantidade de dados a salvar e testar vários cenários de finalização. Vamos percorrer uma implementação passo a passo para um aplicativo Flutter usando o pacote 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 ?? '';
  }
}

Ao implementar, é importante lembrar os limites de salvamento. Nem todo campo da UI precisa ser restaurado. Uma posição de rolagem em uma lista longa — sim. Um estado temporário de animação — não. O desenvolvedor deve escolher conscientemente quais dados são críticos para a experiência do usuário e quais podem ser redefinidos com segurança sem perda de conveniência.

Testar o State Restoration é uma tarefa separada que requer simular a finalização do processo. No Android, isso pode ser feito pelo comando adb shell am kill; no iOS, pela simulação de finalização no Xcode. Estruturas de teste de UI, como Espresso e XCTest, fornecem métodos especiais para verificar a restauração do estado.

Melhores práticas do State Restoration

A primeira regra — salve identificadores, não dados. Em vez de salvar o objeto completo com cem campos, salve seu identificador único e, na restauração, carregue os dados reais do banco de dados ou API. Isso economiza espaço no Bundle e garante a atualidade dos dados no momento da restauração.

A segunda regra — teste todos os cenários. Verifique a restauração após rotação de tela, após minimizar e retornar uma hora depois, após o sistema finalizar o aplicativo por falta de memória. Cada cenário pode se comportar de maneira diferente dependendo do estado do sistema operacional e dos recursos disponíveis.

A terceira regra — use mecanismos do sistema, não personalizados. iOS e Android fornecem APIs integradas para State Restoration otimizadas para sua plataforma específica. Uma implementação personalizada via SharedPreferences ou UserDefaults pode causar problemas de sincronização e comportamento inesperado durante a restauração.

A quarta regra — lide com a ausência de estado. Na primeira inicialização ou após limpar os dados, o estado pode estar ausente. A UI deve funcionar corretamente em seu estado inicial sem lançar exceções. Verifique todos os dados salvos como nulos antes do uso e forneça valores padrão.

A quinta regra — documente as chaves salvas. Quando um projeto tem dezenas de telas e cada uma salva vários campos, sem gerenciamento centralizado de chaves surge o caos. Crie uma única classe ou arquivo com constantes de chave para State Restoration em cada módulo. Isso simplifica a manutenção e evita sobrescritas acidentais de dados durante a refatoração.