Compartilhar via

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

  • Artigo

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

Um pouco de historia

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. Quando um usuário os minimiza ou se afasta deles, eles continuam a ser executados. Isso foi 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 volta para o aplicativo, ele pode ser restaurado rapidamente para um estado de execução.

Há várias maneiras de os 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 que seu aplicativo seja 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, pois o usuário não saberá que o sistema fechou o aplicativo. Eles pensarão que ele esteve esperando em segundo plano enquanto eles estavam fazendo outras coisas e esperarão que ele esteja no mesmo estado em que estavam quando o deixaram. Neste tópico, veremos como fazer isso.

Windows 10, versão 1607, introduziu mais dois estados de modelo de aplicativo: Executando em primeiro plano e Executando em segundo plano. Veremos 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.

Diagrama de estado mostrando transições entre estados de execução do aplicativo

Os aplicativos entram no estado de execução em segundo plano quando são iniciados ou ativados. Se o aplicativo precisar passar 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 diferentes maneiras pelas quais o sistema operacional pode iniciar seu aplicativo. Vamos primeiro dar uma olhada no lançamento de um aplicativo.

Lançamento do aplicativo

O método OnLaunched é chamado quando um aplicativo é iniciado. Ele é 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 a ação apropriada a ser tomada devido a esse estado são os seguintes:

ApplicationExecutionState Explicação Ação a ser tomada
Não está em execução Um aplicativo pode estar nesse estado porque não foi iniciado desde a última vez que o usuário foi reinicializado ou conectado. Ele também pode estar nesse estado se estiver em execução, mas depois travou, ou porque o usuário o fechou anteriormente. Inicialize o aplicativo como se ele estivesse sendo executado pela primeira vez na sessão do usuário atual.
Suspenso O usuário minimizou ou saiu do seu aplicativo e não retornou a ele em alguns segundos. Quando o aplicativo foi suspenso, seu estado permaneceu na memória. Você só precisa readquirir todos os identificadores de arquivo ou outros recursos liberados 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 saiu dele.
Fechado por usuá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 depois encerrado. Como o aplicativo passou essencialmente pelas mesmas etapas que levam ao estado Terminated, lide com isso da mesma forma que faria com o estado Terminated.
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 do usuário atual é baseada no logon do Windows. Desde que o usuário atual não tenha feito logoff, desligado ou reiniciado o Windows, a sessão do usuário atual persistirá em eventos como autenticação de tela de bloqueio, alternância de usuário e assim por diante.

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

Devido à pré-inicialização, 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 tocar música quando iniciado, eles não saberão de onde ela está vindo porque o aplicativo é pré-iniciado em segundo plano. Depois que seu aplicativo é pré-inicializado em segundo plano, ele é seguido por uma chamada para Application.Suspending. Em seguida, quando o usuário inicia o aplicativo, o evento resuming é invocado, bem como o método OnLaunched(). Consulte Manipular a pré-inicialização do aplicativo para obter informações adicionais sobre como lidar com o cenário de pré-inicialização. Somente os aplicativos que aceitam 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. Verifique se essas tarefas em execução no construtor do aplicativo e em OnLaunched() são concluídas em alguns segundos ou o sistema pode pensar que seu aplicativo não está respondendo e encerrá-lo. Se um aplicativo precisar solicitar dados da rede ou 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 execução longa. Consulte Exibir uma tela inicial para obter mais tempo e o exemplo de tela inicial para obter mais informações.

Depois que o aplicativo conclui a inicialização, ele entra no estado Em execução e a tela inicial desaparece e todos os recursos e objetos da tela inicial são apagados.

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 lidar com 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 lidar com 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:

OnCachedFileUpdaterAtivado
Ativado no arquivo
OnFileOpenPickerAtivado OnFileSavePickerAtivado
OnSearchAtivado
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 no 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 em que 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

Executar em primeiro plano significa que a interface do usuário do seu aplicativo está visível.

O evento LeavingBackground é acionado pouco antes de a 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 volta para o seu aplicativo.

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

