Ciclo de vida do aplicativo da Plataforma Universal do Windows (UWP)

  • Artigo

Este tópico descreve o ciclo de vida de um aplicativo da Plataforma Universal do Windows (UWP) desde o momento em que ele é iniciado até ser fechado.

Um pouco de história

Antes do Windows 8, os aplicativos tinham um ciclo de vida simples. Os aplicativos Win32 e .NET estão em execução ou não estão em execução. Quando um usuário os minimiza ou se afasta deles, eles continuam a ser executados. Isso era bom até que os dispositivos portáteis e o gerenciamento de energia se tornassem cada vez mais importantes.

O Windows 8 introduziu um novo modelo de aplicativo com aplicativos UWP. Em um nível alto, um novo estado suspenso foi adicionado. Um aplicativo UWP é suspenso logo após o usuário minimizá-lo ou alternar para outro aplicativo. Isso significa que os threads do aplicativo são interrompidos e o aplicativo é deixado na memória, a menos que o sistema operacional precise recuperar recursos. Quando o usuário alterna de volta para o aplicativo, ele pode ser restaurado rapidamente para um estado de execução.

Há várias maneiras para aplicativos que precisam continuar a ser executados quando estão em segundo plano, como tarefas em segundo plano, execução estendida e execução patrocinada por atividade (por exemplo, o recurso BackgroundMediaEnabled que permite que um aplicativo continue a reproduzir mídia em segundo plano). Além disso, as operações de transferência em segundo plano podem continuar mesmo se seu aplicativo for suspenso ou até mesmo encerrado. Para obter mais informações, consulte Como baixar um arquivo.

Por padrão, os aplicativos que não estão em primeiro plano são suspensos. Isso resulta em economia de energia e mais recursos disponíveis para o aplicativo atualmente em primeiro plano.

O estado suspenso adiciona novos requisitos para você como desenvolvedor porque o sistema operacional pode optar por encerrar um aplicativo suspenso para liberar recursos. O aplicativo encerrado ainda aparecerá na barra de tarefas. Quando o usuário clica nele, o aplicativo deve restaurar o estado em que estava antes de ser encerrado, porque o usuário não estará ciente de que o sistema fechou o aplicativo. Eles pensarão que ele ficou esperando em segundo plano enquanto estavam fazendo outras coisas e esperarão que esteja no mesmo estado em que estavam quando o deixaram. Neste tópico, veremos como fazer isso.

O Windows 10, versão 1607, introduziu mais dois estados de modelo de aplicativo: Executando em primeiro plano e Executando em segundo plano. Examinaremos esses estados adicionais nas seções a seguir.

Estado de execução do aplicativo

Esta ilustração representa os possíveis estados de modelo de aplicativo a partir do Windows 10, versão 1607. Vamos percorrer o ciclo de vida típico de um aplicativo UWP.

state diagram showing transitions between app execution states

Os aplicativos entram em execução em segundo plano quando são iniciados ou ativados. Se o aplicativo precisar se mover para o primeiro plano devido a uma inicialização de aplicativo em primeiro plano, o aplicativo obterá o evento LeavingBackground.

Embora "iniciado" e "ativado" possam parecer termos semelhantes, eles se referem a maneiras diferentes pelas quais o sistema operacional pode iniciar seu aplicativo. Vamos primeiro olhar para o lançamento de um aplicativo.

Inicialização do aplicativo

O método OnLaunched é chamado quando um aplicativo é iniciado. É passado um parâmetro LaunchActivatedEventArgs que fornece, entre outras coisas, os argumentos passados para o aplicativo, o identificador do bloco que iniciou o aplicativo e o estado anterior em que o aplicativo estava.

Obtenha o estado anterior do seu aplicativo de LaunchActivatedEventArgs.PreviousExecutionState, que retorna um ApplicationExecutionState. Seus valores e as medidas apropriadas a serem tomadas devido a esse estado são os seguintes:

