Ciclo de vida da atividade

À medida que um usuário navega pelo app, sai dele e volta, as instâncias de Activity no app passam por diferentes estados no ciclo de vida. A classe Activity fornece vários callbacks que informam à atividade quando um estado muda ou quando o sistema está criando, interrompendo ou retomando uma atividade ou destruindo o processo em que ela reside.

Nos métodos de callback do ciclo de vida, é possível declarar como a atividade se comporta quando o usuário sai e entra novamente nela. Por exemplo, se você estiver criando um player de streaming de vídeo, pause o vídeo e encerre a conexão de rede quando o usuário mudar para outro app. Quando o usuário retornar, reconecte-se à rede e permita que ele retome o vídeo do mesmo ponto.

Cada callback permite que você realize um trabalho específico que seja apropriado para uma determinada mudança de estado. Fazer o trabalho certo no momento certo e lidar com as transições adequadamente torna seu app mais robusto e eficiente. Por exemplo, uma boa implementação dos callbacks do ciclo de vida pode ajudar seu app a evitar o seguinte:

  • Falhar se o usuário receber uma ligação ou mudar para outro app enquanto usa o seu.
  • Consumir recursos valiosos do sistema quando o usuário não está usando o app ativamente.
  • Perder o progresso do usuário se ele sair do app e voltar mais tarde.
  • Falha ou perda do progresso do usuário quando a tela gira entre as orientações paisagem e retrato.

Este documento explica detalhadamente o ciclo de vida da atividade. O documento começa descrevendo o paradigma do ciclo de vida. Em seguida, explica cada um dos callbacks: o que acontece internamente durante a execução e o que você precisa implementar durante eles.

Em seguida, ele apresenta brevemente a relação entre o estado da atividade e a vulnerabilidade de um processo de ser encerrado pelo sistema. Por fim, ele aborda vários tópicos relacionados às transições entre estados de atividade.

Para saber como processar ciclos de vida, incluindo orientações sobre práticas recomendadas, consulte Ciclo de vida no Jetpack Compose e Salvar estados da IU. Para saber como arquitetar um app robusto e de qualidade de produção usando atividades em combinação com componentes de arquitetura, consulte o Guia para a arquitetura do app.

Conceitos do ciclo de vida da atividade

Para navegar pelas transições entre os estágios do ciclo de vida da atividade, a classe Activity oferece um conjunto principal de seis callbacks: onCreate, onStart, onResume, onPause, onStop e onDestroy. O sistema invoca cada um desses callbacks conforme a atividade entra em um novo estado.

A Figura 1 apresenta uma representação visual desse paradigma.

Figura 1. Uma ilustração simplificada do ciclo de vida da atividade.

Quando o usuário começa a sair da atividade, o sistema chama métodos para desativar a atividade. Em alguns casos, a atividade é apenas parcialmente desativada e ainda permanece na memória, como quando o usuário muda para outro app. Nesses casos, a atividade ainda pode voltar ao primeiro plano.

Se o usuário retornar à atividade, ela será retomada de onde parou. Com algumas exceções, os apps são impedidos de iniciar atividades quando estão em execução em segundo plano.

A probabilidade de o sistema encerrar um determinado processo, junto com as atividades nele, depende do estado da atividade no momento. Para mais informações sobre a relação entre o estado e a vulnerabilidade à remoção, consulte a seção sobre estado da atividade e remoção da memória.

Dependendo da complexidade de sua atividade, não é necessário implementar todos os métodos do ciclo de vida. No entanto, é importante que você entenda cada um deles e implemente os que fazem o app se comportar da maneira esperada pelos usuários.

Compose e o ciclo de vida

