Article
11/17/2015

Rubrique spéciale sur Windows 10 - 2015

Volume 30, numéro 11

Cet article a fait l'objet d'une traduction automatique.

Cycle de vie d’une application : maintenez vos applications dynamiques grâce aux tâches d’arrière-plan et à l’exécution étendue

Par Shawn Henry | Windows 2015

Auparavant, que la durée de vie d'une application était facile. Lorsqu'un utilisateur a lancé une application, il peut exécuter sauvage sur le système : utilisation des ressources, particularité de windows ainsi que généralement comme il le plaisir sans tenir compte des autres. Aujourd'hui, les choses sont plus ardues. Dans un monde mobile en premier, les applications sont limitées à un cycle de vie d'application définis. Ce cycle de vie spécifie quand une application peut s'exécuter, et la plupart du temps il ne peut pas, si l'application n'est pas la chose en cours, l'utilisateur, il n'a pas autorisé à exécuter.

Dans la plupart des cas, c'est bon, les utilisateurs savent qu'une application n'est pas consommation d'énergie ou qui vident votre performance. Pour les applications, le système d'exploitation applique ce qui a toujours été conseillé que les applications entrent dans un état stable de suspendu lorsqu'en cours d'utilisation. Ceci est particulièrement important, car le modèle d'application dans la plate-forme de Windows universel (UWP) doit pouvoir évoluer à partir des périphériques plus bas-end, tels que les téléphones et appareils Internet des objets (IoT), à ses bureaux plus puissant et Xbox.

Pour les applications complexes, le modèle d'application moderne peut sembler restrictif au premier abord, mais comme le décrit cet article, il y a plusieurs façons applications peuvent développer la boîte et exécutez (exécution des tâches et la livraison des notifications), même lorsque pas au premier plan.

Cycle de vie de l'application

Dans Win32 et .NET développement de bureau traditionnelles, les applications sont généralement dans un des deux états: « running » ou « inactif » et la plupart du temps, ils s'exécutent. Cela peut sembler évident, mais imaginez un instant messaging application comme Skype ou une application de musique comme Spotify : l'utilisateur lance, exécute une action (envoi d'un message ou de la recherche de musique), puis s'éteint et fait quelque chose d'autre. Tout, Skype réside en arrière-plan attend les messages à venir et Spotify conserve audio. Cela contraste avec les applications modernes (tels que les applications Windows basées sur la série UWP), dont la plupart de leur temps dans un état autre qu'en cours d'exécution.

Les applications Windows sont toujours dans un des trois états : en cours d'exécution, suspendu ou pas en cours d'exécution, comme dans Figure 1. Lorsqu'un utilisateur lance une application Windows, par exemple en tapant sur une vignette dans le menu Démarrer, l'application est activée et passe à l'état en cours d'exécution. Tant que l'utilisateur interagit avec l'application, il reste dans l'état en cours d'exécution. Si l'utilisateur quitte l'application ou réduit, un événement interrompu est déclenché. Il s'agit d'une opportunité pour l'application à sérialiser n'importe quel état que peuvent être nécessaires pour lorsqu'il a repris ou réactivé, telles que la page actuelle de l'application ou les données de formulaire partiellement remplis. Lorsqu'une application est à l'état suspendu, ses processus et les threads sont suspendus par Windows et ne peut pas exécuter. Lorsque l'utilisateur navigue vers l'application, les threads d'application sont figées et l'application reprend l'état en cours d'exécution.

Figure 1 le cycle de vie des applications Windows

Si une application est dans l'état suspendu, mais les ressources qu'il utilise (en général, la mémoire), sont nécessaires pour autre chose, comme l'exécution d'une autre application, l'application est déplacée vers l'état pas en cours d'exécution.

Du point de vue de l'exécution d'application, la différence entre la suspension et ne pas en cours d'exécution est si l'application est autorisée à demeurent en mémoire. Lorsqu'une application est simplement suspendue, son exécution est bloquée, mais toutes ses informations d'état reste en mémoire. Lorsqu'une application n'est pas en cours d'exécution, il est supprimé de la mémoire. Car aucun événement n'est déclenché lorsqu'une application se déplace de suspendu ne pas en cours d'exécution, il est important pour une application à sérialiser toutes les informations d'état dont il a besoin de la mémoire, au cas où il est réactivé de ne pas en cours d'exécution.

Figure 2 montre ce qui arrive à l'utilisation des ressources en tant que la transition d'applications via le cycle de vie. Lorsqu'une application est activée, il commence à consommer la mémoire, en général atteint un palier relativement stable. Lorsqu'une application est interrompue, sa consommation de mémoire généralement tombe en panne, mémoires tampons et les ressources utilisées sont libérées et la consommation de l'UC atteint zéro (appliquée par le système d'exploitation). Lorsqu'une application se déplace de suspendu ne pas en cours d'exécution, la mémoire et l'utilisation de l'UC atteindre zéro, à nouveau appliquée par le système d'exploitation.