ApplicationExecutionState Explicação Ação a ser tomada
NãoExecutando Um aplicativo pode estar nesse estado porque não foi iniciado desde a última vez que o usuário reinicializou ou fez login. Ele também pode estar nesse estado se estava em execução, mas depois travou, ou porque o usuário o fechou antes. Inicialize o aplicativo como se ele estivesse sendo executado pela primeira vez na sessão de usuário atual.
Suspenso O usuário minimizou ou se afastou do seu aplicativo e não retornou a ele em poucos segundos. Quando o aplicativo foi suspenso, seu estado permaneceu na memória. Você só precisa readquirir quaisquer identificadores de arquivo ou outros recursos que você liberou quando o aplicativo foi suspenso.
Terminado O aplicativo foi suspenso anteriormente, mas foi desligado em algum momento porque o sistema precisava recuperar memória. Restaure o estado em que o aplicativo estava quando o usuário se afastou dele.
FechadoPorUsuário O usuário fechou o aplicativo com o botão fechar do sistema ou com Alt+F4. Quando o usuário fecha o aplicativo, ele é primeiro suspenso e, em seguida, encerrado. Como o aplicativo essencialmente passou pelas mesmas etapas que levam ao estado Terminado, manipule isso da mesma maneira que faria com o estado Terminado.
Em execução O aplicativo já estava aberto quando o usuário tentou iniciá-lo novamente. Nada. Observe que outra instância do seu aplicativo não é iniciada. A instância já em execução é simplesmente ativada.

Observação

A sessão de usuário atual é baseada no logon do Windows. Contanto que o usuário atual não tenha feito logoff, desligado ou reiniciado o Windows, a sessão de usuário atual persistirá em eventos como autenticação de tela de bloqueio, usuário de alternância e assim por diante.

Uma circunstância importante a ser observada é que, se o dispositivo tiver recursos suficientes, o sistema operacional pré-lançará aplicativos usados com frequência que optaram por esse comportamento para otimizar a capacidade de resposta. Os aplicativos que são pré-lançados são iniciados em segundo plano e, em seguida, rapidamente suspensos para que, quando o usuário mudar para eles, eles possam ser retomados, o que é mais rápido do que iniciar o aplicativo.

Devido ao pré-lançamento, o método OnLaunched() do aplicativo pode ser iniciado pelo sistema e não pelo usuário. Como o aplicativo é pré-iniciado em segundo plano, talvez seja necessário executar uma ação diferente em OnLaunched(). Por exemplo, se o aplicativo começar a reproduzir música quando iniciado, eles não saberão de onde ele vem porque o aplicativo é pré-iniciado em segundo plano. Depois que seu aplicativo é pré-iniciado em segundo plano, ele é seguido por uma chamada para Application.Suspending. Em seguida, quando o usuário inicia o aplicativo, o evento resuming é chamado, bem como o método OnLaunched(). Consulte Manipular o pré-lançamento do aplicativo para obter informações adicionais sobre como lidar com o cenário de pré-inicialização. Somente os aplicativos que optam por participar são pré-iniciados.

O Windows exibe uma tela inicial para o aplicativo quando ele é iniciado. Para configurar a tela inicial, consulte Adicionando uma tela inicial.

Enquanto a tela inicial é exibida, seu aplicativo deve registrar manipuladores de eventos e configurar qualquer interface do usuário personalizada necessária para a página inicial. Veja que essas tarefas em execução no construtor do aplicativo e OnLaunched() são concluídas em poucos segundos ou o sistema pode achar que seu aplicativo não está respondendo e encerrá-lo. Se um aplicativo precisar solicitar dados da rede ou precisar recuperar grandes quantidades de dados do disco, essas atividades deverão ser concluídas fora da inicialização. Um aplicativo pode usar sua própria interface do usuário de carregamento personalizada ou uma tela inicial estendida enquanto aguarda a conclusão de operações de longa execução. Consulte Exibir uma tela inicial por mais tempo e o Exemplo de tela inicial para obter mais informações.

Depois que o aplicativo concluir a inicialização, ele entrará no estado Em execução e a tela inicial desaparece e todos os recursos e objetos da tela inicial são limpos.

Ativação do aplicativo

Ao contrário de ser iniciado pelo usuário, um aplicativo pode ser ativado pelo sistema. Um aplicativo pode ser ativado por um contrato, como o contrato de compartilhamento. Ou ele pode ser ativado para manipular um protocolo de URI personalizado ou um arquivo com uma extensão que seu aplicativo está registrado para manipular. Para obter uma lista de maneiras pelas quais seu aplicativo pode ser ativado, consulte ActivationKind.