No Compose, evite colocar a lógica de negócios ou a configuração manual do observador diretamente em callbacks de atividade, como onStart ou onResume. Em vez disso, use efeitos que reconhecem o ciclo de vida e observadores que reconhecem o estado e se alinham automaticamente com a presença da interface na tela.

  • Coleta com reconhecimento de ciclo de vida: use collectAsStateWithLifecycle para consumir fluxos da sua ViewModel. Essa API começa a coletar automaticamente quando a IU entra no estado Started e para quando ela vai para o segundo plano, evitando o consumo desnecessário de recursos. Depois de coletar o fluxo como estado, use LifecycleEffects para executar o código quando um evento de ciclo de vida ocorrer.
  • Fluxo de lógica: ao usar essas APIs, a interface reage ao estado do ciclo de vida naturalmente pela árvore de composição, garantindo que a lógica de negócios só seja executada quando o usuário estiver interagindo ativamente com o componente.

Para saber mais sobre o Compose e o ciclo de vida, consulte Ciclo de vida no Jetpack Compose.

Callbacks do ciclo de vida

Nesta seção, você encontra informações conceituais e de implementação sobre os métodos de callback usados durante o ciclo de vida da atividade.

Algumas ações pertencem aos métodos do ciclo de vida da atividade. No entanto, coloque o código que implementa as ações de um componente dependente no componente, em vez de no método do ciclo de vida da atividade. Para isso, é preciso tornar o componente dependente compatível com o ciclo de vida. Para saber como tornar seus componentes dependentes cientes do ciclo de vida, consulte Ciclo de vida no Jetpack Compose.

onCreate

Esse callback precisa ser implementado. Ele é acionado assim que o sistema cria a atividade. Quando a atividade é criada, ela insere o estado Criado. No método onCreate, execute a lógica básica de inicialização do aplicativo que acontece apenas uma vez durante todo o ciclo de vida da atividade.

Por exemplo, sua implementação de onCreate pode vincular dados a listas, associar a atividade a um ViewModel e instanciar algumas variáveis de escopo de classe. Esse método recebe o parâmetro savedInstanceState, que é um objeto Bundle que contém o estado salvo anteriormente da atividade. Se a atividade nunca tiver existido antes, o valor do objeto Bundle será nulo.

Se você tiver um componente que reconhece o ciclo de vida conectado ao ciclo de vida da sua atividade, ele vai receber o evento ON_CREATE. O método anotado com @OnLifecycleEvent é chamado para que o componente que reconhece o ciclo de vida possa executar qualquer código de configuração necessário para o estado criado.

O exemplo abaixo mostra como integrar um elemento de composição Text em uma atividade mínima:

class ExampleActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent { // In here, we can call composables!
            MaterialTheme {
                Greeting(name = "compose")
            }
        }
    }
}

@Composable
fun Greeting(name: String) {
    Text(text = "Hello $name!")
}

A atividade não permanece no estado "Criada". Depois que o método onCreate conclui a execução, a atividade entra no estado Started e o sistema chama os métodos onStart e onResume em rápida sucessão.

onStart

Quando a atividade entra no estado Started, o sistema invoca onStart. Essa chamada torna a atividade visível para o usuário enquanto o app se prepara para que ela entre em primeiro plano e se torne interativa. Por exemplo, esse método é onde o código que mantém a interface é inicializado.

Quando a atividade passa para o estado Started, qualquer componente que reconhece o ciclo de vida vinculado a ela recebe o evento ON_START.

O método onStart é concluído rapidamente e, assim como no estado Created, a atividade não permanece no estado Started. Depois que esse callback é concluído, a atividade entra no estado Resumed e o sistema invoca o método onResume.

onResume

Quando a atividade entra no estado retomado, ela vai para o primeiro plano, e o sistema invoca o callback onResume. É nesse estado que o aplicativo interage com o usuário. O app permanece nesse estado até que algo aconteça para tirar o foco dele, como o dispositivo receber uma ligação, o usuário navegar para outra atividade ou a tela do dispositivo ser desligada.

Quando a atividade passa para o estado retomado, qualquer componente que reconhece o ciclo de vida vinculado a ela recebe o evento ON_RESUME. É aqui que os componentes de ciclo de vida podem ativar qualquer funcionalidade que precise ser executada enquanto o componente estiver visível e em primeiro plano, como iniciar uma prévia da câmera.

Quando ocorre um evento de interrupção, a atividade entra no estado Paused e o sistema invoca o callback onPause.

