Lecture multimédia en arrière-plan héritée

Cet article décrit le modèle hérité à deux processus pour ajouter la prise en charge audio en arrière-plan à votre application UWP. À compter de Windows 10, version 1607, modèle monoprocesseur pour l’audio d’arrière-plan beaucoup plus simple à implémenter. Pour plus d’informations sur les recommandations actuelles relatives à l’audio en arrière-plan, consultez Lire le média en arrière-plan. Cet article est destiné à fournir la prise en charge des applications qui ont déjà été développées à l’aide du modèle à deux processus hérité.

Architecture audio en arrière-plan

Une application effectuant une lecture en arrière-plan se compose de deux processus. Le premier processus est l’application principale, qui contient l’interface utilisateur de l’application et la logique cliente, en cours d’exécution au premier plan. Le deuxième processus est la tâche de lecture en arrière-plan, qui implémente IBackgroundTask comme toutes les tâches en arrière-plan de l’application UWP. La tâche en arrière-plan contient la logique de lecture audio et les services en arrière-plan. La tâche en arrière-plan communique avec le système via les contrôles de transport de média système.

Le diagramme suivant est une vue d’ensemble de la façon dont le système est conçu.

MediaPlayer

L’espace de noms Windows.Media.Playback contient des API utilisées pour lire l’audio en arrière-plan. Il existe une seule instance de MediaPlayer par application via laquelle la lecture se produit. Votre application audio en arrière-plan appelle des méthodes et définit des propriétés sur la classe MediaPlayer pour définir la piste actuelle, démarrer la lecture, suspendre, avancer rapidement, rembobiner, et ainsi de suite. L’instance de l’objet lecteur multimédia est toujours accessible via la propriété BackgroundMediaPlayer.Current.

Proxy MediaPlayer et stub

Lorsque BackgroundMediaPlayer.Current est accessible à partir du processus en arrière-plan de votre application, l’instance MediaPlayer est activée dans l’hôte de tâche en arrière-plan et peut être manipulée directement.

Lorsque BackgroundMediaPlayer.Current est accessible à partir de l’application de premier plan, l’instance MediaPlayer retournée est en fait un proxy qui communique avec un stub dans le processus en arrière-plan. Ce stub communique avec l’instance MediaPlayer réelle, qui est également hébergée dans le processus en arrière-plan.

Le processus de premier plan et d’arrière-plan peut accéder à la plupart des propriétés de l’instance MediaPlayer, à l’exception de MediaPlayer.Source et de MediaPlayer.SystemMediaTransportControls qui ne sont accessibles qu’à partir du processus en arrière-plan. L’application de premier plan et le processus en arrière-plan peuvent recevoir des notifications d’événements spécifiques aux médias tels que MediaOpened, MediaEnded et MediaFailed.

Listes de lecture

Un scénario courant pour les applications audio en arrière-plan consiste à lire plusieurs éléments dans une ligne. Cela s’effectue le plus facilement dans votre processus en arrière-plan à l’aide d’un objet MediaPlaybackList, qui peut être défini en tant que source sur MediaPlayer en l’affectant à la propriété MediaPlayer.Source.

Il n’est pas possible d’accéder à un MediaPlaybackList à partir du processus de premier plan défini dans le processus en arrière-plan.

Contrôles de transport du support système

Un utilisateur peut contrôler la lecture audio sans utiliser directement l’interface utilisateur de votre application par le biais de moyens tels que les appareils Bluetooth, SmartGlass et les contrôles de transport multimédia système. Votre tâche en arrière-plan utilise la classe SystemMediaTransportControls pour s’abonner à ces événements système initiés par l’utilisateur.

Pour obtenir une instance SystemMediaTransportControls à partir du processus en arrière-plan, utilisez la propriété MediaPlayer.SystemMediaTransportControls. Les applications de premier plan obtiennent une instance de la classe en appelant SystemMediaTransportControls.GetForCurrentView, mais l’instance retournée est une instance de premier plan uniquement qui n’est pas liée à la tâche en arrière-plan.

Envoi de messages entre les tâches

Il arrive que vous souhaitiez communiquer entre les deux processus d’une application audio en arrière-plan. Par exemple, vous souhaiterez peut-être que la tâche en arrière-plan informe la tâche de premier plan lorsqu’une nouvelle piste commence à jouer, puis d’envoyer le nouveau titre de chanson à la tâche de premier plan à afficher à l’écran.

Un mécanisme de communication simple déclenche des événements au premier plan et en arrière-plan. Les méthodes SendMessageToForeground et SendMessageToBackground appellent chaque événement dans le processus correspondant. Les messages peuvent être reçus en s’abonnant aux événements MessageReceivedFromBackground et MessageReceivedFromForeground.

