Activity Lifecycle: o que é, onCreate onStart onResume no Android

O que é o Activity Lifecycle

O Activity Lifecycle (ciclo de vida da Activity) é uma máquina de estados pela qual cada tela de um aplicativo Android passa desde o momento da criação até a destruição completa. O sistema Android gerencia esse processo com base nas ações do usuário: abrir o aplicativo, minimizar, girar a tela, atender uma chamada recebida, alternar entre aplicativos e encerrar.

Compreender o ciclo de vida é essencial para todo desenvolvedor Android, pois o sistema pode destruir uma Activity a qualquer momento quando a memória está baixa — e o aplicativo deve restaurar seu estado corretamente. De acordo com o Google Android Vitals (2025), aplicativos que não tratam o salvamento de estado em onSaveInstanceState() apresentam 42% mais travamentos durante a recriação da Activity.

O ciclo de vida inclui seis métodos callback principais: onCreate(), onStart(), onResume(), onPause(), onStop(), onDestroy(). Adicionalmente, existe o método onRestart(), chamado antes de onStart() quando uma Activity retorna do estado parado. Cada método tem um propósito e tempo de execução estritamente definidos — o sistema os chama sequencialmente, e o desenvolvedor pode sobrescrever qualquer um deles para implementar sua própria lógica.

O ciclo pode ser dividido em três etapas principais: tempo de vida completo (onCreate → onDestroy), tempo de vida visível (onStart → onStop) e tempo de vida em primeiro plano (onResume → onPause). Compreender esses três níveis ajuda a distribuir corretamente o código de inicialização e liberação de recursos.

Métodos do ciclo de vida da Activity

Cada método do ciclo de vida executa uma tarefa estritamente definida. O sistema os chama em uma ordem fixa, e o desenvolvedor deve sobrescrever apenas os métodos necessários para a lógica específica. Não é recomendado chamar os métodos do ciclo de vida diretamente — isso é tratado pelo Android Runtime.

Esquema geral de chamadas

Uma sequência típica ao iniciar um aplicativo: onCreate → onStart → onResume. Ao pressionar o botão Voltar: onPause → onStop → onDestroy. Ao minimizar: onPause → onStop, depois ao retornar: onRestart → onStart → onResume.

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }

    override fun onStart() {
        super.onStart()
    }

    override fun onResume() {
        super.onResume()
    }

    override fun onPause() {
        super.onPause()
    }

    override fun onStop() {
        super.onStop()
    }

    override fun onDestroy() {
        super.onDestroy()
    }

    override fun onRestart() {
        super.onRestart()
    }
}

Cada método sobrescrito deve chamar sua versão super — sem isso, o sistema não pode completar corretamente a transição de estado. Esta regra está estabelecida na documentação do Android Developers e é verificada pelas regras lint do Android Studio.

Três níveis do ciclo de vida

O primeiro nível — tempo de vida completo: o intervalo entre onCreate e onDestroy. Aqui são realizadas a inicialização única e a liberação final de recursos globais. O segundo nível — tempo de vida visível: entre onStart e onStop. A Activity está visível na tela, mas pode estar parcialmente coberta por outra janela. O terceiro nível — tempo de vida em primeiro plano: entre onResume e onPause. A Activity está no topo da pilha de tarefas e interage com o usuário.

onCreate — criação da Activity

onCreate() — o primeiro e único método obrigatório do ciclo de vida da Activity. Ele é chamado pelo sistema uma vez ao criar uma instância da Activity. Este método aceita um parâmetro savedInstanceState: Bundle?, que contém o estado previamente salvo se a Activity estiver sendo recriada após a destruição — por exemplo, durante a rotação da tela.

Dentro de onCreate, as seguintes tarefas são realizadas: inicialização da interface do usuário via setContentView() com um recurso de layout, vinculação de elementos View via findViewById(), configuração de adaptadores para RecyclerView e ViewPager, restauração do estado a partir de savedInstanceState, inicialização de ViewModel e LiveData, configuração de listeners de clique e gestos. O método deve ser concluído o mais rápido possível — operações longas aqui bloqueiam a renderização do primeiro quadro, aumentando o tempo de inicialização do aplicativo.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_profile)

    val userNameText: TextView = findViewById(R.id.user_name)
    val loadButton: Button = findViewById(R.id.load_button)

    if (savedInstanceState != null) {
        userNameText.text = savedInstanceState.getString("user_name")
    }

    loadButton.setOnClickListener {
        loadUserProfile()
    }
}