Se a atividade retornar do estado Pausado para o estado Retomado, o sistema chamará novamente o método onResume. Por isso, implemente onResume para inicializar componentes que você libera durante onPause e para realizar outras inicializações que precisam ocorrer sempre que a atividade entra no estado "Retomada".

Veja um exemplo de um componente com reconhecimento de ciclo de vida que acessa a câmera quando recebe o evento ON_RESUME:

class CameraComponent : LifecycleObserver {
    ...
    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun initializeCamera() {
        if (camera == null) {
            getCamera()
        }
    }
    ...
}

O código anterior inicializa a câmera quando o LifecycleObserver recebe o evento ON_RESUME. No entanto, no modo de várias janelas, a atividade pode ficar totalmente visível mesmo quando está no estado Pausado. Por exemplo, quando o app está no modo de várias janelas e o usuário toca na janela que não contém sua atividade, ela passa para o estado Pausada.

Se você quiser que a câmera fique ativa apenas quando o app for retomado (visível e ativo em primeiro plano), inicialize a câmera após o evento ON_RESUME demonstrado anteriormente. Se você quiser manter a câmera ativa enquanto a atividade estiver pausada, mas visível, como no modo de várias janelas, inicialize a câmera após o evento ON_START.

No entanto, manter a câmera ativa enquanto a atividade está pausada pode negar o acesso à câmera a outro app retomado no modo de várias janelas. Às vezes, é necessário manter a câmera ativa enquanto a atividade está pausada, mas isso pode prejudicar a experiência geral do usuário.

Por isso, pense com cuidado em que momento do ciclo de vida é mais adequado assumir o controle dos recursos compartilhados do sistema no contexto do modo de várias janelas. Para saber mais sobre como oferecer suporte ao modo de várias janelas, consulte Oferecer suporte ao modo de várias janelas.

Independentemente do evento de criação escolhido para realizar uma operação de inicialização, use o evento de ciclo de vida correspondente para liberar o recurso. Se você inicializar algo após o evento ON_START, libere ou encerre após o evento ON_STOP. Se você inicializar após o evento ON_RESUME, libere após o evento ON_PAUSE.

O snippet de código anterior coloca o código de inicialização da câmera em um componente que reconhece o ciclo de vida. Você pode colocar esse código diretamente nos callbacks do ciclo de vida da atividade, como onStart e onStop, mas não recomendamos isso. Adicionar essa lógica a um componente independente e com reconhecimento de ciclo de vida permite reutilizar o componente em várias atividades sem precisar duplicar o código. Para saber como criar um componente que reconhece o ciclo de vida, consulte Ciclo de vida no Jetpack Compose.

onPause

O sistema chama esse método como a primeira indicação de que o usuário está saindo da atividade, embora isso nem sempre signifique que ela está sendo destruída. Ele indica que a atividade não está mais em primeiro plano, mas ainda está visível se o usuário estiver no modo de várias janelas. Há vários motivos para uma atividade entrar nesse estado:

  • Um evento que interrompe a execução do app, conforme descrito na seção sobre o callback onResume, pausa a atividade atual. Esse é o caso mais comum.
  • No modo de várias janelas, apenas um app tem o foco por vez, e o sistema pausa todos os outros.
  • A abertura de uma nova atividade semitransparente, como uma caixa de diálogo, pausa a atividade que ela cobre. Enquanto a atividade estiver parcialmente visível, mas não em foco, ela vai permanecer pausada.

Quando uma atividade passa para o estado Pausado, qualquer componente que reconhece o ciclo de vida vinculado a ela recebe o evento ON_PAUSE. É aqui que os componentes do ciclo de vida podem interromper qualquer funcionalidade que não precise ser executada enquanto o componente não estiver em primeiro plano, como interromper uma visualização da câmera.

Use o método onPause para pausar ou ajustar operações que não podem continuar ou que podem continuar com moderação enquanto o Activity está no estado Pausado e que você espera retomar em breve.

Você também pode usar o método onPause para liberar recursos do sistema, identificadores de sensores (como GPS) ou qualquer recurso que afete a duração da bateria enquanto a atividade estiver pausada e o usuário não precisar deles.