A classe Windows.UI.Xaml.Application define métodos que você pode substituir para manipular as várias maneiras pelas quais seu aplicativo pode ser ativado. OnActivated pode lidar com todos os tipos de ativação possíveis. No entanto, é mais comum usar métodos específicos para lidar com os tipos de ativação mais comuns e usar OnActivated como o método de fallback para os tipos de ativação menos comuns. Estes são os métodos adicionais para ativações específicas:

OnCachedFileUpdaterActivated
OnFileActivated
OnFileOpenPickerActivated OnFileSavePickerActivated
OnSearchActivated
OnShareTargetActivated

Os dados de evento para esses métodos incluem a mesma propriedade PreviousExecutionState que vimos acima, que informa em qual estado seu aplicativo estava antes de ser ativado. Interprete o estado e o que você deve fazer da mesma maneira descrita acima na seção Inicialização do aplicativo.

Observação Se você fizer logon usando a conta de administrador do computador, não poderá ativar aplicativos UWP.

Executando em segundo plano

A partir do Windows 10, versão 1607, os aplicativos podem executar tarefas em segundo plano no mesmo processo que o próprio aplicativo. Leia mais sobre isso em Atividade em segundo plano com o Modelo de Processo Único. Não entraremos no processamento em segundo plano em processo neste artigo, mas como isso afeta o ciclo de vida do aplicativo é que dois novos eventos foram adicionados relacionados a quando seu aplicativo está em segundo plano. São eles: EnteredBackground e LeavingBackground.

Esses eventos também refletem se o usuário pode ver a interface do usuário do seu aplicativo.

A execução em segundo plano é o estado padrão no qual um aplicativo é iniciado, ativado ou retomado. Nesse estado, a interface do usuário do aplicativo ainda não está visível.

Correndo em primeiro plano

A execução em primeiro plano significa que a interface do usuário do seu aplicativo está visível.

O evento LeavingBackground é acionado antes da interface do usuário do aplicativo ficar visível e antes de entrar no estado de execução em primeiro plano. Ele também é acionado quando o usuário alterna de volta para seu aplicativo.

Anteriormente, o melhor local para carregar ativos da interface do usuário era nos manipuladores de eventos Ativado ou Retomando . Agora , LeavingBackground é o melhor lugar para verificar se sua interface do usuário está pronta.

É importante verificar se os ativos visuais estão prontos neste momento, pois esta é a última oportunidade de fazer o trabalho antes que seu aplicativo esteja visível para o usuário. Todo o trabalho da interface do usuário nesse manipulador de eventos deve ser concluído rapidamente, pois isso afeta o tempo de inicialização e retomada que o usuário experimenta. LeavingBackground é o momento de garantir que o primeiro quadro da interface do usuário esteja pronto. Em seguida, as chamadas de rede ou armazenamento de longa execução devem ser tratadas de forma assíncrona para que o manipulador de eventos possa retornar.

Quando o usuário se afasta do aplicativo, ele reentra no estado em execução em segundo plano.

Reinserindo o estado de plano de fundo

O evento EnteredBackground indica que seu aplicativo não está mais visível em primeiro plano. Na área de trabalho , o EnteredBackground é acionado quando seu aplicativo é minimizado, no telefone, ao alternar para a tela inicial ou outro aplicativo.

Reduzir o uso de memória do seu aplicativo

Como seu aplicativo não está mais visível para o usuário, esse é o melhor lugar para interromper o trabalho de renderização e as animações da interface do usuário. Você pode usar LeavingBackground para iniciar esse trabalho novamente.

Se você vai fazer um trabalho em segundo plano, este é o lugar para se preparar para ele. É melhor verificar MemoryManager.AppMemoryUsageLevel e, se necessário, reduzir a quantidade de memória que está sendo usada pelo seu aplicativo quando ele está sendo executado em segundo plano para que seu aplicativo não corra o risco de ser encerrado pelo sistema para liberar recursos.

Consulte Reduzir o uso de memória quando seu aplicativo se move para o estado de segundo plano para obter mais detalhes.

Salve seu estado