Se a Activity estiver sendo criada pela primeira vez, savedInstanceState é null. Ao ser recriada após a rotação da tela, o Bundle contém os dados salvos em onSaveInstanceState(). A verificação de null é uma prática padrão para restaurar corretamente a UI sem perder os dados inseridos pelo usuário.

onStart — aparecimento na tela

onStart() é chamado imediatamente após onCreate() ou após onRestart(), quando a Activity se torna visível para o usuário. Neste estado, a Activity ainda não está em primeiro plano e não pode interagir com o usuário, mas sua interface do usuário já está visível na tela. Por exemplo, ao iniciar um aplicativo, o sistema renderiza o primeiro quadro da interface entre as chamadas onStart e onResume.

No método onStart, as seguintes ações são tipicamente realizadas: iniciar animações que devem funcionar enquanto a Activity estiver visível; vincular receptores de transmissão (BroadcastReceiver); conectar-se a serviços de geolocalização e sensores; atualizar dados do ViewModel ou Room. Aqui também é realizada a vinculação a serviços Bound via bindService() se o aplicativo usar uma arquitetura cliente-servidor dentro do processo.

override fun onStart() {
    super.onStart()
    val locationManager = getSystemService(Context.LOCATION_SERVICE) as LocationManager
    locationManager.requestLocationUpdates(
        LocationManager.GPS_PROVIDER,
        5000L,
        10f,
        locationListener
    )
}

override fun onStop() {
    super.onStop()
    val locationManager = getSystemService(Context.LOCATION_SERVICE) as LocationManager
    locationManager.removeUpdates(locationListener)
}

Regra importante: os recursos conectados em onStart devem ser liberados em onStop. Isso garante que, quando a Activity não estiver visível na tela, ela não consuma bateria e recursos do sistema. O Google Play Store verifica aplicativos quanto a vazamentos de LocationListener e outros serviços do sistema ao moderar atualizações.

onResume — obtenção do foco

onResume() — o estado em que a Activity está em primeiro plano e pronta para interagir com o usuário. Este é o estado de trabalho da tela: o sistema transfere o foco de entrada para a Activity, e todos os eventos de toque, entrada de teclado e gestos são direcionados para esta tela. O método onResume é chamado toda vez que a Activity retorna ao primeiro plano — após outra Activity terminar, após uma caixa de diálogo ser fechada, ou após o dispositivo ser desbloqueado.

Em onResume, são realizados: retomada de animações que foram pausadas em onPause; abertura da câmera e outros recursos exclusivos; registro de listeners de sensores (acelerômetro, giroscópio); início de temporizadores e cronômetro para a UI; atualização do conteúdo da tela com dados atuais. O par onResume/onPause é usado para recursos que devem estar ativos apenas quando focados — por exemplo, reconhecimento contínuo de fala ou captura de vídeo.

override fun onResume() {
    super.onResume()
    cameraHolder.openCamera()
    animator.resume()
    sensorManager.registerListener(
        stepCounter,
        sensorManager.getDefaultSensor(Sensor.TYPE_STEP_COUNTER),
        SensorManager.SENSOR_DELAY_NORMAL
    )
}

override fun onPause() {
    super.onPause()
    cameraHolder.closeCamera()
    animator.pause()
    sensorManager.unregisterListener(stepCounter)
}

A diferença entre onStart e onResume é significativa: uma Activity pode estar visível (onStart) mas não ativa (onResume) — por exemplo, quando uma caixa de diálogo pop-up ou uma tela de bloqueio transparente é exibida sobre ela. É em onResume, não em onStart, que recursos exclusivos que exigem acesso exclusivo devem ser abertos.

onPause — perda do foco

onPause() é chamado quando a Activity perde o foco de entrada, mas permanece parcialmente visível. Cenários típicos: abertura de uma caixa de diálogo, pressionar o botão Aplicativos recentes, uma chamada recebida, pressionar o botão Início (neste caso, onPause será seguido por onStop). O método onPause é o último lugar confiável para salvar dados que o usuário não deve perder.

