cycle de vie de l’application plateforme Windows universelle (UWP)

Cette rubrique décrit le cycle de vie d’une application plateforme Windows universelle (UWP) à partir du moment où elle est lancée jusqu’à sa fermeture.

Un peu d’histoire

Avant Windows 8, les applications avaient un cycle de vie simple. Les applications Win32 et .NET s’exécutent ou ne s’exécutent pas. Lorsqu’un utilisateur les réduit ou s’éloigne de lui, il continue à s’exécuter. C’était bien jusqu’à ce que les appareils portables et la gestion de l’alimentation deviennent de plus en plus importants.

Windows 8 a introduit un nouveau modèle d’application avec des applications UWP. À un niveau élevé, un nouvel état suspendu a été ajouté. Une application UWP est suspendue peu après que l’utilisateur le réduit ou bascule vers une autre application. Cela signifie que les threads de l’application sont arrêtés et que l’application est laissée en mémoire, sauf si le système d’exploitation doit récupérer des ressources. Lorsque l’utilisateur revient à l’application, il peut être rapidement restauré dans un état en cours d’exécution.

Il existe différentes façons pour les applications qui doivent continuer à s’exécuter lorsqu’elles se trouvent en arrière-plan, telles que les tâches en arrière-plan, l’exécution étendue et l’exécution parrainée par l’activité (par exemple, la fonctionnalité BackgroundMediaEnabled qui permet à une application de continuer à lire des médias en arrière-plan). En outre, les opérations de transfert en arrière-plan peuvent continuer même si votre application est suspendue ou même arrêtée. Pour plus d’informations, consultez Comment télécharger un fichier.

Par défaut, les applications qui ne sont pas au premier plan sont suspendues. Cela entraîne des économies d’énergie et davantage de ressources disponibles pour l’application actuellement au premier plan.

L’état suspendu ajoute de nouvelles exigences pour vous en tant que développeur, car le système d’exploitation peut choisir de mettre fin à une application suspendue afin de libérer des ressources. L’application arrêtée apparaît toujours dans la barre des tâches. Lorsque l’utilisateur clique dessus, l’application doit restaurer l’état dans lequel elle se trouvait avant son arrêt, car l’utilisateur ne sait pas que le système a fermé l’application. Ils penseront qu’il attendait en arrière-plan pendant qu’ils faisaient d’autres choses et s’attendront à ce qu’il soit dans le même état qu’au moment où ils l’ont quitté. Dans cette rubrique, nous allons examiner comment procéder.

Windows 10, version 1607, a introduit deux états de modèle d’application supplémentaires : En cours d’exécution au premier plan et en cours d’exécution en arrière-plan. Nous examinerons ces états supplémentaires dans les sections qui suivent.

État d’exécution de l’application

Cette illustration représente les états possibles du modèle d’application à partir de Windows 10, version 1607. Examinons le cycle de vie classique d’une application UWP.

Les applications entrent dans l’état en arrière-plan lorsqu’elles sont lancées ou activées. Si l’application doit se déplacer au premier plan en raison d’un lancement d’application de premier plan, l’application obtient l’événement LeavingBackground .

Bien que les termes « lancés » et « activés » ressemblent à des termes similaires, ils font référence à différentes façons dont le système d’exploitation peut démarrer votre application. Examinons d’abord le lancement d’une application.

Lancement de l’application

La méthode OnLaunched est appelée lorsqu’une application est lancée. Il est passé un paramètre LaunchActivatedEventArgs qui fournit, entre autres, les arguments passés à l’application, l’identificateur de la vignette qui a lancé l’application et l’état précédent dans lequel l’application était présente.

Obtenez l’état précédent de votre application à partir de LaunchActivatedEventArgs.PreviousExecutionState qui retourne une applicationExecutionState. Ses valeurs et l’action appropriée à entreprendre en raison de cet état sont les suivantes :

L’une des circonstances importantes à prendre en compte est que si l’appareil dispose de ressources suffisantes, le système d’exploitation prélance les applications fréquemment utilisées qui ont choisi ce comportement afin d’optimiser la réactivité. Les applications qui sont prélancées sont lancées en arrière-plan, puis rapidement suspendues afin que lorsque l’utilisateur les bascule, ils peuvent être repris plus rapidement que le lancement de l’application.