O manipulador de eventos de suspensão é o melhor lugar para salvar o estado do aplicativo. No entanto, se você estiver fazendo trabalho em segundo plano (por exemplo, reprodução de áudio, usando uma sessão de execução estendida ou tarefa em segundo plano no processo), também é uma boa prática salvar seus dados de forma assíncrona do manipulador de eventos EnteredBackground . Isso ocorre porque é possível que seu aplicativo seja encerrado enquanto ele estiver em uma prioridade mais baixa em segundo plano. E como o aplicativo não terá passado pelo estado suspenso nesse caso, seus dados serão perdidos.

Salvar seus dados no manipulador de eventos EnteredBackground , antes do início da atividade em segundo plano, garante uma boa experiência do usuário quando o usuário traz seu aplicativo de volta ao primeiro plano. Você pode usar as APIs de dados do aplicativo para salvar dados e configurações. Para obter mais informações, consulte Armazenar e recuperar configurações e outros dados do aplicativo.

Depois de salvar os dados, se você estiver acima do limite de uso de memória, poderá liberar os dados da memória, pois poderá recarregá-los mais tarde. Isso liberará memória que pode ser usada pelos ativos necessários para a atividade em segundo plano.

Lembre-se de que, se seu aplicativo tiver atividade em segundo plano em andamento, ele poderá passar da execução no estado em segundo plano para a execução no estado de primeiro plano sem nunca atingir o estado suspenso.

Observação

Quando seu aplicativo está sendo fechado pelo usuário, é possível que o evento OnSuspending seja acionado antes do evento EnteredBackground . Em alguns casos, o evento EnteredBackground pode não ser acionado antes que o aplicativo seja encerrado. É importante salvar seus dados no manipulador de eventos OnSuspending .

Trabalho assíncrono e diferimentos

Se você fizer uma chamada assíncrona dentro do manipulador, o controle retornará imediatamente dessa chamada assíncrona. Isso significa que a execução pode retornar do manipulador de eventos e seu aplicativo será movido para o próximo estado, mesmo que a chamada assíncrona ainda não tenha sido concluída. Use o método GetDeferral no objeto EnteredBackgroundEventArgs que é passado para o manipulador de eventos para atrasar a suspensão até depois de chamar o método Complete no objeto Windows.Foundation.Deferral retornado.

Um adiamento não aumenta a quantidade de tempo que você precisa para executar seu código antes que seu aplicativo seja encerrado. Ele apenas atrasa a rescisão até que o método completo do diferimento seja chamado ou o prazo passe - o que ocorrer primeiro.

Se você precisar de mais tempo para salvar seu estado, investigue maneiras de salvar seu estado em estágios antes que seu aplicativo entre no estado de segundo plano para que haja menos para salvar no manipulador de eventos OnSuspending . Ou você pode solicitar um ExtendedExecutionSession para obter mais tempo. No entanto, não há garantia de que o pedido será concedido, por isso é melhor encontrar maneiras de minimizar a quantidade de tempo que você precisa para salvar seu estado.

Suspensão do aplicativo

Quando o usuário minimiza um aplicativo, o Windows aguarda alguns segundos para ver se o usuário voltará para ele. Se eles não voltarem dentro dessa janela de tempo e nenhuma execução estendida, tarefa em segundo plano ou execução patrocinada de atividade estiver ativa, o Windows suspenderá o aplicativo. Um aplicativo também é suspenso quando a tela de bloqueio aparece, desde que nenhuma sessão de execução estendida, etc. esteja ativa nesse aplicativo.

Quando um aplicativo é suspenso, ele invoca o evento Application.Suspending. Os modelos de projeto UWP do Visual Studio fornecem um manipulador para esse evento chamado OnSuspending em App.xaml.cs. Você deve colocar o código para salvar o estado do aplicativo aqui.

Você deve liberar recursos exclusivos e identificadores de arquivo para que outros aplicativos possam acessá-los enquanto seu aplicativo está suspenso. Exemplos de recursos exclusivos incluem câmeras, dispositivos de E/S, dispositivos externos e recursos de rede. Liberar explicitamente recursos exclusivos e identificadores de arquivo ajuda a garantir que outros aplicativos possam acessá-los enquanto seu aplicativo está suspenso. Quando o aplicativo for retomado, ele deverá readquirir seus recursos exclusivos e identificadores de arquivo.