Le cycle des applications et l'utilisation des ressources
Figure 2 le cycle de vie d'Application et l'utilisation des ressources

Sur de nombreux systèmes de bureau avec beaucoup de RAM et les fichiers d'échange volumineux, il n'est pas commun, mais pas impossible, pour une application à supprimer de la mémoire, mais cette transition est beaucoup plus courante sur les périphériques mobile et autres ressources limitées. Pour cette raison, il est important de tester votre application UWP sur un large éventail de périphériques. L'émulateur de Windows est fourni avec Visual Studio peut être très utile pour cela ; Il permet aux développeurs de cibler les périphériques avec que peu de 512 Mo de mémoire.

Étendue de l'exécution

J'ai décrit le cycle des applications est efficace, consomme de ressources ne sont pas des applications s'ils ne sont pas utilisés, mais il peut entraîner un scénario où l'une application a besoin n'est pas possible. Par exemple, un cas d'usage typique pour une application sociale ou les communications consiste à vous connecter et synchroniser des données de cloud (contacts, flux, l'historique des conversations, etc.). Avec le cycle de vie d'une application de base comme décrit, pour télécharger les contacts, l'utilisateur aurait besoin de conserver l'application ouverte et au premier plan tout le temps ! Un autre exemple peut être une navigation ou une application de Fitness (pertinence) qui doit suivre l'emplacement de l'utilisateur. Dès que l'utilisateur bascule vers une autre application ou placer le périphérique dans leur poche, cela ne fonctionnent plus. Il doit y avoir un mécanisme pour permettre aux applications exécuter un peu plus de temps.

La plate-forme Windows Universal introduit le concept d'exécution prolongée pour aider à ces types de scénarios. Il existe deux cas où l'exécution étendue peut être utilisée :

À tout moment pendant l'exécution régulière de premier plan, tandis que l'application est en cours d'exécution.
Une fois que l'application a reçu un événement d'interruption (le système d'exploitation est sur le point de passer de l'application à l'état suspendu) dans le Gestionnaire d'événements suspension.

Le code de ces deux cas est le même, mais l'application se comporte un peu différemment dans chacun. Dans le premier cas, l'application reste en cours d'exécution, même si un événement qui déclenche normalement suspension se produit (par exemple, l'utilisateur accédant à une autre application). L'application ne recevra jamais un événement d'interruption pendant que l'extension de l'exécution est en vigueur. Lorsque l'extension est supprimée, l'application devient éligible pour la suspension à nouveau.

Dans le deuxième cas, si l'application est en transition vers l'état interrompu, il reste dans un état de suspension pour la période de l'extension. Une fois que l'extension expire, l'application sont suspendues sans autre notification.

Figure 3 montre comment utiliser l'exécution prolongée pour étendre l'état uspending d'une application. Tout d'abord, une nouvelle ExtendedExecutionSession est créée et fournie avec un motif et une Description. Ces deux propriétés sont utilisées pour allouer les ressources correctes définies pour cette application (autrement dit, la quantité de mémoire, UC et durée d'exécution qu'est autorisée) et exposer des informations à l'utilisateur sur ce que font les applications en arrière-plan. L'application puis raccorde un gestionnaire d'événements de révocation, qui est appelé si Windows peut ne plus en charge l'extension, par exemple, si une autre tâche de haute priorité, comme une application de premier plan ou d'un appel VoIP, a besoin de ressources. Enfin, l'application demande l'extension et, en cas de réussite, commence son enregistrement opération. Si l'extension est refusée, l'application effectue une opération de suspension comme s'il n'avait pas reçu l'extension, comme un événement de suspension régulière.