No entanto, conforme mencionado na seção sobre onResume, uma atividade pausada ainda pode ficar totalmente visível se o app estiver no modo de várias janelas. Considere usar onStop em vez de onPause para liberar ou ajustar totalmente os recursos relacionados à interface e as operações para oferecer melhor suporte ao modo de várias janelas.

O exemplo a seguir de um LifecycleObserver reagindo ao evento ON_PAUSE é o equivalente ao exemplo de evento ON_RESUME anterior, liberando a câmera que é inicializada após o recebimento do evento ON_RESUME:

class CameraComponent : LifecycleObserver {
    ...
    @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    fun releaseCamera() {
        camera?.release()
        camera = null
    }
    ...
}

Este exemplo coloca o código de liberação da câmera depois que o evento ON_PAUSE é recebido pelo LifecycleObserver.

A execução de onPause é muito breve e não oferece necessariamente tempo suficiente para realizar operações de salvamento. Por esse motivo, não use onPause para salvar dados do aplicativo ou do usuário, fazer chamadas de rede ou executar transações de banco de dados. Esse trabalho pode não ser concluído antes do método.

Em vez disso, realize operações de encerramento de carga pesada durante onStop. Para mais informações sobre operações adequadas para realizar durante onStop, consulte a próxima seção. Para mais informações sobre como salvar dados, consulte a seção sobre como salvar e restaurar o estado.

A conclusão do método onPause não significa que a atividade sai do estado Pausado. Em vez disso, a atividade permanece nesse estado até que seja retomada ou se torne completamente invisível para o usuário. Se a atividade for retomada, o sistema vai invocar o callback onResume novamente.

Se a atividade retornar do estado Pausado para o estado Retomado, o sistema vai manter a instância Activity residente na memória, recuperando-a quando o sistema invocar onResume. Nesse cenário, não é necessário reinicializar os componentes criados durante os métodos de callback que levam ao estado Retomado. Se a atividade ficar completamente invisível, o sistema vai chamar onStop.

onStop

Quando a atividade não está mais visível para o usuário, ela entra no estado Interrompida, e o sistema invoca o callback onStop. Isso pode ocorrer quando uma atividade recém-iniciada cobre toda a tela. O sistema também chama onStop quando a atividade termina de ser executada e está prestes a ser encerrada.

Quando a atividade passa para o estado "Stopped", qualquer componente que reconhece o ciclo de vida vinculado a ela recebe o evento ON_STOP. É nesse momento que os componentes do ciclo de vida podem interromper qualquer funcionalidade que não precise operar enquanto o componente não estiver visível na tela.

No método onStop, libere ou ajuste os recursos que não são necessários enquanto o app não está visível para o usuário. Por exemplo, o app pode pausar animações ou mudar de atualizações do local detalhadas para aproximadas. Usar onStop em vez de onPause significa que o trabalho relacionado à interface continua, mesmo quando o usuário está visualizando sua atividade no modo de várias janelas.

Além disso, use onStop para realizar operações de encerramento com uso intensivo da CPU. Por exemplo, se você não encontrar um momento melhor para salvar informações em um banco de dados, faça isso durante onStop. O exemplo a seguir mostra uma implementação de onStop que salva o conteúdo de um rascunho de nota no armazenamento persistente:

override fun onStop() {
    super.onStop()

    // Delegate the save operation to the ViewModel, which handles the
    // background thread operations (e.g., using Kotlin Coroutines and Room).
    noteViewModel.saveDraft()
}

Quando a atividade entra no estado "Interrompida", o objeto Activity é mantido na memória: ele mantém todas as informações de estado e de membros, mas não está anexado ao gerenciador de janelas. Quando a atividade é retomada, ela recupera essas informações.

A partir do estado "Interrompido", a atividade volta a interagir com o usuário ou para de operar e é encerrada. Se a atividade voltar, o sistema vai invocar onRestart. Se a execução do Activity for concluída, o sistema vai chamar onDestroy.

onDestroy

