Écriture d’applications multimédias en arrière-plan qui économisent l’énergie (HTML)

  • Article

[ Cet article est destiné aux développeurs Windows 8.x et Windows Phone 8.x qui créent des applications Windows Runtime. Si vous développez une application pour Windows 10, voir la Documentation ]

Introduction

Le mode d’alimentation AOAC (Always On Always Connected) est nouveau dans Windows 8. Ce mode permet à vos applications de consommer très peu d’énergie tout en étant connectées et réactives. Ce nouvel état de faible consommation d’énergie est appelé veille connectée. Un objectif de cet état est de permettre une lecture audio à faible consommation d’énergie pour que les applications multimédias en arrière-plan puissent fonctionner pendant de nombreuses heures sans recharger la batterie.

Pour atteindre les objectifs en matière d’énergie pour la veille connectée, la connexion réseau doit entrer dans un état de faible consommation d’énergie. Cela signifie qu’une application audio en arrière-plan ne peut pas accéder au réseau n’importe quand. Les sources Microsoft Media Foundation peuvent toujours lire le contenu en réseau, par exemple via une balise audio HTML5, à la fois à partir des emplacements de fichiers réseau et par une diffusion multimédia en continu si vous utilisez des sources de la boîte de réception. Toutefois, si une application doit communiquer avec le réseau pour une raison quelconque, par exemple pour des vérifications de licences, des métadonnées ou des statistiques utilisateur, vous devez effectuer des tâches supplémentaires.

Ces exigences s’appliquent uniquement aux applications qui lisent des données audio en arrière-plan. Pour plus d’informations sur la lecture de contenu audio en arrière-plan, voir Comment lire du contenu audio en arrière-plan.

Comment accéder au réseau

Une application audio en arrière-plan peut accéder au réseau de trois façons différentes :

  1. Background transfer API. Il s’agit de la meilleure option. Il vous suffit de passer vos autres appels réseau via l’API de transfert en arrière-plan en tant que chargement ou téléchargement de fichier. Tout le travail consistant à activer ou désactiver les connexions réseau est effectué automatiquement. Pour plus d’informations, voir Windows.Networking.BackgroundTransfer.

  2. Wrap an existing MF bytestream. L’API de transfert en arrière-plan est conçue pour le transfert des fichiers et peut être inappropriée pour des communications réseau courtes et rapides. Quand une source ou un flux d’octets Media Foundation est instancié, Windows accepte une référence réseau à son nom. Cela s’applique aussi aux sources et flux d’octets Media Foundation personnalisés. Une source ou un flux d’octets entièrement personnalisé est assez complexe. Pour simplifier le problème, vous pouvez encapsuler les flux d’octets de la boîte de réception. Après l’initialisation, l’application peut utiliser le réseau si nécessaire à l’aide de n’importe quelle API réseau. Une fois qu’il a fini d’utiliser le réseau, le wrapper commence à utiliser le flux d’octets de la boîte de réception. Le flux d’octets de la boîte de réception à son tour arrête le réseau quand il a terminé.

    Pour obtenir un exemple de source personnalisée, voir l’Exemple de communication en temps réel.

    Pour obtenir un exemple de communication entre une application et une source, voir l’exemple de diffusion MediaStreamSource.

  3. Fully custom Media Foundation source or bytestream. Cette option est semblable à l’option 2 mais, au lieu d’utiliser des composants de la boîte de réception, le développeur écrit l’intégralité du flux d’octets ou de la source Media Foundation. Dans ce cas, il vous revient d’informer Media Foundation quand vous avez terminé d’utiliser le réseau en émettant une modification des caractéristiques. La figure illustre un exemple de flux.

Voici un exemple d’une playlist de deux chansons avec l’option 2 ou 3.

Exemple de flux pour une playlist de deux chansons avec l’option 2 ou 3.

Si aucune de ces solutions ne fonctionne pour votre application, contactez lpa_questions@microsoft.com. Décrivez précisément votre scénario d’utilisation et la raison pour laquelle les options ci-dessus ne peuvent pas fonctionner pour vous.

Autres remarques

En plus de vous assurer que votre application accède correctement au réseau, vous devez tenir compte d’autres éléments dans le cas d’une application audio à faible consommation d’énergie. Comme l’application peut être exécutée quand la majeure partie du système est suspendue, vous devez garder les besoins en énergie à l’esprit pendant le développement de l’application. En utilisant les notifications de changement de la visibilité (ce qui se produit à la fois quand l’application est en arrière-plan et quand l’appareil passe en veille connectée) comme indicateur, placez l’application en mode de faible consommation.

  • N’effectuez aucune mise à jour de l’interface utilisateur. Si l’application n’est pas visible, toute opération liée aux graphiques ou à l’interface utilisateur utilise inutilement de l’énergie.
  • Réduisez autant que possible les tâches. Cela est étroitement lié aux mises à jour de l’interface utilisateur. Si une opération n’est pas nécessaire en l’absence de l’utilisateur, il n’est pas pertinent de l’effectuer quand l’application n’est pas visible.
  • Regroupez les communications réseau. Plus l’application peut passer de temps sans utiliser de manière significative le réseau ou le processeur, mieux c’est.
  • En mode veille connectée, les opérations peuvent prendre plus de temps. L’application est limitée quand elle est en veille connectée et n’a que peu de temps d’exécution sur le processeur.
  • Pour garantir la meilleure utilisation des ressources audio, vous devez limiter le nombre de balises audio qui sont utilisées dans votre application à une ou deux en même temps (cela inclut les balises qui peuvent être initialisées, mais qui ne sont pas actives).