Mise à jour des mosaïques dynamiques sans baisse de l'autonomie

Conception de Windows 8

Vision en coulisses de l'équipe d'ingénierie Windows

Mise à jour des mosaïques dynamiques sans baisse de l'autonomie

  • Comments 4

Sur tous nos écrans, le concept de « notification légère » est de plus en plus courant. À l'origine, les gadgets Windows étaient conçus pour offrir ce type de fonctionnalité, l'idée étant de proposer un affichage en superposition fournissant rapidement des informations importantes (actualité, météo, résultats sportifs, informations métier, etc.). Cependant, le temps de démarrage et le concept de gadget s'accordent mal avec notre volonté de réduire la consommation électrique globale (objectif important aussi bien pour les ordinateurs de bureau que pour les ordinateurs portables) et de proposer aux développeurs une plateforme en plein écran. En outre, l'écran Démarrer de Windows 8 offre une surface de travail bien plus vaste permettant d'afficher plus de notifications de ce type, ainsi qu'une interface de gestion des mises à jour entièrement contrôlable par l'utilisateur (y compris en ce qui concerne l'utilisation des ressources réseau). Avec les expériences utilisateur modernes, à travers lesquelles la quantité d'informations disponibles via des transmissions de type push ou des fragments de code structurés ne cesse d'augmenter, les opportunités qui s'offrent aux développeurs et aux utilisateurs finaux sont inédites. Dans ce billet, Ryan Haveson aborde le développement des mosaïques dynamiques de style Metro et explique comment l'architecture peut prendre en charge de nombreuses mosaïques, tout en réduisant la consommation électrique globale et la charge système.
–Steven Sinofsky

Comme nous le savons tous, les performances et l'autonomie de la batterie jouent un rôle crucial dans le succès des nouvelles versions de Windows. Vos commentaires mettent d'ailleurs l'accent sur ces critères. @KISSmakesmeSMILE résume assez bien le problème :

« …essayez de faire aussi bien, voire mieux, que les niveaux d'autonomie atteints par [concurrent] lorsque l'ordinateur est peu sollicité ».

Par ailleurs, nous savons également que tous les environnements modernes (PC, téléviseurs, téléphones, etc.) possèdent un modèle de gadgets, de widgets ou de plug-ins permettant d'afficher des informations rapidement. Les informations télévisées, les émissions sportives et les prévisions météo offrent un écran structuré d'informations issues de nombreuses sources, regroupées en temps réel. Les utilisateurs veulent pouvoir consulter rapidement les cours de la bourse, la météo, leur courrier électronique, leurs rendez-vous, leurs données métier ou encore leurs réseaux sociaux en quelques secondes, avant de reprendre le cours normal de leurs activités. Dans ce domaine, le PC a sans doute un train de retard sur d'autres types d'appareils. Lorsque nous avons commencé à élaborer notre infrastructure de notifications, notre principale difficulté a été de réussir à rendre le PC parfaitement réactif, tout en assurant une efficacité optimale sur le plan de la consommation électrique et de l'utilisation de la bande passante. @AndyCadley résume parfaitement cet objectif :

« Vos applications Metro se comportent comme des applications exécutées en permanence, mais pour autant, elles ne viennent pas limiter l'autonomie ou les performances ».

L'écran Démarrer offre également plus d'efficacité du point de vue du modèle utilisateur, en vous proposant un affichage plein écran en superposition, qui n'interfère en rien avec les applications de bureau ou les applications de style Metro affichées à l'écran. Par ailleurs, nous voulions non seulement rendre cet affichage efficace, mais aussi faire en sorte que vous puissiez installer autant d'applications de notification que vous le souhaitez, sans avoir à vous soucier des performances ou de l'autonomie.

En utilisant Windows 8 en interne, nous avons remarqué que la possibilité d'utiliser l'écran Démarrer sous forme d'affichage en superposition unifié et lisible pour les applications de cœur de métier contribue à améliorer la productivité. Les applications axées principalement sur les notifications suscitent beaucoup d'intérêt. Grâce à l'évolutivité de notre nouvelle plateforme de notifications push, Windows 8 peut proposer cette fonctionnalité sans ralentir les performances du système, ce qui constitue une amélioration de taille par rapport aux mécanismes présents actuellement dans Windows. Rapidement, nous avons décelé de nombreux cas d'utilisation où même les plus fervents partisans des applications de bureau trouveront l'écran Démarrer particulièrement utile, car il constitue une zone de notification centralisée, présentée de façon agréable et contrôlable à souhait, accessible à l'aide d'une simple touche.