Figure 3 étendue d'exécution dans le Gestionnaire de OnSuspending

private async void OnSuspending(object sender, SuspendingEventArgs e)
{
  var deferral = e.SuspendingOperation.GetDeferral();
  using (var session = new ExtendedExecutionSession())
  {
    session.Reason = ExtendedExecutionReason.SavingData;
    session.Description = "Upload Data";
    session.Revoked += session_Revoked;
    var result = await session.RequestExtensionAsync();
    if (result == ExtendedExecutionResult.Denied)
    {
      UploadBasicData();
    }
    // Upload Data
    var completionTime = await UploadDataAsync(session);
  }
  deferral.Complete();
}

Figure 4 montre l'impact sur le cycle de vie d'application; comparez-la à Figure 2. Lorsqu'une application reçoit un événement de suspension, il commence à la version ou de sérialiser des ressources. Si l'application détermine le service nécessite plus de temps, une extension, il reste dans l'état de suspension jusqu'à ce que l'extension est révoquée.

Figure 4 l'utilisation des ressources lors de l'exécution étendue

Comme mentionné précédemment dans les cas 2, extension de l'exécution ne doit pas être demandé uniquement dans le Gestionnaire d'interruption ; Il peut être demandé à tout moment pendant que l'application est en cours d'exécution. Cela est utile pour lorsque l'application sait au préalable qu'il doit continuer à s'exécuter en arrière-plan, comme avec l'application de navigation mentionnée précédemment. Le code est très similaire à l'exemple précédent et est indiqué dans Figure 5.

Figure 5 étendue d'exécution pendant l'exécution régulière