onDestroy é chamado antes que a atividade seja destruída. O sistema invoca esse callback por um destes dois motivos:

  1. A atividade está sendo encerrada porque o usuário a dispensou completamente ou porque finish foi chamado nela.
  2. O sistema está destruindo temporariamente a atividade devido a uma mudança de configuração, como a rotação do dispositivo ou a entrada no modo de várias janelas.

Quando a atividade passa para o estado destruído, qualquer componente que reconhece o ciclo de vida vinculado ao ciclo de vida da atividade recebe o evento ON_DESTROY. É onde os componentes do ciclo de vida podem limpar o que for necessário antes que o Activity seja destruído.

Em vez de colocar lógica no Activity para determinar por que ele está sendo destruído, use um objeto ViewModel para conter os dados de visualização relevantes para o Activity. Se a Activity for recriada devido a uma mudança de configuração, o ViewModel não precisará fazer nada, já que ele é preservado e fornecido para a próxima instância de Activity.

Se a Activity não for recriada, a ViewModel vai ter a chamada de método onCleared, em que pode limpar todos os dados necessários antes de ser destruída. É possível distinguir entre esses dois cenários com o método isFinishing.

Se a atividade estiver sendo concluída, onDestroy será o callback do ciclo de vida final que ela vai receber. Se onDestroy for chamado como resultado de uma mudança de configuração, o sistema vai criar imediatamente uma nova instância de atividade e chamar onCreate nessa nova instância na nova configuração.

O callback onDestroy libera todos os recursos que não foram liberados por callbacks anteriores, como onStop.

Estado da atividade e ejeção da memória

O sistema encerra processos quando precisa liberar RAM. A probabilidade de o sistema encerrar um determinado processo depende do estado dele no momento. O estado do processo, por sua vez, depende do estado da atividade em execução no processo. A Tabela 1 mostra as correlações entre o estado do processo, o estado da atividade e a probabilidade de o sistema encerrar o processo. Esta tabela só se aplica se um processo não estiver executando outros tipos de componentes de aplicativo.

Probabilidade de eliminação

Estado do processo

Estado final da atividade

Mais baixa

Em primeiro plano (com foco ou prestes a ter)

Retomada

Baixo

Visível (sem foco)

Iniciado/Pausado

Maior

Segundo plano (invisível)

Interrompido

Mais alta

Vazio

Destruído

Tabela 1. Relação entre o ciclo de vida do processo e o estado da atividade.

O sistema nunca elimina uma atividade diretamente para liberar memória. Em vez disso, ele encerra o processo em que a atividade é executada, destruindo não apenas a atividade, mas também tudo o que está sendo executado no processo. Para saber como preservar e restaurar o estado da interface da atividade quando ocorre o encerramento do processo iniciado pelo sistema, consulte a seção sobre como salvar e restaurar o estado.

O usuário também pode encerrar um processo usando o Gerenciador de Aplicativos, em "Configurações", para encerrar o app correspondente.

Para mais informações sobre processos, consulte Visão geral dos processos e linhas de execução.

Como salvar e restaurar o estado transitório da IU

O usuário espera que o estado da interface de uma atividade permaneça o mesmo durante uma mudança de configuração, como girar ou mudar o dispositivo para o modo de várias janelas. No entanto, o sistema destrói a atividade por padrão quando ocorre uma mudança de configuração. Isso exclui qualquer estado de IU armazenado na instância da atividade.

Da mesma forma, o usuário espera que o estado da interface permaneça o mesmo se ele sair temporariamente do seu app para outro e depois voltar. No entanto, o sistema pode destruir o processo do aplicativo enquanto o usuário está ausente e a atividade está interrompida.

Quando as restrições do sistema destruírem a atividade, preserve o estado transitório da interface do usuário usando uma combinação de ViewModel (para lógica de negócios complexa e estado da tela), a API rememberSaveable do Jetpack Compose (para estado leve da interface) e/ou armazenamento local. Para saber mais sobre as expectativas do usuário em comparação com o comportamento do sistema e como preservar melhor os dados complexos de estado da interface em atividades iniciadas pelo sistema e encerramento de processos, consulte Salvar estados da interface.