Objectifs de la plateforme de notification

De prime abord, il peut sembler contradictoire de vouloir afficher des centaines de mosaïques d'applications actives et dynamiques sans ralentir les performances du système. Par définition, toute « activité » consomme des ressources : les notifications issues du cloud utilisent le réseau, l'affichage d'une notification dans une mosaïque utilise les ressources du processeur et de la carte graphique, etc. Pour parvenir au résultat attendu, nous savions que nous devions rester concentrés sur les objectifs fixés au départ :

  • Permettre l'affichage de centaines de mosaïques dynamiques sans dégradation des performances
  • Aller encore plus loin que l'affichage de bulles, de badges et de texte, en permettant l'affichage d'images haute résolution
  • Simplifier le travail des développeurs, pour qu'ils n'aient plus à se soucier des mosaïques, une fois la fonctionnalité implémentée
  • Diffuser les données en temps réel, de sorte que les « messages instantanés » soient réellement diffusés de façon instantanée

À partir de ces objectifs, en termes d'architecture, la première décision fondamentale que nous avons prise a consisté à créer une plateforme pilotée par les données : aucun code d'application ne devait être exécuté en arrière-plan pour faire fonctionner l'écran Démarrer.

L'architecture d'un système de distribution de notifications comporte plusieurs éléments : logique déterminant quand la connexion doit être établie, authentification, mise en cache local, affichage, gestion des erreurs, algorithmes de réduction exponentielle, limitation de bande passante, etc. En outre, le système doit gérer également les problèmes directement liés au service (identifier si la connexion est ou non établie, par exemple), pour pouvoir mettre en cache le contenu non distribué et gérer des scénarios complexes générant de nouvelles tentatives. Imaginez le résultat si chaque application possédant sa mosaïque dynamique disposait de sa propre version intégrale de ce code client/serveur. Non seulement chaque implémentation présenterait ses propres bogues, mais en plus le système devrait gérer des doublons d'un code similaire pour chaque application chargée en mémoire. Le code serait en permanence paginé et dépaginé sur le disque. Ce fonctionnement manquerait réellement d'efficacité, car il obligerait toutes vos applications à être exécutées en permanence pour assurer la mise à jour de l'écran Démarrer. Même sur une machine disposant de beaucoup de mémoire, les performances du système seraient ralenties très rapidement.

Comme Bill Karagounis l'a expliqué dans son billet dévoilant comment nous avons réduit l'encombrement de la mémoire dans Windows 8, les performances se dégradent à mesure qu'augmente le nombre de processus, de DLL ou de services en cours d'exécution. Si chaque mosaïque dynamique était exécutée avec son propre code, nous n'aurions pas pu concrétiser notre premier objectif, celui de permettre l'affichage de centaines de mosaïques dynamiques sans ralentir les performances.

Pour résoudre ce problème, nous avons conçu un modèle piloté par les données. Par conséquent, un développeur peut implémenter sa mosaïque en utilisant un jeu de propriétés prédéfinies et de modèles, avec dans ce cas un schéma XML. Les données de la mosaïque XML sont ensuite envoyées au service WNS (Windows Push Notification Service), via une simple requête HTTP POST. Windows se charge ensuite du reste. L'ensemble du code requis pour la connexion, les nouvelles tentatives, l'authentification, la mise en cache, le rendu, la gestion des erreurs, etc., est mis en œuvre de façon homogène et s'avère très efficace sur le plan de la consommation électrique.

Voici un exemple d'un des nombreux modèles de mosaïques que les développeurs peuvent utiliser dans leurs applications Windows 8. Ce modèle se compose d'une zone de texte et d'une seule image, mais d'autres modèles sont à votre disposition.

Image d'un surfer, sur laquelle figure l'icône Flux RSS ainsi que le texte « First ever surfboard kickflip recorded in Santa Cruz » (Le tout premier kickflip en surf, enregistré à Santa Cruz)
Figure 1 : exemple de modèle (TileWideImageAndText)

Voici le code XML correspondant, qui décrit la mosaïque ci-dessus :

<?xml version="1.0" encoding="utf-8"?>
<tile>
<visual lang="en-US">
<binding template="TileWideImageAndText">
<image id="1" src="http://www.fabrikam.com/kickflip.png"/>
<text id="1">First ever surfboard kickflip recorded in Santa
Cruz</text>
</binding>
</visual>
</tile>

