onRestart — restauração de Activity no ciclo de vida

onRestart — a essência do método no ciclo de vida do Android

onRestart — um método de callback que o Android chama estritamente antes de onStart quando uma Activity retorna do estado invisível Stopped para se tornar visível. Este método é único porque só é chamado quando a Activity é exibida novamente — durante a primeira criação da instância, a sequência começa com onCreate, pulando onRestart. O ciclo completo: onCreate → onStart → onResume (primeira inicialização) ou onRestart → onStart → onResume (exibição subsequente).

Da perspectiva do sistema Android, onRestart é uma otimização que permite que a Activity se prepare para seu retorno: atualizar dados do repositório, sincronizar o estado da UI, verificar a conectividade de rede. Ao contrário de onResume, que é chamado toda vez que a Activity ganha foco (inclusive ao retornar de um diálogo ou menu do sistema), onRestart é acionado apenas durante um ciclo completo de ocultação e retorno. Isso torna onRestart o local ideal para operações de atualização “pesadas” que não são necessárias durante a perda parcial de foco.

De acordo com a especificação do ciclo de vida da Activity do Android, o intervalo de tempo entre onStop e onRestart pode variar de alguns segundos (o usuário alternou rapidamente) a várias horas (o aplicativo estava em segundo plano e o usuário retornou). Durante esse tempo, os dados em uma fonte remota (API, BD) podem ter mudado, então onRestart é um ponto natural para verificar a atualidade.

Quando onRestart é chamado: condições e sequência

onRestart só é chamado quando uma Activity retorna do estado Stopped, no qual a Activity entrou depois que onStop foi chamado. Abaixo estão todos os cenários que levam ao onRestart.

Cenários de invocação do onRestart:

• Retorno de outra Activity — o usuário abriu uma nova Activity (por exemplo, tocou em uma notificação) e depois navegou de volta (pressionou “Voltar”). Pilha: MainActivity.onPause → MainActivity.onStop → SecondActivity é criada → usuário pressiona “Voltar” → SecondActivity.onPause → SecondActivity.onStop → SecondActivity.onDestroy → MainActivity.onRestart → MainActivity.onStart → MainActivity.onResume.
• Retorno da minimização — o usuário minimizou o aplicativo (Início) e após algum tempo retornou. CurrentActivity.onPause → CurrentActivity.onStop → (aplicativo em segundo plano) → usuário retorna → CurrentActivity.onRestart → CurrentActivity.onStart → CurrentActivity.onResume.
• Retorno da tela de bloqueio — a tela de bloqueio cobre a Activity; após desbloquear, a Activity recebe onRestart se um tempo significativo tiver passado (mais de 5 segundos).
• Retorno de um aplicativo lançado via Intent — câmera, galeria, navegador — qualquer aplicativo de terceiros lançado via startActivityForResult() ou ActivityResultLauncher.

Quando onRestart NÃO é chamado: durante a rotação da tela (a Activity é destruída e recriada via onCreate), ao retornar de uma caixa de diálogo (a Activity não entra em onStop, apenas onPause → onResume), durante a morte do processo (a Activity é recriada).

onRestart vs onCreate: qual escolher

onRestart e onCreate são duas abordagens diferentes para restaurar uma Activity. A escolha entre eles depende se a Activity foi completamente destruída ou simplesmente ocultada.

Regra de seleção: faça a inicialização da View e a assinatura do LiveData/StateFlow no onCreate (ou onViewCreated para Fragment). Atualizações de dados, recarga de listas e verificações de estado — no onRestart. Se os dados são carregados via ViewModel, onRestart pode simplesmente chamar o método refresh() no ViewModel, e a View assinará os dados atualizados através de um fluxo reativo.

O Google recomenda: não duplique a lógica do onCreate no onRestart. Extraia métodos refresh() no ViewModel que carregam dados atuais e chame-os no onRestart. Isso preserva uma arquitetura MVVM limpa e elimina duplicação de código.

Casos de uso do onRestart: atualização de dados e UI

onRestart é o local ideal para operações que devem ser executadas toda vez que a tela for retornada, mas não são necessárias na primeira abertura. Aqui estão cenários típicos:

• Atualizar uma lista do BD ou API — o usuário foi para outra Activity, alterou dados lá, voltou — a lista deve estar atualizada. Chame viewModel.refreshItems() no onRestart.
• Verificação de autorização — se a Activity ficou oculta por muito tempo, o token de acesso pode ter expirado. onRestart é o ponto para verificar a validade do token e redirecionar para a tela de login.
• Sincronização do estado da UI — alternância de tema, mudança de idioma, atualização de configurações — as alterações devem ser aplicadas ao retornar à tela.
• Recarga de mídia — se a Activity exibe conteúdo que pode ter mudado (feed de notícias, taxas de câmbio, clima), atualize os dados no onRestart.
• Verificação de conectividade de rede — ao retornar do modo offline, a Activity deve verificar a disponibilidade da rede e alternar a UI.
• Restauração de animações — animações liberadas no onStop devem ser reiniciadas no onRestart antes do onStart.

O que NÃO fazer no onRestart: não reinicialize as Views — elas estão vivas porque a Activity não foi destruída. Não assine novamente o LiveData — a assinatura no onCreate ainda está viva. Não crie novos Fragments — eles já estão no FragmentManager.

onRestart e morte do processo: uma exceção importante

A exceção mais importante: onRestart não é chamado se o processo do aplicativo foi morto pelo sistema. Este é um ponto-chave que os desenvolvedores frequentemente perdem ao confiar no onRestart para restauração de estado.

Durante a morte do processo:

• O aplicativo estava em segundo plano, o Android matou o processo para liberar memória.
• O usuário retorna — o sistema inicia um novo processo.
• A Activity é recriada: onCreate(Bundle) → onStart → onResume.
• onRestart NÃO é chamado — para o sistema, esta é uma nova instância da Activity.

Como se proteger contra isso: sempre salve o estado crítico em onSaveInstanceState(Bundle) (chamado antes de onStop) ou use SavedStateHandle no ViewModel. No onCreate, verifique savedInstanceState: se não for null, restaure o estado do Bundle; se for null, carregue dados novos.

De acordo com o Google Android Vitals, cerca de 7% dos retornos a uma Activity após um longo tempo em segundo plano ocorrem após a morte do processo. Isso significa que a cada 15.ª Activity que deveria ter chamado onRestart, na verdade passa por onCreate. Ignorar esse cenário é uma das principais causas de bugs de “tela vazia após o retorno”.

Exemplos de código com onRestart em Kotlin

Exemplo 1: onRestart com atualização de lista via ViewModel

A Activity chama viewModel.refreshTasks() no onRestart para atualizar a lista de tarefas após retornar da tela de edição.

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", "Recebidas ${tasks.size} tarefas")
        }
    }

    override fun onRestart() {
        super.onRestart()
        Log.d("TaskList", "onRestart: atualizando lista de tarefas")
        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() carrega dados atuais do repositório. LiveData notifica automaticamente a Activity sobre mudanças de dados — a UI é atualizada sem código adicional. onRestart não cria uma nova assinatura — ela já foi configurada no onCreate.

Exemplo 2: onRestart com verificação de autorização

A Activity verifica a validade do token ao retornar e redireciona para o login se necessário.

class ProfileActivity : AppCompatActivity() {
    private val authManager = AuthManager()
    private val launcher = registerForActivityResult(
        ActivityResultContracts.StartActivityForResult()
    ) { Log.d("Profile", "Voltou da tela de login") }

    override fun onRestart() {
        super.onRestart()
        if (!authManager.isTokenValid()) {
            Log.d("Profile", "Token expirado — redirecionando para login")
            launcher.launch(Intent(this, LoginActivity::class.java))
        }
    }
}

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

Se o usuário minimizou o aplicativo por um longo período e retornou após o token expirar, onRestart o redirecionará para a tela de login. Isso evita erros de API ao tentar fazer uma solicitação com um token expirado. Nota: a verificação está no onRestart, não no onResume, para evitar uma verificação desnecessária ao retornar de um diálogo.

Exemplo 3: onRestart em Fragment com ViewLifecycleOwner

O Fragment usa onRestart via LifecycleObserver para atualizar dados.

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 via LifecycleObserver")
                viewModel.refreshFeed()
            }
        })
    }
}

Em vez de sobrescrever onRestart no Fragment, o LifecycleObserver é usado — uma abordagem mais flexível que permite adicionar lógica de eventos do ciclo de vida sem herança. O ViewLifecycleOwner garante que o observer viva dentro do escopo da View (não sobrevive ao onDestroyView).