O rememberSaveable sobrevive automaticamente às mudanças de configuração e ao encerramento do processo iniciado pelo sistema, agrupando o estado em segundo plano e oferecendo uma experiência perfeita sem a necessidade de código boilerplate no nível da atividade.

Estado da instância

Há alguns cenários em que a atividade é destruída devido ao comportamento normal do app, como quando o usuário pressiona o botão "Voltar" ou quando a atividade sinaliza a própria destruição chamando o método finish.

Quando a atividade é destruída porque o usuário pressiona "Voltar" ou porque ela é encerrada, o conceito do sistema e do usuário sobre essa instância de Activity desaparece para sempre. Nesses cenários, a expectativa do usuário corresponde ao comportamento do sistema, e você não precisa fazer nenhum trabalho extra.

No entanto, se o sistema destruir a atividade devido a restrições do sistema (como uma mudança de configuração ou pressão de memória), embora a instância real de Activity não exista mais, o sistema vai se lembrar de que ela existiu. Se o usuário tentar voltar para a atividade, o sistema vai criar uma nova instância dela usando um conjunto de dados salvos que descreve o estado da atividade quando ela foi destruída.

Os dados salvos que o sistema usa para restaurar o estado anterior são chamados de estado da instância. Por trás dos panos, é uma coleção de pares de chave-valor. Por padrão, o sistema usa o estado da instância para salvar informações básicas sobre o layout da interface, como entrada de texto do usuário ou posições de rolagem.

Você se conecta a esse comportamento do sistema usando rememberSaveable. Se a instância de atividade for destruída e recriada, qualquer estado da interface encapsulado em rememberSaveable será restaurado automaticamente, sem que você precise de mais código no nível da atividade.

No entanto, é provável que sua atividade tenha informações de estado mais complexas que você queira restaurar, como dados do usuário, respostas de rede ou variáveis de membro que acompanham o progresso do usuário. O mecanismo de estado da instância (e, por extensão, rememberSaveable) não é adequado para preservar mais do que uma quantidade trivial de dados, porque requer serialização na linha de execução principal e consome memória do processo do sistema.

Para preservar mais do que uma quantidade muito pequena de dados, use uma abordagem combinada com armazenamento local persistente, a classe ViewModel e a elevação de estado do Compose, conforme descrito em Salvar estados da interface.

Salvar o estado simples e leve da interface usando rememberSaveable

Quando a atividade começa a ser interrompida, o sistema se prepara para salvar as informações de estado em um pacote de estado de instância. Para se conectar a esse comportamento do sistema, use rememberSaveable diretamente nas funções combináveis. O rememberSaveable salva e restaura automaticamente o estado transitório da interface, como entrada de texto do usuário ou posições de rolagem, durante a recriação da atividade.

Para salvar informações de estado personalizadas e leves (como o progresso de um usuário em um jogo), declare seu estado usando rememberSaveable. O framework do Compose processa a serialização para o pacote de estado da instância em segundo plano:

var userTypedQuery by rememberSaveable(typedQuery, stateSaver = TextFieldValue.Saver) {
    mutableStateOf(
        TextFieldValue(text = typedQuery, selection = TextRange(typedQuery.length))
    )
}

Para salvar dados persistentes, como preferências do usuário ou dados de um banco de dados, aproveite as oportunidades adequadas quando a atividade estiver em primeiro plano. Se essa oportunidade não surgir, salve os dados persistentes durante o método onStop.

Restaurar o estado de IU da atividade por meio de um estado da instância salvo

Quando a atividade é recriada depois de ter sido destruída, a restauração do estado é automática. Ao usar rememberSaveable, não é necessário escrever nenhuma lógica de restauração explícita, verificar se há pacotes nulos ou substituir callbacks de atividade. O código que inicializa e salva o estado também o restaura sem problemas quando a atividade é retomada:

var userTypedQuery by rememberSaveable(typedQuery, stateSaver = TextFieldValue.Saver) {
    mutableStateOf(
        TextFieldValue(text = typedQuery, selection = TextRange(typedQuery.length))
    )
}

Atividades e navegação