En raison de la prélancement, la méthode OnLaunched() de l’application peut être lancée par le système plutôt que par l’utilisateur. Étant donné que l’application est prélancée en arrière-plan, vous devrez peut-être effectuer différentes actions dans OnLaunched(). Par exemple, si votre application commence à lire de la musique lors du lancement, elle ne sait pas où elle provient, car l’application est prélancée en arrière-plan. Une fois que votre application est prélancée en arrière-plan, elle est suivie d’un appel à Application.Suspending. Ensuite, lorsque l’utilisateur lance l’application, l’événement de reprise est appelé ainsi que la méthode OnLaunched(). Pour plus d’informations sur la gestion du scénario de prélancement, consultez Gérer la prélancement de l’application. Seules les applications qui optent sont prélancées.

Windows affiche un écran de démarrage pour l’application lorsqu’elle est lancée. Pour configurer l’écran de démarrage, consultez Ajout d’un écran de démarrage.

Pendant que l’écran de démarrage s’affiche, votre application doit inscrire des gestionnaires d’événements et configurer toute interface utilisateur personnalisée dont elle a besoin pour la page initiale. Vérifiez que ces tâches s’exécutent dans le constructeur de l’application et OnLaunched() sont effectuées en quelques secondes ou que le système peut penser que votre application ne répond pas et l’arrête. Si une application doit demander des données à partir du réseau ou doit récupérer de grandes quantités de données à partir du disque, ces activités doivent être effectuées en dehors du lancement. Une application peut utiliser son propre interface utilisateur de chargement personnalisée ou un écran de démarrage étendu pendant qu’elle attend la fin des opérations longues. Pour plus d’informations, voir Afficher un écran de démarrage pour plus de temps et l’exemple d’écran de démarrage.

Une fois l’application lancée, elle entre dans l’état en cours d’exécution et l’écran de démarrage disparaît et toutes les ressources d’écran de démarrage et les objets sont effacés.

Activation de l’application

Contrairement à celui lancé par l’utilisateur, une application peut être activée par le système. Une application peut être activée par un contrat tel que le contrat de partage. Ou il peut être activé pour gérer un protocole URI personnalisé ou un fichier avec une extension que votre application est inscrite pour gérer. Pour obtenir la liste des façons dont votre application peut être activée, consultez ActivationKind.

La classe Windows.UI.Xaml.Application définit des méthodes que vous pouvez remplacer pour gérer les différentes façons dont votre application peut être activée. OnActivated peut gérer tous les types d’activation possibles. Toutefois, il est plus courant d’utiliser des méthodes spécifiques pour gérer les types d’activation les plus courants et utiliser OnActivated comme méthode de secours pour les types d’activation les moins courants. Voici les méthodes supplémentaires pour des activations spécifiques :

OnCachedFileUpdaterActivated
OnFileActivated
OnFileOpenPickerActivated OnFileSavePickerActivated
OnSearchActivated
OnShareTargetActivated

Les données d’événement de ces méthodes incluent la même propriété PreviousExecutionState que celle que nous avons vue ci-dessus, ce qui vous indique l’état dans lequel votre application était présente avant son activation. Interpréter l’état et ce que vous devez faire de la même façon que décrit ci-dessus dans la section lancement de l’application.

Notez que si vous vous connectez à l’aide du compte Administrateur de l’ordinateur, vous ne pouvez pas activer les applications UWP.

Exécution en arrière-plan

À compter de Windows 10, version 1607, les applications peuvent exécuter des tâches en arrière-plan au sein du même processus que l’application elle-même. En savoir plus sur cette activité en arrière-plan avec le modèle de processus unique. Nous n’allons pas entrer dans le traitement en arrière-plan in-process dans cet article, mais la façon dont cela a un impact sur le cycle de vie de l’application est que deux nouveaux événements ont été ajoutés lorsque votre application est en arrière-plan. Ils sont : EnteredBackground et LeavingBackground.