Fique atento ao prazo

Para garantir um dispositivo rápido e responsivo, há um limite para a quantidade de tempo que você precisa executar seu código no manipulador de eventos de suspensão. Ele é diferente para cada dispositivo, e você pode descobrir o que ele está usando uma propriedade do objeto SuspendingOperation chamada deadline.

Assim como acontece com o manipulador de eventos EnteredBackground, se você fizer uma chamada assíncrona do manipulador, o controle retornará imediatamente dessa chamada assíncrona. Isso significa que a execução pode retornar do manipulador de eventos e seu aplicativo será movido para o estado de suspensão, mesmo que a chamada assíncrona ainda não tenha sido concluída. Use o método GetDeferral no objeto SuspendingOperation (disponível por meio do evento args) para atrasar a entrada no estado suspenso até depois de chamar o método Complete no objeto SuspendingDeferral retornado.

Se precisar de mais tempo, você pode solicitar um ExtendedExecutionSession. No entanto, não há garantia de que a solicitação será concedida, portanto, é melhor encontrar maneiras de minimizar a quantidade de tempo que você precisa em seu manipulador de eventos Suspenso .

Encerramento do aplicativo

O sistema tenta manter seu aplicativo e seus dados na memória enquanto ele está suspenso. No entanto, se o sistema não tiver os recursos para manter seu aplicativo na memória, ele encerrará seu aplicativo. Os aplicativos não recebem uma notificação de que estão sendo encerrados, portanto, a única oportunidade que você tem de salvar os dados do seu aplicativo é no manipulador de eventos OnSuspending .

Quando seu aplicativo determina que foi ativado após ser encerrado, ele deve carregar os dados do aplicativo que salvou para que o aplicativo esteja no mesmo estado em que estava antes de ser encerrado. Quando o usuário alterna de volta para um aplicativo suspenso que foi encerrado, o aplicativo deve restaurar seus dados de aplicativo em seu método OnLaunched. O sistema não notifica um aplicativo quando ele é encerrado, portanto, seu aplicativo deve salvar seus dados de aplicativo e liberar recursos exclusivos e identificadores de arquivo antes de serem suspensos e restaurá-los quando o aplicativo for ativado após o encerramento.

Uma observação sobre depuração usando o Visual Studio: o Visual Studio impede que o Windows suspenda um aplicativo anexado ao depurador. Isso é para permitir que o usuário exiba a interface do usuário de depuração do Visual Studio enquanto o aplicativo está em execução. Ao depurar um aplicativo, você pode enviar a ele um evento suspend usando o Visual Studio. Verifique se a barra de ferramentas Local de depuração está sendo mostrada e clique no ícone Suspender.

Currículo do aplicativo

Um aplicativo suspenso é retomado quando o usuário alterna para ele ou quando é o aplicativo ativo quando o dispositivo sai de um estado de baixo consumo de energia.

Quando um aplicativo é retomado do estado Suspenso , ele entra no estado Em execução em segundo plano e o sistema restaura o aplicativo de onde parou, para que ele apareça para o usuário como se estivesse sendo executado o tempo todo. Nenhum dado do aplicativo armazenado na memória é perdido. Portanto, a maioria dos aplicativos não precisa restaurar o estado quando eles são retomados, embora eles devem readquirir qualquer arquivo ou identificador de dispositivo que eles lançaram quando foram suspensos e restaurar qualquer estado que foi explicitamente liberado quando o aplicativo foi suspenso.

Seu aplicativo pode ser suspenso por horas ou dias. Se o seu aplicativo tiver conteúdo ou conexões de rede que podem ter ficado obsoletas, elas deverão ser atualizadas quando o aplicativo for retomado. Se um aplicativo registrou um manipulador de eventos para o evento Application.Resuming, ele será chamado quando o aplicativo for retomado do estado Suspenso. Você pode atualizar o conteúdo e os dados do aplicativo nesse manipulador de eventos.

Se um aplicativo suspenso for ativado para participar de um contrato ou extensão de aplicativo, ele receberá o evento Resuming primeiro e, em seguida, o evento Activated .