En prenant la décision d'utiliser un modèle piloté par les données, nous avons réussi à atteindre nos deux premiers objectifs (performances et expérience utilisateur optimale). Il nous restait encore à distribuer les notifications en temps réel et à simplifier la gestion, de sorte que les développeurs n'aient plus à se soucier de la mosaïque une fois l'implémentation terminée.

En matière de distribution de contenus entre client et serveur, il existe deux modèles de conception de haut niveau : l'interrogation et la transmission de type push. En mode interrogation, le client se connecte au service à intervalle régulier (toutes les 90 minutes, par exemple) pour détecter les nouveaux contenus éventuels. En mode push, lorsque du nouveau contenu est détecté, le service envoie les données directement au client.

Le seul moyen de prendre en charge les notifications instantanées avec un modèle d'interrogation consiste à interroger le serveur à une fréquence suffisamment élevée (toutes les cinq secondes, par exemple), de sorte que lorsqu'un nouveau message arrive, vous puissiez le voir presque instantanément. Une telle méthode risquerait cependant de nous empêcher d'atteindre nos objectifs de performances : avec un intervalle d'interrogation de cinq secondes, la pile radio du réseau ne serait jamais en veille, l'autonomie de la batterie serait très limitée et les ordinateurs de bureau devraient rester sous tension en permanence. Au final, cela reviendrait à rester au téléphone toute la journée : la batterie de votre téléphone ne survivrait pas longtemps à un tel traitement. Par ailleurs, il serait totalement vain de contacter le serveur toutes les cinq secondes, car la plupart du temps, aucun élément nouveau ne serait détecté. Par le passé, les notifications affichées dans la barre d'état système et les gadgets de bureau introduits dans Windows Vista étaient implémentés via un mécanisme d'interrogation. Avec ce type de mécanisme, l'intervalle s'avère toujours trop long pour les services en temps réel modernes, qui sont instantanés.

Ainsi, pour Windows 8, nous avons mis en place un service de transmission de type push. Cette décision ne fut pas prise à la légère, car elle nous a obligés à créer une plateforme globale, capable d'assurer l'affichage de centaines de milliers d'applications auprès de plus d'un milliard d'utilisateurs. Cependant, l'avantage était clair : les développeurs allaient pouvoir distribuer des notifications en temps réel auprès de leurs clients, de façon gratuite et très efficace, sans devoir créer ni gérer leurs propres connexions persistantes auprès du client.

La plateforme de notifications push

Examinons de plus près les différents composants de la plateforme afin de détailler les subtilités de cette architecture. Le schéma ci-dessous montre trois entités principales :

  1. Windows Push Notification Service (WNS) : ce service est utilisé par les mosaïques dynamiques et les notifications toast.
  2. Service de l'application : il s'agit du service Web exécuté par les applications de style Metro (à partir de leur site Web existant, par exemple), qui envoie les notifications toast et les mises à jour des mosaïques via WNS. Il peut par exemple s'agir du service principal de l'application météo fournie dans la version Developer Preview ou d'un service principal hébergeant les photos d'une application de réseau social.
  3. Plateforme cliente Windows 8 : elle correspond au PC et aux sous-éléments du système d'exploitation, qui forment le système de connexions englobant l'expérience utilisateur.

Trois images sont affichées : App Back-End Service (Service principal de l'application), Windows Push Notification Service (WNS) (qui contient également une section « Cache ») et Windows 8 Client Platform (qui contient également les zones « Tile renderer » (Moteur de rendu des mosaïques), « Image Cache » (Cache d'images) et « WNS Connection » (Connexion WNS). Une flèche associée à la légende « 1. Push notification » (Transmission des notifications en mode push) est tracée entre App Back-End Service et WNS. Une flèche associée à la légende « 2. Notification » est tracée entre WNS et la partie WNS Connection (Connexion WNS) de la section Client Platform (Plateforme cliente). Une flèche à deux directions, libellée « 3. Fetch images » (Récupération des images) est tracée entre la section App Back-End Service et la partie Image Cache (Cache d'images) de la section Client Platform.
Figure 2 : la plateforme de notifications push

Examinons maintenant un scénario d'utilisation type pour comprendre le fonctionnement de ce processus. Imaginons que le service de l'application est un site de réseau social qui envoie une mise à jour de mosaïque lorsque quelqu'un commente votre photo (il peut également s'agir d'une application métier qui m'envoie une notification lorsqu'un bogue m'est affecté ou lorsque je reçois une note de frais à valider, par exemple). Lorsqu'une mise à jour est disponible, le service de l'application envoie une notification au service WNS (Étape 1 sur le schéma ci-dessus). Ensuite, le service WNS transmet la notification au client en mode push (Étape 2). Lorsque vient le moment d'afficher la mise à jour de la mosaïque dans l'écran Démarrer, le système d'exploitation récupère cette image auprès du service de l'application, grâce à l'URL contenue dans le code XML de la notification (Étape 3). Une fois que la notification et l'image ont été téléchargées, l'application génère le rendu de la mosaïque dynamique, en fonction du modèle spécifié dans le code XML, puis l'affiche dans l'écran Démarrer.