Ces événements reflètent également si l’utilisateur peut voir l’interface utilisateur de votre application.

L’exécution en arrière-plan est l’état par défaut dans lequel une application est lancée, activée ou reprise. Dans cet état, l’interface utilisateur de votre application n’est pas encore visible.

Exécution au premier plan

L’exécution au premier plan signifie que l’interface utilisateur de votre application est visible.

L’événement LeavingBackground est déclenché juste avant que l’interface utilisateur de votre application soit visible et avant d’entrer l’état d’exécution au premier plan. Il se déclenche également lorsque l’utilisateur revient à votre application.

Auparavant, le meilleur emplacement pour charger les ressources de l’interface utilisateur se trouvait dans les gestionnaires d’événements Activé ou Reprise . À présent, LeavingBackground est le meilleur endroit pour vérifier que votre interface utilisateur est prête.

Il est important de vérifier que les ressources visuelles sont prêtes pour le moment, car il s’agit de la dernière occasion de faire du travail avant que votre application soit visible par l’utilisateur. Tout le travail de l’interface utilisateur dans ce gestionnaire d’événements doit se terminer rapidement, car il a un impact sur le lancement et la reprise de l’expérience utilisateur. LeavingBackground est le temps de s’assurer que la première image de l’interface utilisateur est prête. Ensuite, le stockage ou les appels réseau de longue durée doivent être gérés de manière asynchrone afin que le gestionnaire d’événements puisse retourner.

Lorsque l’utilisateur quitte votre application, votre application réentente l’exécution en arrière-plan.

Réentérer l’état d’arrière-plan

L’événement EnteredBackground indique que votre application n’est plus visible au premier plan. Sur le bureau EnteredBackground se déclenche lorsque votre application est réduite ; sur téléphone, lors du passage à l’écran d’accueil ou à une autre application.

Réduire l’utilisation de la mémoire de votre application

Étant donné que votre application n’est plus visible par l’utilisateur, il s’agit du meilleur endroit pour arrêter le travail de rendu de l’interface utilisateur et les animations. Vous pouvez utiliser LeavingBackground pour recommencer ce travail.

Si vous allez faire du travail en arrière-plan, c’est l’endroit où se préparer. Il est préférable de vérifier MemoryManager.AppMemoryUsageLevel et, si nécessaire, de réduire la quantité de mémoire utilisée par votre application lorsqu’elle s’exécute en arrière-plan afin que votre application ne risque pas d’être arrêtée par le système pour libérer des ressources.

Pour plus d’informations, consultez Réduire l’utilisation de la mémoire lorsque votre application passe à l’état en arrière-plan.

Enregistrer votre état

Le gestionnaire d’événements de suspension est le meilleur endroit pour enregistrer l’état de votre application. Toutefois, si vous effectuez un travail en arrière-plan (par exemple, lecture audio, utilisation d’une session d’exécution étendue ou tâche en arrière-plan en cours), il est également recommandé d’enregistrer vos données de manière asynchrone à partir de votre gestionnaire d’événements EnteredBackground . Cela est dû au fait qu’il est possible que votre application soit arrêtée alors qu’elle est à une priorité inférieure en arrière-plan. Et parce que l’application n’a pas traversé l’état suspendu dans ce cas, vos données seront perdues.

L’enregistrement de vos données dans votre gestionnaire d’événements EnteredBackground , avant le début de l’activité en arrière-plan, garantit une bonne expérience utilisateur lorsque l’utilisateur ramène votre application au premier plan. Vous pouvez utiliser les API de données d’application pour enregistrer les données et les paramètres. Pour en savoir plus, voir Stocker et récupérer des paramètres et autres données d’application.

Après avoir enregistré vos données, si vous dépassez votre limite d’utilisation de la mémoire, vous pouvez libérer vos données de la mémoire, car vous pouvez la recharger ultérieurement. Cela libère la mémoire qui peut être utilisée par les ressources nécessaires pour l’activité en arrière-plan.