Les données peuvent être transmises en tant qu’argument aux méthodes d’envoi de message qui sont ensuite passées dans les gestionnaires d’événements reçus du message. Transmettez des données à l’aide de la classe ValueSet . Cette classe est un dictionnaire qui contient une chaîne sous forme de clé et d’autres types de valeurs en tant que valeurs. Vous pouvez passer des types valeur simples tels que des entiers, des chaînes et des booléens.

Cycle de vie des tâches en arrière-plan

La durée de vie d’une tâche en arrière-plan est étroitement liée à l’état de lecture actuel de votre application. Par exemple, lorsque l’utilisateur interrompt la lecture audio, le système peut arrêter ou annuler votre application en fonction des circonstances. Après une période de temps sans lecture audio, le système peut arrêter automatiquement la tâche en arrière-plan.

La méthode IBackgroundTask.Run est appelée la première fois que votre application accède à BackgroundMediaPlayer.Current à partir du code exécuté dans l’application de premier plan ou lorsque vous inscrivez un gestionnaire pour l’événement MessageReceivedFromBackground, selon ce qui se produit en premier. Il est recommandé de vous inscrire au gestionnaire reçu du message avant d’appeler BackgroundMediaPlayer.Current pour la première fois afin que l’application de premier plan ne manque aucun message envoyé à partir du processus en arrière-plan.

Pour maintenir la tâche en arrière-plan active, votre application doit demander un BackgroundTaskDeferral à partir de la méthode Run et appeler BackgroundTaskDeferral.Complete lorsque l’instance de tâche reçoit les événements Canceled ou Completed. N’effectuez pas de boucle ou n’attendez pas dans la méthode Run , car cela consomme des ressources et peut entraîner la fin de la tâche en arrière-plan de votre application par le système.

Votre tâche en arrière-plan obtient l’événement Completed lorsque la méthode Run est terminée et que le report n’est pas demandé. Dans certains cas, lorsque votre application obtient l’événement Annulé , elle peut également être suivie de l’événement Completed . Votre tâche peut recevoir un événement annulé pendant l’exécution de l’exécution. Veillez donc à gérer cette concurrence potentielle.

Les situations dans lesquelles la tâche en arrière-plan peut être annulée sont les suivantes :

• Une nouvelle application avec des fonctionnalités de lecture audio démarre sur les systèmes qui appliquent la sous-stratégie d’exclusivité. Consultez la section de durée de vie des tâches audio en arrière-plan des stratégies système ci-dessous.

• Une tâche en arrière-plan a été lancée, mais la musique n’est pas encore en cours de lecture, puis l’application de premier plan est suspendue.

• Autres interruptions multimédias, telles que les appels téléphoniques entrants ou les appels VoIP.

Les situations dans lesquelles la tâche en arrière-plan peut être arrêtée sans préavis sont les suivantes :

• Un appel VoIP intervient et il n’y a pas suffisamment de mémoire disponible sur le système pour maintenir la tâche en arrière-plan active.

• Une stratégie de ressource est violée.

• L’annulation ou l’achèvement des tâches ne se termine pas correctement.

Stratégies système pour la durée de vie des tâches audio en arrière-plan

Les stratégies suivantes permettent de déterminer comment le système gère la durée de vie des tâches audio en arrière-plan.

Exclusivité

Si elle est activée, cette sous-stratégie limite le nombre de tâches audio en arrière-plan à un maximum de 1 à un moment donné. Il est activé sur mobile et sur d’autres références SKU non de bureau.

Délai d’inactivité

En raison de contraintes de ressources, le système peut mettre fin à votre tâche en arrière-plan après une période d’inactivité.

Une tâche en arrière-plan est considérée comme « inactive » si les deux conditions suivantes sont remplies :

• L’application de premier plan n’est pas visible (elle est suspendue ou arrêtée).

• Le lecteur multimédia en arrière-plan n’est pas dans l’état de lecture.

Si ces deux conditions sont satisfaites, la stratégie du système multimédia en arrière-plan démarre un minuteur. Si aucune condition n’a changé lorsque le minuteur expire, la stratégie du système multimédia en arrière-plan met fin à la tâche en arrière-plan.

Durée de vie partagée

Si elle est activée, cette sous-stratégie force la tâche en arrière-plan à dépendre de la durée de vie de la tâche de premier plan. Si la tâche de premier plan est arrêtée, par l’utilisateur ou le système, la tâche en arrière-plan s’arrête également.

Toutefois, notez que cela ne signifie pas que le premier plan dépend de l’arrière-plan. Si la tâche en arrière-plan est arrêtée, cela ne force pas la tâche de premier plan à arrêter.

Le tableau suivant répertorie les stratégies appliquées aux types d’appareils.