Em onPause, são realizados: salvamento de rascunhos de e-mails e formulários de entrada no Room ou SharedPreferences; interrupção de animações e reprodução de vídeo; fechamento da câmera e liberação de recursos exclusivos; cancelamento de operações caras que não são críticas em segundo plano. O método onPause deve ser concluído em menos de 100 milissegundos — o sistema bloqueia a transição para a próxima Activity até que onPause retorne o controle, e exceder o limite leva a ANR (Application Not Responding).

override fun onPause() {
    super.onPause()
    val editor = SharedPreferences.Manager ...
    editor.putString("draft_text", draftEditText.text.toString())
    editor.apply()
    videoView.pause()
    cameraHolder.release()
}

Importante: onPause é executado na thread da UI, portanto, quaisquer operações de bloqueio, como escrever no banco de dados via Room com uma consulta síncrona, devem ser substituídas por assíncronas (corrotinas) ou executadas em uma thread em segundo plano. Use apply() em vez de commit() para SharedPreferences — apply escreve dados de forma assíncrona e não bloqueia a thread da UI.

onStop — ocultação da tela

onStop() é chamado quando a Activity deixa de ser visível para o usuário. Isso ocorre nos seguintes casos: a Activity está completamente coberta por outra Activity; o usuário pressionou o botão Início ou mudou para outro aplicativo; a Activity está finalizando (onDestroy será chamado depois). No estado onStop, a Activity permanece na memória e mantém todos os seus campos — não está destruída, mas também não está ativa.

Em onStop, são realizados: cancelamento do registro dos BroadcastReceivers registrados em onStart; desconexão de serviços Bound; liberação de LocationListener, SensorListener e outros listeners do sistema; interrupção de operações em segundo plano de longa duração que não são necessárias quando o aplicativo está oculto; escrita do estado atual da UI em um Bundle via onSaveInstanceState() se isso não foi feito em onPause.

override fun onStop() {
    super.onStop()
    unregisterReceiver(connectivityReceiver)
    unbindService(serviceConnection)
    if (isChangingConfigurations()) {
        Log.d("Lifecycle", "A Activity é recriada devido à configuração")
    }
}

O sistema pode destruir uma Activity no estado onStop sem chamar onDestroy quando a memória está baixa. Portanto, todos os dados críticos devem ser salvos antes da transição para onStop. O sinalizador isChangingConfigurations() permite determinar se a chamada onStop está relacionada à rotação da tela — neste caso, a Activity será recriada, não finalizada.

onDestroy — destruição da Activity

onDestroy() — o último método do ciclo de vida chamado antes da destruição completa da Activity. O sistema chama onDestroy em dois casos: a Activity está finalizando via finish() ou o usuário pressiona o botão Voltar; a Activity está sendo destruída pelo sistema devido a uma mudança de configuração (por exemplo, rotação da tela) e será criada novamente. O método onDestroy permite realizar a limpeza final de recursos: desvincular threads e corrotinas, fechar cursores e sockets permanentemente abertos, e liberar memória nativa através do NDK.

override fun onDestroy() {
    super.onDestroy()
    backgroundJob.cancel()
    dbHelper.close()
    if (isFinishing) {
        Log.d("Lifecycle", "A Activity está finalizando permanentemente")
    } else {
        Log.d("Lifecycle", "A Activity será recriada")
    }
}

Nota importante: onDestroy não é garantido de ser chamado se o processo do aplicativo for morto pelo sistema (out-of-memory kill). Portanto, não se pode confiar em onDestroy para salvar dados — esta tarefa é resolvida em onPause ou onStop. A propriedade isFinishing permite distinguir o encerramento da Activity via finish() da recriação devido a mudanças de configuração.

onRestart — retorno do estado parado

onRestart() é chamado antes de onStart() quando uma Activity retorna do estado parado (onStop) para o primeiro plano. Isso acontece quando o usuário reabre o aplicativo do menu Aplicativos recentes ou retorna a uma Activity pressionando Voltar em uma tela filha. O método onRestart permite executar uma lógica diferente de onCreate — por exemplo, atualizar dados que podem ter mudado enquanto a Activity estava oculta.

override fun onRestart() {
    super.onRestart()
    refreshDataFromNetwork()
    Log.d("Lifecycle", "A Activity está reiniciando da pilha")
}

Cenário típico: o usuário abriu o aplicativo, mudou para outra tarefa e retornou uma hora depois. Em onRestart, o aplicativo pode verificar a relevância dos dados e, se muito tempo tiver passado, sugerir recarregar o conteúdo. Isso melhora a experiência do usuário e reduz a probabilidade de exibir informações desatualizadas.