N’oubliez pas que si votre application dispose d’une activité en arrière-plan en cours d’exécution, elle peut passer de l’état en arrière-plan à l’état en cours d’exécution à l’état de premier plan sans jamais atteindre l’état suspendu.

Travail asynchrone et report

Si vous effectuez un appel asynchrone dans votre gestionnaire, le contrôle retourne immédiatement à partir de cet appel asynchrone. Cela signifie que l’exécution peut ensuite retourner à partir de votre gestionnaire d’événements et que votre application passe à l’état suivant, même si l’appel asynchrone n’a pas encore été terminé. Utilisez la méthode GetDeferral sur l’objet EnteredBackgroundEventArgs transmis à votre gestionnaire d’événements pour retarder la suspension jusqu’à ce que vous appelons la méthode Complete sur l’objet Windows.Foundation.Deferral retourné.

Un report n’augmente pas la durée pendant laquelle vous devez exécuter votre code avant la fin de votre application. Il retarde uniquement l’arrêt jusqu’à ce que la méthode Complete du report soit appelée, soit que l’échéance passe en premier.

Si vous avez besoin de plus de temps pour économiser votre état, examinez les façons d’enregistrer votre état en phases avant que votre application entre dans l’état d’arrière-plan afin qu’il y ait moins d’enregistrement dans votre gestionnaire d’événements OnSuspending . Vous pouvez également demander à une session ExtendedExecutionSession d’obtenir plus de temps. Il n’existe aucune garantie que la demande sera accordée, mais il est préférable de trouver des moyens de réduire le temps nécessaire pour économiser votre état.

Suspension de l’application

Lorsque l’utilisateur réduit une application, Windows attend quelques secondes pour voir si l’utilisateur revient à celui-ci. S’ils ne reviennent pas dans cette fenêtre de temps et qu’aucune exécution étendue, tâche en arrière-plan ou exécution parrainée par l’activité n’est active, Windows suspend l’application. Une application est également suspendue lorsque l’écran de verrouillage s’affiche tant qu’aucune session d’exécution étendue, etc. est active dans cette application.

Lorsqu’une application est suspendue, elle appelle l’événement Application.Suspending . Les modèles de projet UWP de Visual Studio fournissent un gestionnaire pour cet événement appelé OnSuspending dans App.xaml.cs. Vous devez placer le code pour enregistrer l’état de votre application ici.

Vous devez libérer des ressources exclusives et des handles de fichiers afin que d’autres applications puissent y accéder pendant la suspension de votre application. Parmi les ressources exclusives, citons les caméras, les appareils d’E/S, les appareils externes et les ressources réseau. La publication explicite de ressources exclusives et de handles de fichiers permet de s’assurer que d’autres applications peuvent y accéder pendant que votre application est suspendue. Une fois l’application reprise, elle doit réacquire ses ressources exclusives et ses handles de fichiers.

Tenez compte de l’échéance

Pour garantir un appareil rapide et réactif, il existe une limite pour la durée pendant laquelle vous devez exécuter votre code dans votre gestionnaire d’événements suspendu. Il est différent pour chaque appareil, et vous pouvez déterminer ce qu’il utilise une propriété de l’objet SuspendingOperation appelé échéance.

Comme avec le gestionnaire d’événements EnteredBackground , si vous effectuez un appel asynchrone à partir de votre gestionnaire, le contrôle retourne immédiatement à partir de cet appel asynchrone. Cela signifie que l’exécution peut ensuite retourner à partir de votre gestionnaire d’événements et que votre application passe à l’état de suspension même si l’appel asynchrone n’a pas encore été terminé. Utilisez la méthode GetDeferral sur l’objet SuspendingOperation (disponible via les arguments d’événement) pour retarder l’entrée de l’état suspendu jusqu’à ce que vous appelons la méthode Complete sur l’objet SuspendingDeferral retourné.

Si vous avez besoin de plus de temps, vous pouvez demander une session ExtendedExecutionSession. Toutefois, il n’existe aucune garantie que la demande sera accordée. Il est donc préférable de trouver des moyens de réduire le temps dont vous avez besoin dans votre gestionnaire d’événements suspendus .

Arrêt de l’application