private async void StartTbTNavigationSession()
{
  using (var session = new ExtendedExecutionSession())
  {
    session.Reason = ExtendedExecutionReason.LocationTracking;
    session.Description = "Turn By Turn Navigation";
    session.Revoked += session_Revoked;
    var result = await session.RequestExtensionAsync();
    if (result == ExtendedExecutionResult.Denied
    {
      ShowUserWarning("Background location tracking not available");
    }
    // Do Navigation
    var completionTime = await DoNavigationSessionAsync(session);
  }
}

Figure 6 illustre le cycle de vie d'application pour ce scénario. Là encore, il est très similaire ; la différence est que lorsque l'extension de l'exécution est révoquée, l'application sera probablement rapidement passer à l'état suspendu à l'état en cours d'exécution pas. Cela se produit car, dans ce cas, l'extension a été révoquée en général uniquement en raison de la sollicitation des ressources, une situation qui peut uniquement être atténuée en libérant les ressources (ce qui est, en supprimant l'application de la mémoire).

Figure 6 utilisation des ressources lors de l'exécution étendue

Tâches d'arrière-plan

Il existe une autre façon, qu'une application peut s'exécuter en arrière-plan, et c'est une tâche en arrière-plan. Tâches en arrière-plan sont des composants distincts dans une application qui implémentent l'interface IBackgroundTask. Ces composants peuvent être exécutées sans infrastructures d'interface utilisateur de haute densité et s'exécutent généralement dans un processus distinct (bien qu'ils peuvent également être exécutés in-process avec l'exécutable d'application principal).

Une tâche en arrière-plan est exécutée lorsque le déclencheur associé est déclenché. Un déclencheur est un événement système qui peut déclencher et activer une application, même si l'application n'est pas en cours d'exécution. Par exemple, le TimeTrigger peut être généré avec un intervalle de temps spécifique (par exemple, toutes les 30 minutes), auquel cas tâche d'arrière-plan de l'application serait activer toutes les 30 minutes lorsque le déclencheur est activé. Il existe de nombreux types de déclencheurs pris en charge par Windows, y compris les types de déclencheurs en arrière-plan : TimeTrigger, PushNotificationTrigger, LocationTrigger, ContactStoreNotificationTrigger, BluetoothLEAdvertisementWatcherTrigger, UserPresent, InternetAvailable et PowerStateChange.

À l'aide d'une tâche en arrière-plan est un processus en trois étapes : Le composant doit être créé, puis déclaré dans le manifeste d'application et ensuite enregistré au moment de l'exécution.

Tâches en arrière-plan sont généralement implémentées dans des projets de composant Windows Runtime (WinRT) distincts dans la même solution que le projet d'interface utilisateur. Ainsi, la tâche en arrière-plan à activer dans un processus distinct, ce qui réduit la surcharge requise par le composant de mémoire. Une implémentation simple d'un IBackgroundTask est indiquée dans Figure 7. IBackgroundTask est une interface simple qui définit une seule méthode, exécutez. Il s'agit de la méthode est appelée lorsque le déclencheur de la tâche en arrière-plan. Seul paramètre de la méthode est un objet IBackgroundTaskInstance qui contient le contexte sur l'activation (par exemple, la charge utile d'une notification push associé ou l'action utilisée par une notification toast) et les gestionnaires d'événements pour gérer les événements de cycle de vie telles que l'annulation. Lorsque la méthode Run est terminée, la tâche en arrière-plan est terminée. Pour cette raison, comme dans le Gestionnaire d'interruption indiqué précédemment, il est important d'utiliser l'objet Report (se bloquent également désactiver la IBackgroundTaskInstance) si votre code est asynchrone.

Figure 7 BackgroundTask implémentation

public sealed class TimerTask : IBackgroundTask
{
  public void Run(IBackgroundTaskInstance taskInstance)
  {
    var deferral = taskInstance.GetDeferral();
    taskInstance.Canceled += TaskInstance_Canceled;
    await ShowToastAsync("Hello from Background Task");
    deferral.Complete();
  }
  private void TaskInstance_Canceled(IBackgroundTaskInstance sender,
    BackgroundTaskCancellationReason reason)
  {
    // Handle cancellation
    deferral.Complete();
  }
}

Dans le manifeste d'application, la tâche d'arrière-plan doit également être enregistrée. Cet enregistrement indique à Windows le type de déclencheur, le point d'entrée et l'hôte exécutable de la tâche, comme suit :

<Extensions>
  <Extension Category="windows.backgroundTasks" EntryPoint="BackgroundTasks.TimerTask">
    <BackgroundTasks>
      <Task Type="timer" />
    </BackgroundTasks>
  </Extension>

Cela possible également sans plonger dans XML à l'aide du Concepteur de manifeste inclus avec Visual Studio.

Enfin, la tâche doit également être inscrit au moment de l'exécution, et cela est indiqué dans Figure 8. Ici, j'utilise l'objet BackgroundTaskBuilder pour enregistrer la tâche avec un TimeTrigger qui se déclenche toutes les 30 minutes, si Internet est disponible. C'est le type idéal de déclencheur pour les opérations courantes telles que mise à jour d'une vignette ou périodiquement la synchronisation de petites quantités de données.

Figure 8 inscription de la tâche en arrière-plan

private void RegisterBackgroundTasks()
{
  BackgroundTaskBuilder builder = new BackgroundTaskBuilder();
  builder.Name = "Background Test Class";
  builder.TaskEntryPoint = "BackgroundTaskLibrary.TestClass";
  IBackgroundTrigger trigger = new TimeTrigger(30, true);
  builder.SetTrigger(trigger);
  IBackgroundCondition condition =
    new SystemCondition(SystemConditionType.InternetAvailable);
  builder.AddCondition(condition);
  IBackgroundTaskRegistration task = builder.Register();
  task.Progress += new BackgroundTaskProgressEventHandler(task_Progress);
  task.Completed += new BackgroundTaskCompletedEventHandler(task_Completed);
}

Le principal avantage des tâches d'arrière-plan peut être également leur malédiction : Tâches en arrière-plan s'exécutant en arrière-plan (lorsque l'utilisateur peut faire quelque chose d'important au premier plan ou le périphérique est en veille), ils sont strictement limitées dans la quantité de mémoire et ils peuvent utiliser le temps processeur. Par exemple, la tâche d'arrière-plan est enregistré dans Figure 8 s'exécutera que 30 secondes et ne peut pas consommer plus de 16 Mo de mémoire sur les périphériques avec 512 Mo de mémoire ; les limitations de mémoire mise à l'échelle avec la quantité de mémoire sur le périphérique. Lors du développement et l'implémentation des tâches en arrière-plan, il est important de tenir compte de cela. Tâches en arrière-plan doivent être testées sur divers périphériques, notamment des appareils bas de gamme, avant de publier une application. Il existe deux autres choses à noter également :

Si Battery Saver est disponible et active (en général, lorsque la batterie est sous un certain seuil de coût), les tâches en arrière-plan ne peuvent pas en cours d'exécution jusqu'à ce que la batterie est rechargée au-delà du seuil de batterie de veille.
Dans les versions précédentes de Windows, les applications devait être « épinglé » sur le verrou avant qu'ils ont été autorisés à s'exécuter en arrière-plan et, dans certains cas, il y avait un nombre maximal de tâches en arrière-plan qui pourrait être inscrits, à l'échelle du périphérique. Ce n'est plus le cas dans Windows 10, mais une application doit toujours appeler BackgroundExecutionManger.RequestAcessAsync pour déclarer son intention de s'exécuter en arrière-plan.

Une meilleure approche contactez la synchronisation

Il existe de nombreuses opérations d'arrière-plan qui peuvent être effectuées avec l'exécution de l'étendue ou les tâches en arrière-plan. En règle générale, il est préférable d'utiliser des tâches en arrière-plan si possible, ils sont plus fiables et plus efficace.

Par exemple, le scénario mentionné précédemment, la synchronisation des données premier lancement d'une application, peut également être effectuée et fait plus efficacement, avec une tâche en arrière-plan, dans ce cas à l'aide d'un déclencheur est une nouveauté de Windows 10 : le déclencheur de l'application.

ApplicationTrigger (comme DeviceUseTrigger) appartient à une catégorie particulière de déclencheurs qui sont déclenchées directement à partir de la partie de premier plan de l'application. Pour cela, vous devez explicitement appeler RequestAsync sur l'objet déclencheur. ApplicationTrigger est particulièrement utile pour les scénarios où l'application souhaite démarrer une opération en premier plan qui doit continuer façon opportuniste en arrière-plan si l'application n'est plus au premier plan et d'opération n'est pas dépendante est étroitement lié au premier plan. Voici un exemple d'une tâche ApplicationTrigger qui peut être utilisé à la place d'exécution étendu pour la plupart des scénarios :

var appTrigger = new ApplicationTrigger();
var backgroundTaskBuilder = new BackgroundTaskBuilder();
backgroundTaskBuilder.Name = "App Task";
backgroundTaskBuilder.TaskEntryPoint = typeof(AppTask).FullName;
backgroundTaskBuilder.SetTrigger(appTrigger);
backgroundTaskBuilder.Register();
var result = await appTrigger.RequestAsync();

Synthèse

Cet article donne une vue d'ensemble de l'exécution du cycle de vie et de l'arrière-plan de l'application dans Windows 10 et introduit quelques nouveaux mécanismes applications peuvent utiliser pour s'exécuter en arrière-plan : étendue des tâches d'exécution et d'arrière-plan. Tâches en arrière-plan sont un meilleur choix pour les appareils bas de gamme et soumis à des contraintes de mémoire (tels que des téléphones), tandis que l'exécution étendue est plus appropriée pour les périphériques haut de gamme (tels que les ordinateurs de bureau).

Shawn Henryest responsable de programme Senior de l'équipe plate-forme Windows universel. Joindre sur Twitter : @shawnhenry.

Remercie les experts techniques Microsoft suivants pour avoir relu cet article : Anis Mohammed Khaja Mohideen et cheik Abdul Hadi
Abdul Hadi cheik est développeur de logiciels dans l'équipe de plate-forme Windows universel

Anis Mohammed Khaja Mohideen est un développeur de logiciels Senior équipe plate-forme Windows universel

Partager via