Rotação da tela e salvamento de estado

A rotação da tela é o cenário mais comum de recriação da Activity. Por padrão, o Android destrói a Activity atual e cria uma nova a cada mudança de orientação. Se o estado não for salvo, o usuário perderá todos os dados inseridos. O Android fornece dois mecanismos para isso: onSaveInstanceState() para dados serializáveis e ViewModel para dados que sobrevivem a mudanças de configuração.

onSaveInstanceState e onRestoreInstanceState

onSaveInstanceState() é chamado antes da Activity ser destruída para salvar o estado temporário. Os dados salvos são passados para onCreate através do parâmetro savedInstanceState e para o método onRestoreInstanceState(), que é chamado após onStart. O Bundle tem um limite de tamanho — cerca de 500 KB, portanto, grandes volumes de dados (por exemplo, bitmaps) são salvos via ViewModel.

<!-- AndroidManifest.xml — fixação de orientação -->
<activity android:name=".MainActivity"
    android:configChanges="orientation|screenSize" />

A fixação da orientação via android:configChanges impede a recriação da Activity, mas é considerada um antipadrão se o aplicativo precisar suportar ambas as orientações. A recomendação moderna do Google é usar ViewModel em combinação com onSaveInstanceState para dados que o usuário insere na UI.

Ciclo de vida do Fragment

O Fragment tem seu próprio ciclo de vida, semelhante ao da Activity, mas com métodos adicionais: onAttach, onCreate, onCreateView, onViewCreated, onStart, onResume, onPause, onStop, onDestroyView, onDestroy, onDetach. Um Fragment sempre existe dentro de uma Activity, e seu ciclo de vida está vinculado ao ciclo de vida da Activity contêiner. Se a Activity for destruída, o Fragment a segue.

A principal diferença: o Fragment gerencia não apenas o estado do componente, mas também a hierarquia de View. O método onCreateView retorna a View raiz do Fragment, e onDestroyView destrói essa hierarquia. Isso permite que o Fragment sobreviva à recriação da Activity durante a rotação da tela: o Fragment é preservado e sua View é recriada em onCreateView.

class ProfileFragment : Fragment() {
    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        return inflater.inflate(R.layout.fragment_profile, container, false)
    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        val avatarImage: ImageView = view.findViewById(R.id.avatar_image)
        loadAvatar(avatarImage)
    }
}

Compreender a diferença entre onCreate e onCreateView é criticamente importante: onCreate é chamado uma vez por vida do Fragment (mesmo quando a View é recriada), enquanto onCreateView é chamado toda vez que o Fragment cria ou recria sua hierarquia de View. A inicialização de dados é realizada em onCreate, enquanto a vinculação da UI é feita em onViewCreated.

LifecycleObserver e Jetpack

LifecycleObserver — um componente da biblioteca Android Jetpack que permite reagir a mudanças no ciclo de vida sem sobrescrever métodos na Activity ou Fragment. Em vez de duplicar código em cada método do ciclo de vida, o desenvolvedor cria uma classe separada com anotações @OnLifecycleEvent e a passa para lifecycle.addObserver().

O Jetpack também fornece a interface LifecycleOwner, que é implementada por AppCompatActivity e Fragment. Qualquer objeto que implemente LifecycleOwner pode gerenciar assinaturas do LiveData, corrotinas via lifecycleScope e WorkManager em relação ao ciclo de vida. Esta é uma pedra angular da arquitetura moderna do Android baseada em MVVM e Jetpack.

class MyLocationObserver(private val context: Context) : DefaultLifecycleObserver {
    override fun onStart(owner: LifecycleOwner) {
        startLocationUpdates()
    }

    override fun onStop(owner: LifecycleOwner) {
        stopLocationUpdates()
    }
}

// Na Activity:
lifecycle.addObserver(MyLocationObserver(this))

O uso do DefaultLifecycleObserver simplifica os testes, reduz a duplicação de código e torna a lógica do ciclo de vida reutilizável em diferentes telas. Esta é uma substituição moderna para a sobrescrita manual de onStart/onStop em cada Activity. Nos aplicativos Android desenvolvidos pela IT Sectr, aplicamos LifecycleObserver para geolocalização, escaneamento Bluetooth e análise — isso reduz o volume de código boilerplate em 30–40%.