Le système tente de conserver votre application et ses données en mémoire pendant sa suspension. Toutefois, si le système n’a pas les ressources nécessaires pour conserver votre application en mémoire, elle met fin à votre application. Les applications ne reçoivent pas de notification indiquant qu’elles sont arrêtées. Par conséquent, la seule opportunité d’enregistrer les données de votre application se trouve dans votre gestionnaire d’événements OnSuspending .

Lorsque votre application détermine qu’elle a été activée après son arrêt, elle doit charger les données de l’application qu’elle a enregistrées afin que l’application soit dans le même état avant qu’elle ne soit terminée. Lorsque l’utilisateur revient à une application suspendue qui a été arrêtée, l’application doit restaurer ses données d’application dans sa méthode OnLaunched. Le système n’avertit pas une application lorsqu’elle est arrêtée, de sorte que votre application doit enregistrer ses données d’application et libérer des ressources exclusives et des handles de fichiers avant qu’elle soit suspendue, et les restaurer lorsque l’application est activée après l’arrêt.

Remarque sur le débogage à l’aide de Visual Studio : Visual Studio empêche Windows de suspendre une application attachée au débogueur. Cela permet à l’utilisateur d’afficher l’interface utilisateur de débogage Visual Studio pendant l’exécution de l’application. Lorsque vous déboguez une application, vous pouvez l’envoyer à un événement de suspension à l’aide de Visual Studio. Vérifiez que la barre d’outils Emplacement de débogage est affichée, puis cliquez sur l’icône Suspendre .

Cv de l’application

Une application suspendue est reprise lorsque l’utilisateur bascule vers celui-ci ou lorsqu’il s’agit de l’application active lorsque l’appareil sort d’un état d’alimentation faible.

Lorsqu’une application est reprise à partir de l’état suspendu , elle entre dans l’état En cours d’exécution en arrière-plan et le système restaure l’application là où elle s’est arrêtée afin qu’elle apparaisse à l’utilisateur comme si elle était en cours d’exécution. Aucune donnée d’application stockée en mémoire n’est perdue. Par conséquent, la plupart des applications n’ont pas besoin de restaurer l’état lorsqu’elles sont reprise, bien qu’elles doivent réacquire tout fichier ou périphérique qu’ils ont libérés lorsqu’elles ont été suspendues, et restaurer tout état qui a été explicitement libéré lors de la suspension de l’application.

Vous pouvez suspendre l’application pendant des heures ou des jours. Si votre application a du contenu ou des connexions réseau obsolètes, celles-ci doivent être actualisées lorsque l’application reprend. Si une application a inscrit un gestionnaire d’événements pour l’événement Application.Resuming , elle est appelée lorsque l’application est reprise à partir de l’état suspendu . Vous pouvez actualiser le contenu et les données de votre application dans ce gestionnaire d’événements.

Si une application suspendue est activée pour participer à un contrat ou une extension d’application, elle reçoit d’abord l’événement Reprise , puis l’événement Activé .

Si l’application suspendue a été arrêtée, il n’existe aucun événement De reprise et OnLaunched() est appelé à la place avec un État ApplicationExecution de Terminated. Étant donné que vous avez enregistré votre état lorsque l’application a été suspendue, vous pouvez restaurer cet état pendant OnLaunched() afin que votre application apparaisse à l’utilisateur tel qu’il l’était lorsqu’elle a basculé.

Pendant qu’une application est suspendue, elle ne reçoit aucun événement réseau qu’elle a inscrit pour recevoir. Ces événements réseau ne sont pas mis en file d’attente : ils sont simplement manqués. Par conséquent, votre application doit tester l’état du réseau lorsqu’elle est reprise.

Notez que l’événement Resumeing n’est pas déclenché à partir du thread d’interface utilisateur, un répartiteur doit être utilisé si le code de votre gestionnaire de reprise communique avec votre interface utilisateur. Consultez Mettre à jour le thread d’interface utilisateur à partir d’un thread d’arrière-plan pour obtenir un exemple de code sur la façon de procéder.