É importante verificar se os ativos visuais estão prontos a essa altura, pois essa é a última oportunidade de trabalhar antes que seu aplicativo fique visível para o usuário. Todo o trabalho de interface do usuário nesse manipulador de eventos deve ser concluído rapidamente, pois 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 duração devem ser tratadas de forma assíncrona para que o manipulador de eventos possa retornar.

Quando o usuário sai do aplicativo, ele entra novamente no estado em execução em segundo plano.

Reentrando no estado de fundo

O evento EnteredBackground indica que seu aplicativo não está mais visível em primeiro plano. Na área de trabalho , 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 animações da interface do usuário. Você pode usar LeavingBackground para iniciar esse trabalho novamente.

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

Consulte Reduzir o uso de memória quando seu aplicativo for movido para o estado em 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 trabalhando em segundo plano (por exemplo, reprodução de áudio, usando uma sessão de execução estendida ou uma 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 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 para o 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 seus dados, se você estiver acima do limite de uso de memória, poderá liberar seus 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 o aplicativo tiver atividade em segundo plano em andamento, ele poderá passar do estado de execução em segundo plano para o estado de execução em 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 adiamentos

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 passará 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ê tem para executar seu código antes que seu aplicativo seja encerrado. Ele apenas atrasa a rescisão até que o método Complete do adiamento 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 em segundo plano para que haja menos para salvar em seu manipulador de eventos OnSuspending . Ou você pode solicitar um ExtendedExecutionSession para obter mais tempo. No entanto, não há garantia de que a solicitação será concedida, por isso é melhor encontrar maneiras de minimizar o tempo necessário 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 por 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 no 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 estiver suspenso. Exemplos de recursos exclusivos incluem câmeras, dispositivos de E/S, dispositivos externos e recursos de rede. A liberação explícita de recursos exclusivos e identificadores de arquivo ajuda a garantir que outros aplicativos possam acessá-los enquanto seu aplicativo estiver 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 para executar seu código em seu manipulador de eventos de suspensão. É diferente para cada dispositivo e você pode descobrir o que está usando uma propriedade do objeto SuspendingOperation chamada prazo.

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 dos argumentos de evento) 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 necessária 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 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 ele salvou para que o aplicativo esteja no mesmo estado em que estava antes de ser encerrado. Quando o usuário 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 os dados do aplicativo e liberar recursos exclusivos e identificadores de arquivo antes de ser suspenso e restaurá-los quando o aplicativo for ativado após o encerramento.

Uma observação sobre a 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 de suspensão usando o Visual Studio. Verifique se a barra de ferramentas Local de Depuração está sendo mostrada e clique no ícone Suspender .

Resumo 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 baixa 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 em execução o tempo todo. Nenhum dado de aplicativo armazenado na memória é perdido. Portanto, a maioria dos aplicativos não precisa restaurar o estado quando são retomados, embora devam readquirir todos os identificadores de arquivo ou dispositivo que liberaram 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 aplicativo tiver conteúdo ou conexões de rede que possam ter ficado obsoletos, eles deverão ser atualizados 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 Suspended . Você pode atualizar o conteúdo e os dados do aplicativo neste 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 haverá nenhum evento Resuming e, em vez disso , OnLaunched() será 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 saiu 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 são enfileirados - 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 do thread da interface do usuário, um dispatcher deve ser usado se o código no manipulador de retomada 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 do aplicativo.

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 alternador de tarefas no Windows Phone.

Não há um evento que indique que o usuário fechou o aplicativo. Quando um aplicativo é fechado pelo usuário, ele é suspenso primeiro 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 alternância, mas não é encerrado explicitamente.

Comportamento fechado pelo usuário: se o aplicativo precisar fazer algo diferente quando for fechado pelo usuário e 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 falha do sistema foi projetada para levar os usuários de volta 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, pois 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 diagnóstico e comentários 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 do aplicativo.

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 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. Para obter mais informações, consulte Modelos de projeto C#, VB e C++ para aplicativos.

Principais APIs do ciclo de vida do aplicativo