Comme nous l'avons déjà expliqué, l'un de nos objectifs était de simplifier le travail des développeurs. Aussi, pour que ceux-ci ne soient pas obligés d'écrire des mécanismes complexes de mise en cache et d'exécution de nouvelles tentatives dans les cas où le PC n'est pas connecté (ordinateur portable en veille prolongée, par exemple), nous mettons en cache une notification par application dans le cloud WNS, jusqu'à la prochaine connexion du PC au réseau.

Lors de la conception des différents éléments de la plateforme cliente, nous avons veillé à ce que tous les composants soient conçus pour offrir des performances optimales avec une consommation électrique minimale. L'un des éléments essentiels de ce processus a consisté à séparer la charge utile des notifications de celle des images. Le code XML d'une notification standard contient moins d'un kilo-octet de données, alors que la taille des images peut atteindre 150 Ko. En séparant ces charges utiles, nous avons pu économiser de la bande passante dans les cas où les images font l'objet de nombreuses duplications. Par exemple, l'image d'une mosaïque peut être l'image de profil d'un ami, que votre PC télécharge une fois et met en cache pour la réutiliser ultérieurement. En séparant la notification de l'image, nous avons également pu gérer de façon plus astucieuse l'abandon des notifications inutilisées et éviter de télécharger l'image. Si l'écran de mon appareil est éteint et que celui-ci reste dans ma chambre pendant que je suis au travail, il est inutile que les images soient systématiquement téléchargées, pour finalement être remplacées par d'autres images, jusqu'à ce que j'utilise à nouveau l'appareil.

Le modèle d'authentification

Les mosaïques dynamiques et les notifications jouent un rôle essentiel dans l'expérience utilisateur des applications. Aussi, il est indispensable que le canal de communication soit authentifié et sécurisé, dès le service de l'application et jusqu'à la mosaïque affichée dans votre écran Démarrer. En effet, si une application ou un service Web malveillant pouvait mettre à jour n'importe quelle mosaïque sur votre appareil, les conséquences pourraient être fâcheuses. Pour cette raison, nous utilisons un mécanisme d'authentification anonyme, qui identifie de façon unique la connexion entre le PC et WNS. Les applications et les services des applications s'authentifient également lorsqu'ils communiquent avec le service WNS. En authentifiant les deux connexions avec le service WNS, nous protégeons le système vis-à-vis des mises à jour abusives de mosaïques dynamiques, par exemple dans le cas d'attaques par usurpation. Le mécanisme d'authentification utilisé par le service WNS associe explicitement l'application et le service, de telle sorte que les autres applications (ou les individus malintentionnés) ne puissent pas envoyer à une mosaïque un contenu qui ne leur appartient pas. Bien évidemment, toutes les communications passent par un canal sécurisé.

Tout ceci fonctionne de la même manière, que vous vous connectiez ou non à Windows par le biais d'un identifiant Windows Live ID. Comme l'a très justement souligné Katie Frigon dans son billet consacré à l'ouverture de session à l'aide d'un identifiant Windows Live ID, Windows 8 est encore plus performant lorsque votre compte est connecté, car vous pouvez alors profiter de fonctionnalités supplémentaires : stockage des applications dans le cloud, itinérance des paramètres de Windows et des applications, authentification unique auprès de plusieurs applications, etc. La plateforme de notifications push utilisant un mécanisme d'authentification anonyme, et ce, même si vous vous connectez en utilisant un identifiant Windows Live ID, le développeur de l'application ne peut pas utiliser le pipeline de notification pour connaître votre identifiant Windows Live ID, vos informations système ou votre position géographique.

Création d'un service évolutif

Comme nous l'avons déjà évoqué ci-dessus, nous devions mettre au point une plateforme capable de prendre en charge une quantité très élevée d'utilisateurs et d'applications. Pour vous donner une idée, le graphique ci-dessous indique le nombre de notifications envoyées chaque jour à Windows 8 par les applications. Il y a deux semaines environ, nous envoyions déjà près de 90 millions de mises à jour de mosaïque chaque jour, alors même que la version bêta n'est pas encore disponible !