Pour obtenir des instructions générales, consultez Recommandations pour la suspension et la reprise de l’application.

Fermeture de l’application

En règle générale, les utilisateurs n’ont pas besoin de fermer les applications, ils peuvent laisser Windows les gérer. Toutefois, les utilisateurs peuvent choisir de fermer une application à l’aide du mouvement de fermeture ou en appuyant sur Alt+F4 ou en utilisant le sélecteur de tâches sur Windows Phone.

Il n’existe pas d’événement pour indiquer que l’utilisateur a fermé l’application. Lorsqu’une application est fermée par l’utilisateur, elle est d’abord suspendue pour vous donner la possibilité d’enregistrer son état. Dans Windows 8.1 et versions ultérieures, une fois qu’une application a été fermée par l’utilisateur, l’application est supprimée de l’écran et de la liste de commutateurs, mais pas explicitement terminée.

Comportement fermé par utilisateur : si votre application doit faire quelque chose de différent lorsqu’elle est fermée par l’utilisateur que lorsqu’elle est fermée par Windows, vous pouvez utiliser le gestionnaire d’événements d’activation pour déterminer si l’application a été arrêtée par l’utilisateur ou par Windows. Consultez les descriptions des états ClosedByUser et Terminated dans la référence de l’énumération ApplicationExecutionState .

Nous vous recommandons de ne pas se fermer par programmation, sauf si absolument nécessaire. Par exemple, si une application détecte une fuite de mémoire, elle peut se fermer pour garantir la sécurité des données personnelles de l’utilisateur.

Blocage de l’application

L’expérience de blocage du système est conçue pour ramener les utilisateurs à ce qu’ils faisaient le plus rapidement possible. Vous ne devez pas fournir une boîte de dialogue d’avertissement ou une autre notification, car cela retardera l’utilisateur.

Si votre application se bloque, cesse de répondre ou génère une exception, un rapport de problème est envoyé à Microsoft en fonction des commentaires et des paramètres de diagnostic de l’utilisateur. Pour plus d’informations, consultez Diagnostics, commentaires et confidentialité dans Windows . Microsoft fournit un sous-ensemble des données d’erreur dans le rapport de problèmes pour vous permettre de l’utiliser pour améliorer votre application. Vous serez en mesure de voir ces données dans la page Qualité de votre application dans votre tableau de bord.

Lorsque l’utilisateur active une application après son blocage, son gestionnaire d’événements d’activation reçoit une valeur ApplicationExecutionState de NotRunning et doit afficher son interface utilisateur initiale et ses données. Après un incident, n’utilisez pas régulièrement les données d’application que vous avez utilisées pour reprendre avec suspension , car ces données peuvent être endommagées. Consultez les instructions relatives à la suspension et à la reprise de l’application.

Suppression de l’application

Lorsqu’un utilisateur supprime votre application, l’application est supprimée, ainsi que toutes ses données locales. La suppression d’une application n’affecte pas les données de l’utilisateur stockées dans des emplacements courants tels que les bibliothèques Documents ou Images.

Cycle de vie des applications et modèles de projet Visual Studio

Le code de base pertinent pour le cycle de vie de l’application est fourni dans les modèles de projet Visual Studio. L’application de base gère l’activation de lancement, vous permet de restaurer vos données d’application et d’afficher l’interface utilisateur principale même avant d’avoir ajouté l’un de vos propres codes. Pour plus d’informations, consultez les modèles de projet C#, VB et C++ pour les applications.

API de cycle de vie des applications clés

• Espace de noms Windows.ApplicationModel
• Espace de noms Windows.ApplicationModel.Activation
• Espace de noms Windows.ApplicationModel.Core
• Classe Windows.UI.Xaml.Application (XAML)
• Classe Windows.UI.Xaml.Window (XAML)

Rubriques connexes

• ApplicationExecutionState
• Recommandations pour la suspension et la reprise d’une application
• Gérer le prélancement d’une application
• Gérer l’activation d’une application
• Gérer la suspension d’une application
• Gérer la reprise d’une application
• Activité en arrière-plan avec le modèle de processus unique
• Lire le média en arrière-plan