É provável que um app faça a transição entre telas muitas vezes durante o ciclo de vida, como quando o usuário toca no botão "Voltar" do dispositivo ou seleciona um novo destino. Os apps Android modernos geralmente usam uma arquitetura de atividade única. Em vez de iniciar uma nova Activity para cada tela, seu app hospeda uma única Activity e usa o componente Navigation para trocar telas de composição dentro dessa atividade.

Para saber como implementar uma navegação moderna que prioriza o Compose, consulte o guia da biblioteca Navigation 3 do Jetpack Compose.

Como iniciar uma atividade a partir de outra

Uma atividade pode precisar iniciar outra em algum momento. Essa necessidade surge, por exemplo, quando um app precisa passar da tela atual para uma nova.

Dependendo se a atividade quer ou não um resultado da nova atividade que está prestes a começar, você inicia a nova atividade usando o método startActivity ou startActivityForResult. Em ambos os casos, você transmite um objeto Intent.

O objeto Intent especifica a atividade exata que você quer iniciar ou descreve o tipo de ação que você quer realizar. O sistema seleciona a atividade adequada para você, que pode até ser de um aplicativo diferente. Um objeto Intent também pode transportar pequenas quantidades de dados para serem usados pela atividade iniciada. Para mais informações sobre a classe Intent, consulte Intents e filtros de intents.

startActivity

Se a atividade recém-iniciada não precisar retornar um resultado, a atividade atual poderá iniciá-la chamando o método startActivity.

Ao trabalhar no seu próprio aplicativo, geralmente você só precisa iniciar uma atividade conhecida. Por exemplo, o snippet de código abaixo mostra como iniciar uma atividade chamada SignInActivity.

val context = LocalContext.current

Button(onClick = {
    val intent = Intent(context, SignInActivity::class.java)
    context.startActivity(intent)
}) {
    Text("Sign In")
}

Como iniciar atividades externas

Enquanto a navegação interna do app é processada por Navigation, seu Activity ocasionalmente precisará iniciar outras atividades. Isso geralmente acontece quando você quer usar um app externo para realizar uma ação específica, como abrir um navegador da Web, enviar um e-mail ou tirar uma foto.

Para isso, use um objeto Intent para descrever o tipo de ação que você quer realizar, e o sistema vai iniciar a atividade adequada de outro aplicativo.

Por exemplo, se você quiser permitir que o usuário envie uma mensagem de e-mail, crie a seguinte intent:

val intent = Intent(Intent.ACTION_SEND).apply {
    putExtra(Intent.EXTRA_EMAIL, recipientArray)
}
startActivity(intent)

Se você precisar iniciar uma atividade externa e receber um resultado (como pedir ao app de câmera para tirar uma foto e retornar a imagem), use as Activity APIs de resultado modernas em vez do callback startActivityForResult descontinuado.

Coordenação de atividades

Quando uma atividade inicia outra, ambas passam por transições no ciclo de vida. A primeira atividade para de funcionar e entra no estado Pausada ou Interrompida, enquanto a outra atividade é criada. Caso essas atividades compartilhem dados salvos no disco ou em outro lugar, é importante entender que a primeira atividade não é completamente interrompida antes que a segunda seja criada. Em vez disso, o processo de inicialização do segundo se sobrepõe ao processo de interrupção do primeiro.

A ordem dos callbacks do ciclo de vida é bem definida, principalmente quando as duas atividades estão no mesmo processo (ou seja, no mesmo app) e uma está iniciando a outra. Esta é a ordem das operações que ocorrem quando a atividade A inicia a atividade B:

  1. O método onPause da atividade A é executado.
  2. Os métodos onCreate, onStart e onResume da atividade B são executados em sequência. A atividade B agora tem o foco do usuário.
  3. Se a Atividade A não estiver mais visível na tela, o método onStop dela será executado.

Essa sequência de callbacks do ciclo de vida permite gerenciar a transição de informações de uma atividade para outra.

Outros recursos

Para saber mais sobre o ciclo de vida da atividade, consulte os seguintes recursos adicionais:

Visualiza conteúdo