Le graphique montre un nombre nul de notifications le 12 septembre 2011, qui montre à 64 millions environ le 16 septembre, avant de retomber à 36 millions le 18. Les notifications augmentent ensuite progressivement, pour se stabiliser à 80-85 millions début octobre.
Figure 3 : nombre de notifications envoyées chaque jour à la version Developer Preview de Windows 8

Parmi les applications disponibles dans la version Developer Preview, l'application boursière Stocks est l'une des plus prisées. Le graphique ci-dessous indique le nombre total de mosaïques dynamiques enregistrées auprès de cette application au cours du mois suivant la mise à disposition de la version Developer Preview.

Nombre total de mosaïques dynamiques pour l'application Stocks
Figure 4 : mosaïques dynamiques enregistrées auprès de l'application Stocks proposée dans la version Developer Preview

Dès la publication de la version Developer Preview, nous avons commencé à analyser le trafic entrant de nos centres de données, afin de surveiller la montée en charge. Voici une représentation de la répartition géographique des notifications, au cours des premiers jours qui ont suivi la publication de la version Developer Preview à l'occasion de la conférence //build. Les données représentent le nombre d'unités par mile carré et ont été adaptées à une échelle logarithmique, afin de prendre en compte les disparités en termes de densité.


Téléchargez cette vidéo pour la regarder sur votre lecteur habituel :
MP4 haute qualité | MP4 faible qualité

La conception du service WNS s'appuie sur l'architecture du service Windows Live Messenger. La partie service de la plateforme de notification a d'ailleurs été conçue par la même équipe. Peu d'équipes possèdent les compétences et le savoir-faire requis pour créer un service aussi évolutif à l'échelle mondiale, capable de supporter une montée en charge aussi rapide. Voici quelques statistiques permettant de mieux comprendre l'ampleur du service actuel de Windows Live Messenger :

  • 300 millions d'utilisateurs actifs chaque mois
  • 630 millions de connexions par jour
  • 10 milliards de notifications par jour
  • Plus de 40 millions de connexions simultanées
  • Plus de 3 000 machines dans le monde, chargées de rediriger les messages

Une meilleure visibilité sur les ressources utilisées par les mosaïques, grâce au Gestionnaire des tâches

Pour optimiser les performances de la plateforme de notification, nous avons été jusqu'à ajouter des statistiques au nouveau Gestionnaire des tâches, afin de vous permettre de surveiller la consommation de bande passante de la plateforme de mosaïques pour chacune de vos applications. En général, les ressources utilisées par les mosaïques restent relativement faibles. Ceux d'entre vous qui utilisent la version Developer Preview peuvent accéder à l'onglet App History (Historique de l'application) du Gestionnaire des tâches et examiner la colonne « Tiles » (Mosaïques) pour connaître la consommation en bande passante de vos mosaïques dynamiques sur les 30 derniers jours.

Carte thermique de l'historique de consommation des applications de style Metro entre le 17 septembre et le 17 octobre 2011. L'application « News » a utilisé environ 71,9 Mo pour la partie Network (Réseau), 57,2 Mo pour la partie Metered Network (Réseau contrôlé), mais seulement 0,1 Mo pour la partie Tiles (Mosaïques). 18 applications figurent dans la liste et toute présentent une consommation comprise entre 0 et 0,1 Mo dans la colonne « Tiles ».
Figure 5 : ressources utilisées par les mosaïques dynamiques, indiquées dans l'onglet App History du Gestionnaire des tâches

Récapitulatif

Lors de la mise au point de Windows 8, nous nous sommes efforcés de concevoir une plateforme de notification capable de fournir des informations rapidement, sans pour autant engendrer les problèmes d'autonomie et de performances rencontrés par les modèles classiques de plug-ins et de gadgets. Pour cela, chaque décision de conception a été prise en tenant compte des performances et de l'autonomie. Pour faciliter la participation des développeurs d'applications, nous avons mis au point le service Windows Push Notifications Service, qui leur permet de créer des mosaïques dynamiques sans les obliger à mettre au point un code complexe de connectivité réseau. Comme le service WNS exploite les technologies standard du Web (HTTP POST, par exemple), les développeurs peuvent facilement intégrer des notifications à partir de leurs services Web existants.

Au final, notre plateforme de notification diffuse les informations plus rapidement que jamais et vous pouvez installer autant d'applications que vous le souhaitez, sans avoir à vous soucier des performances du système ou de l'autonomie.

--Ryan Haveson

  • Loading...
Leave a Comment
  • Please add 8 and 7 and type the answer here:
  • Post