Se o aplicativo suspenso foi encerrado, não há nenhum evento Resuming e, em vez disso , OnLaunched() é chamado com um ApplicationExecutionState de Terminated. Como você salvou seu estado quando o aplicativo foi suspenso, você pode restaurar esse estado durante OnLaunched() para que seu aplicativo apareça para o usuário como estava quando ele se afastou dele.

Enquanto um aplicativo está suspenso, ele não recebe nenhum evento de rede que ele registrou para receber. Esses eventos de rede não estão na fila - eles são simplesmente perdidos. Portanto, seu aplicativo deve testar o status da rede quando ele for retomado.

Observação Como o evento Resuming não é gerado a partir do thread da interface do usuário, um dispatcher deve ser usado se o código no manipulador de currículo se comunicar com a interface do usuário. Consulte Atualizar o thread da interface do usuário de um thread em segundo plano para obter um exemplo de código de como fazer isso.

Para obter diretrizes gerais, consulte Diretrizes para suspensão e retomada de aplicativos.

Fechar aplicativo

Geralmente, os usuários não precisam fechar aplicativos, eles podem permitir que o Windows os gerencie. No entanto, os usuários podem optar por fechar um aplicativo usando o gesto de fechar ou pressionando Alt+F4 ou usando o seletor de tarefas no Windows Phone.

Não há um evento para indicar que o usuário fechou o aplicativo. Quando um aplicativo é fechado pelo usuário, ele é primeiro suspenso para dar a você a oportunidade de salvar seu estado. No Windows 8.1 e posterior, depois que um aplicativo é fechado pelo usuário, o aplicativo é removido da tela e da lista de opções, mas não é encerrado explicitamente.

Comportamento fechado por usuário: se seu aplicativo precisar fazer algo diferente quando for fechado pelo usuário do que quando for fechado pelo Windows, você poderá usar o manipulador de eventos de ativação para determinar se o aplicativo foi encerrado pelo usuário ou pelo Windows. Consulte as descrições dos estados ClosedByUser e Terminated na referência da enumeração ApplicationExecutionState .

Recomendamos que os aplicativos não se fechem programaticamente, a menos que seja absolutamente necessário. Por exemplo, se um aplicativo detectar um vazamento de memória, ele poderá se fechar para garantir a segurança dos dados pessoais do usuário.

Falha do aplicativo

A experiência de travamento do sistema foi projetada para fazer com que os usuários voltem ao que estavam fazendo o mais rápido possível. Você não deve fornecer uma caixa de diálogo de aviso ou outra notificação porque isso atrasará o usuário.

Se o aplicativo falhar, parar de responder ou gerar uma exceção, um relatório de problemas será enviado à Microsoft de acordo com as configurações de comentários e diagnósticos do usuário. A Microsoft fornece um subconjunto dos dados de erro no relatório de problemas para que você possa usá-lo para melhorar seu aplicativo. Você poderá ver esses dados na página Qualidade do seu aplicativo no seu Painel.

Quando o usuário ativa um aplicativo depois que ele falha, seu manipulador de eventos de ativação recebe um valor ApplicationExecutionState de NotRunning e deve exibir sua interface do usuário e dados iniciais. Após uma falha, não use rotineiramente os dados do aplicativo que você usaria para Retomar com Suspenso porque esses dados podem estar corrompidos, consulte Diretrizes para suspensão e retomada de aplicativos.

Remoção de aplicativos

Quando um usuário exclui seu aplicativo, ele é removido, juntamente com todos os seus dados locais. A remoção de um aplicativo não afeta os dados do usuário que foram armazenados em locais comuns, como as bibliotecas Documentos ou Imagens.

Ciclo de vida do aplicativo e os modelos de projeto do Visual Studio

O código básico que é relevante para o ciclo de vida do aplicativo é fornecido nos modelos de projeto do Visual Studio. O aplicativo básico lida com a ativação de inicialização, fornece um local para você restaurar os dados do aplicativo e exibe a interface do usuário principal antes mesmo de você adicionar qualquer código próprio. Para obter mais informações, consulte Modelos de projeto C#, VB e C++ para aplicativos.

Principais APIs do ciclo de vida do aplicativo