Updates von Live-Kacheln ohne den Akku zu leeren

Die Entwicklung von Windows 8

Einblicke in die Arbeit des Windows-Entwicklerteams

Updates von Live-Kacheln ohne den Akku zu leeren

  • Comments 0

Eine der Ideen, die für all unsere „Bildschirme“ mehr und mehr zum Allgemeingut wird, sind ressourcenschonende Benachrichtigungen. Ursprünglich sollten diese Art von Funktionen mithilfe von Windows-Gadgets bereitgestellt werden. Die Idee war die schnelle Heads-Up-Anzeige wichtiger Informationen (z. B. Nachrichten, Wetter, Sportergebnisse oder Unternehmensereignisse). Die Startzeit und das Modell der Gadgets sind jedoch weder mit der (sowohl für Desktopcomputer als auch für Laptops wichtigen) Verringerung des Gesamtenergieverbrauchs noch mit der Bereitstellung einer Vollbildschirmplattform für Entwickler vereinbar. Zudem bietet der Startbildschirm von Windows 8 eine weitaus größere Fläche für derartige Benachrichtigungen sowie eine Benutzeroberfläche für die Verwaltung der Updates (einschließlich der Verwendung von Netzwerkressourcen). Bei einer modernen Oberfläche, auf der immer mehr Informationen als Pushbenachrichtigungen und strukturierte Ausschnitte zur Verfügung gestellt werden, stellt dies eine einmalige Gelegenheit für Entwickler und Endbenutzer dar. In diesem Beitrag schreibt Ryan Haveson über die Entwicklung von Live-Kacheln im Metro-Stil. Zudem erläutert er, wie die Architektur zu einer großen Anzahl an Kacheln skaliert werden kann, während gleichzeitig der Gesamtenergieverbrauch und die Systemlast verringert werden.
–Steven Sinofsky

Wir alle wissen, dass die Leistung und Akkulebensdauer für erfolgreiche Windows-Versionen von entscheidender Bedeutung sind. Auch in Ihren Kommentaren werden diese Aspekte immer wieder hervorgehoben. @KISSmakesmeSMILE fasste dies so zusammen:

"…versuchen Sie, die … Akkulebensdauer [der Wettbewerber] durch eine ressourcenschonende Verwendung zu erreichen oder gar zu übertreffen."

Gleichzeitig wissen wir, dass alle modernen Umgebungen (von Computern über Fernsehgeräte bis hin zu Telefonen) über verschiedene Formen von Gadget-, Widget- oder Plug-In-Modellen verfügen, mit denen Informationen auf einen Blick erfasst werden können. Bei den Nachrichten-, Sport- oder Wettersendungen im Fernsehen werden strukturierte Bildschirme voller Informationen eingesetzt, die aus verschiedenen Quellen in Echtzeit zusammengeführt werden. Die Benutzer möchten dazu in der Lage sein, ihre Aktien, das Wetter, ihre E-Mails, den nächsten Termin, den Stand der Branche oder Neues aus sozialen Netzwerken in Sekundenschnelle abzurufen, um sich anschließend sofort wieder ihrer vorherigen Beschäftigung zuzuwenden. Hier ist der Einwurf angebracht, dass der Computer auf diesem Gebiet im Vergleich zu anderen Geräten in vielfacher Hinsicht aufzuholen hat. Beim Entwerfen unserer Benachrichtigungsinfrastruktur bestand die wesentliche Herausforderung darin, den Computer mit vielen Echtzeitfeatures auszustatten, ihn jedoch andererseits hinsichtlich des Energie- und Bandbreitenverbrauchs weiterhin effizient zu halten. In den Worten von @AndyCadley wird dieses Ziel gut ausgedrückt:

"Behandelt all eure Metro-Anwendungen so, als würden sie ständig ausgeführt (ohne sich jedoch auf den Akku oder die Leistung auszuwirken)"

Aus der Benutzerperspektive ist dies auch für den Startbildschirm effizient, da eine Heads-Up-Vollbildanzeige umgesetzt wird, die sich jedoch nicht mit den Desktop- oder Metro-Stil-Anwendungen überschneidet, wenn Sie mit diesen arbeiten. Außerdem war unser Ziel nicht nur eine effiziente Lösung, sondern auch, sicherzustellen, dass Sie beliebig viele Benachrichtigungsanwendungen installieren können, ohne sich über die Auswirkungen auf die Leistung oder die Akkulebensdauer kümmern zu müssen.

Bei der internen Verwendung von Windows 8 stellten wir u. a. fest, dass die Möglichkeit, den Startbildschirm als vereinheitlichte und gut lesbare Heads-Up-Anzeige für Unternehmensanwendungen zu einer Produktivitätssteigerung führt. Wir stellen ein großes Interesse an Anwendungen fest, bei denen es primär um Benachrichtigungen geht. Dank der Skalierbarkeit der neuen Pushbenachrichtigungsplattform kann dies unter Windows 8 mit minimalen Auswirkungen auf das System erreicht werden. Dies ist eine bedeutende Verbesserung im Vergleich zu der Vielzahl an derzeit unter Windows vorhandenen Mechanismen. Es ist problemlos ein Szenario vorstellbar, in dem selbst überzeugteste Desktop-Benutzer den Wert des Startbildschirms als zentralisierten und sinnvoll angeordneten (sowie steuerbaren) Benachrichtigungsbereich erkennen, der nur einen Tastendruck entfernt ist.

Ziele der Benachrichtigungsplattform

Wenn einerseits Hunderte von Anwendungskacheln mit Live-Aktivitäten dargestellt und gleichzeitig sichergestellt werden soll, dass die Leistung nicht beeinträchtigt wird, mag dies widersprüchlich erscheinen. Schließlich verbraucht "Aktivität" per Definition Ressourcen: Beim Erhalt einer Benachrichtigung aus einer Cloud wird das Netzwerk genutzt, beim Darstellen der Benachrichtigung in einer Kachel werden GPU-/CPU-Ressourcen verbraucht, usw. Für einen gelungenen Entwurf mussten wir uns auf unsere ursprünglichen Ziele konzentrieren:

  • Ermöglichen Hunderter von Live-Kacheln ohne Leistungseinbußen
  • Mehr als Sprechblasen, Infoanzeigen und Text mit schönen Bildern
  • Vereinfachte Entwicklung für problemloses Erstellen Anwendungen
  • Erreichen von Echtzeitbereitstellung, sodass die Bereitstellung von "Sofortnachrichten" direkt erfolgt

Auf Grundlage dieser Ziele bestand die erste grundlegende Architekturentscheidung darin, eine datengesteuerte Plattform zu erstellen, sodass im Hintergrund kein Anwendungscode für den Startbildschirm ausgeführt wird.

Die Anatomie eines Systems für die Bereitstellung von Benachrichtigungen besteht aus mehreren Komponenten: Die Logik für Verbindungen, Authentifizierung, lokales Zwischenspeichern, Rendering, Fehlerbehandlung, Backoff-Algorithmen, Auslösen usw. Zudem muss das System mit dienstseitigen Problemen umgehen (z. B. erkennen, ob eine Verbindung besteht oder nicht), damit nicht übertragene Inhalte zwischengespeichert und komplexe Szenarien durch erneutes Versuchen gelöst werden können. Angenommen, jede einzelne Anwendung mit einer Live-Kacheln verfügt über eine eigene Version dieses gesamten Client-/Servercodes. Nicht nur würden die einzelnen Implementierungen Fehler aufweisen, es entstünden zudem Duplikate desselben Codes für die einzelnen im Speicher geladenen Anwendungen, sodass unablässig Code von der Festplatte ein- und ausgelagert würde. Dies wäre wirklich ineffizient, da alle Anwendungen fortwährend ausgeführt würden, um den Startbildschirm aktuell zu halten. Selbst auf einem Computer mit sehr viel Speicher würde die Systemleistung früher oder später beeinträchtigt werden.

Wenn Sie Bill Karagounis’ Beitrag zur Verringerung der Speicherauslastung unter Windows 8 gelesen haben, wissen Sie, dass die Leistung mit der Anzahl ausgeführter Prozesse, DLLs, Dienste usw. abnimmt. Wenn jede Live-Kachel mit einem eigenen Code ausgeführt wird, ist unser erstes Ziel, die Möglichkeit zum Ausführen hunderter Live-Kacheln ohne Leistungseinbußen, nicht umsetzbar.

Unsere Lösung bestand in der Entwicklung eines datengesteuerten Modells. Auf diese Weise können Entwickler eigene Kacheln mithilfe vordefinierter Eigenschaften und Vorlagen (in diesem Fall eines XML-Schemas) erstellen. Die XML-Kacheldaten werden anschließend über ein einfaches HTTP POST an die Windows-Pushbenachrichtigungsdienste (WNS) gesendet, und wir übernehmen den Rest. Der gesamte Code für Verbindungen, erneute Versuche, Authentifizierung, Zwischenspeicherung, Rendering, Fehlerbehandlung usw. wird auf einheitliche und energieeffiziente Weise ausgeführt.

Hier finden Sie ein Beispiel für eine der vielen Kachelvorlagen, die Entwickler für ihre Windows 8-Anwendungen verwenden können. Diese besteht aus einem Textfeld und einem einzelnen Bild. Es stehen jedoch auch viele andere Vorlagen zur Verfügung.

Bild eines Surfers mit RSS-Feed-Symbol und Text "Erster aufgezeichneter Surfboard-Kickflip in Santa Cruz"
Abbildung 1: Beispielvorlage (TileWideImageAndText)

Im Folgenden finden Sie den entsprechenden XML-Code für die Beschreibung der oben abgebildeten Kachel:

<?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>

Dank der Entscheidung für ein datengesteuertes Modell konnten wir die ersten beiden Ziele umsetzen (Leistung und gut designte Benutzeroberfläche). Wir mussten jedoch weiterhin an der Echtzeitbereitstellung und einer problemlosen und unkomplizierten Effizienz arbeiten.

Für die Client-/Serverbereitstellung von Inhalten gibt es zwei allgemeine Entwurfsmuster: Abrufen und Push. Abrufen bedeutet, dass der Client den Dienst regelmäßig (z. B. alle 90 Minuten) auf neue Inhalte prüft. Bei Push werden neue Inhalte vom Dienst direkt an den Client gesendet.

Die einzige Möglichkeit, Sofortnachrichten in einem Abrufmodell zu unterstützen, besteht darin, ausreichend häufig abzurufen (z. B. alle fünf Sekunden), damit neue Nachrichten mehr oder minder umgehend angezeigt werden. Dies ginge jedoch zu Lasten der Leistungsziele. Bei einem Abrufintervall von fünf Sekunden wäre der Netzwerkstapel niemals im Leerlauf, die Akkulebensdauer wäre grauenvoll und Desktopcomputer müssten ständig eingeschaltet sein. Es wäre, als ob Sie den ganzen Tag mit Ihrem Handy telefonierten – Ihr Akku würde das nicht lange mitmachen. Zudem wäre es äußerst verschwenderisch, den Server alle fünf Sekunden nach neuen Inhalten abzurufen, die zumeist gar nicht vorhanden sind. Bislang wurden die in Vista eingeführten Taskleistenbenachrichtigungen und Desktopgadgets über einen Abrufmechanismus implementiert. Allerdings verfügen sämtliche Abrufmechanismen nach wie vor nicht über Intervalle, die für die Sofortbenachrichtigungen moderner Echtzeitdienste kurz genug sind.

Daher wurde für Windows 8 ein pushbasierter Dienst entwickelt. Dies war eine weitreichende Entscheidung, da eine Plattform von globalem Ausmaß entwickelt werden musste, die Kacheln für Hunderttausende von Anwendungen und mehr als eine Milliarde Nutzer ermöglichen sollte. Der Vorteil hingegen lag auf der Hand: Entwickler können ihren Kunden auf äußerst effiziente Weise kostenlose Echtzeitbenachrichtigungen zur Verfügung stellen, ohne eine eigene dauerhafte Verbindung zum Client herzustellen oder aufrecht erhalten zu müssen.

Die Pushbenachrichtigungsplattform

Betrachten wir die verschiedenen Komponenten der Plattform genauer, um eine der feineren Entwurfsdetails zu erläutern. Im folgenden Diagramm finden Sie die drei wichtigsten Komponenten:

  1. Windows-Pushbenachrichtigungsdienste (WNS): Diese ermöglichen die Live-Kacheln und Toastbenachrichtigungen.
  2. Anwendungsdienst: Hierbei handelt es sich um den Webdienst, der von einer Anwendung im Metro-Stil (z. B. von deren vorhandenen Website) ausgeführt wird, um Toastbenachrichtigungen und Kachelupdates über WNS zu senden. Beispiele hierfür sind der Back-End-Dienst der Wetteranwendung der Developer Preview oder ein Back-End-Dienst, von dem Fotos für die Anwendung eines sozialen Netzwerks gehostet werden.
  3. Windows 8-Clientplattform: Diese entspricht dem eigentlichen Computer und den Unterkomponenten des Betriebssystems, die das Gerüst der End-to-End-Benutzeroberfläche bilden.

Drei Grafiken: Back-End-Anwendungsdienst, Windows Pushbenachrichtigungsdienste (WNS) (mit einem "Zwischenspeicher" umfasst) und Windows 8-Clientplattform (mit den Feldern "Kacheldarstellung", "Bildzwischenspeicher" und "WNS-Verbindung"). Der Pfeil "1. Pushbenachrichtigung" zeigt vom Back-End-Dienst der Anwendung zu WNS. Der Pfeil "2. Benachrichtigung" zeigt von WNS zur WNS-Verbindung auf der Clientplattform. Der bidirektionale Pfeil "3. Bilder abrufen" verläuft zwischen dem Back-End-Dienst der Anwendung und dem Bildzwischenspeicher auf der Clientplattform.
Abbildung 2: Die Pushbenachrichtigungsplattform

Betrachten wir ein typisches Anwendungsszenario, um die Funktionsweise zu verdeutlichen. Gehen wir davon aus, dass es sich beim Anwendungsdienst um die Site eines sozialen Netzwerks handelt, die ein Kachelupdate sendet, wenn jemand Ihr Foto kommentiert. (Hierbei könnte es sich gleichermaßen um eine Unternehmensanwendung handeln, die darauf hinweist, dass dem Benutzer ein Fehler zugewiesen wurde, oder dass ein Kostenbericht geprüft werden muss.) Wenn ein Update vorliegt, sendet der Anwendungsdienst eine Benachrichtigung an WNS (Schritt 1 im oben abgebildeten Diagramm). Anschließend wird die Benachrichtigung von WNS an den Client übertragen (Schritt 2). Wenn das Kachelupdate auf dem Startbildschirm angezeigt werden soll, wird das Bild vom Betriebssystem anhand der in der Benachrichtigungs-XML enthaltenen URL vom Anwendungsdienst abgerufen (Schritt 3). Nachdem die Benachrichtigung und das Bild heruntergeladen wurden, stellt die Anwendung die Live-Kachel anhand der in der XML angegebenen Vorlage auf dem Startbildschirm dar.

Wie bereits erwähnt, ging es uns um einen problemlosen und unkomplizierten Ansatz. Um also sicherzustellen, dass die Entwickler keine komplexen Zwischenspeicherungs- und Wiederholungsmechanismen für nicht verbundene Computer (z. B. Laptops im Energiesparmodus) schreiben müssen, wird eine Benachrichtigung pro Anwendung in der WNS-Cloud zwischengespeichert, bis der Computer wieder online ist.

Beim Entwerfen der Clientplattformkomponenten wollten wir sicherstellen, dass alles auf eine hohe Leistung und einen geringeren Energieverbrauch ausgerichtet ist. Einer der wichtigsten Aspekte war hierbei die Trennung der Benachrichtigungs- von der Bildernutzlast. Eine typische Benachrichtigungs-XML verfügt über weniger als 1 KB an Daten, Bilder können jedoch bis zu 150 KB groß sein. Durch diese Trennung konnten wir in Szenarien, in denen viele identische Bilder auftreten, eine deutliche Einsparung an Netzwerkbandbreite erzielen. So kann es sich bei dem Bild einer Kachel beispielsweise um das Profilbild eines Freundes handeln, das einmalig auf Ihren Computer heruntergeladen und zur erneuten Verwendung lokal zwischengespeichert wird. Durch die Trennung der Benachrichtigung vom Bild können nicht verwendete Benachrichtigungen zudem intelligent verworfen werden, ohne zuvor das Bild herunterzuladen. Wenn mein Gerät mit ausgeschaltetem Bildschirm im Schlafzimmer liegt, während ich bei der Arbeit bin, müssen keine Bilder für Kacheln heruntergeladen werden, die durch neuere Updates ersetzt werden, bevor ich das Gerät das nächste Mal verwende.

Das Authentifizierungsmodell

Da Live-Kacheln und Benachrichtigungen einen wichtigen Teil der Benutzerfreundlichkeit der Anwendung bilden, sind die Authentifizierung und Sicherheit des Kommunikationskanals von großer Bedeutung – vom Anwendungsdienst über die Kachel bis hin zum Startbildschirm. Es gilt zu vermeiden, dass beliebige Kacheln auf Ihrem Computer von nicht autorisierten Anwendungen oder Webdiensten aktualisiert werden können. Daher verwenden wir einen Mechanismus zur anonymen Authentifizierung, der die Verbindung des Computers mit WNS eindeutig identifiziert. Anwendungen und Anwendungsdienste authentifizieren sich zudem bei der Kommunikation mit WNS. Durch die Authentifizierung beider WNS-Verbindungen sind Sie gegen Missbrauch der Live-Kachel-Updates wie z. B. durch Spoofing-Angriffe geschützt. Der von WNS verwendete Authentifizierungsmechanismus verknüpft die Anwendung mit dem Server auf eine Weise, die verhindert, dass andere Anwendungen (oder böswillige Personen) Inhalte an eine Kachel senden, die ihnen nicht gehört. Zudem erfolgt die gesamte Kommunikation selbstverständlich über einen sicheren Kanal.

All dies erfolgt unabhängig davon, ob Sie sich mit einer Windows Live ID bei Windows anmelden. Natürlich gilt, was Katie Frigon in ihrem Beitrag zur Anmeldung mit einer Windows Live ID erläutert: Windows 8 funktioniert am besten mit einem verbundenen Konto, da dies eine Vielzahl erweiterter Features ermöglicht, z. B. das Speichern von Anwendungen in einer Cloud, das Roaming von Windows und der Anwendungseinstellungen sowie das einmalige Anmelden für mehrere Anwendungen. Da für die Pushbenachrichtigungsplattform auch dann ein anonymer Authentifizierungsmechanismus verwendet wird, wenn Sie sich mit einer Windows Live ID anmelden, kann der Anwendungsentwickler die Benachrichtigungspipeline nicht zum Erkennen Ihrer Windows Live ID, Systeminformationen oder Standorte verwenden.

Erstellen eines skalierbaren Dienstes

Wie in diesem Beitrag bereits erwähnt, mussten wir eine Plattform entwickeln, die eine unglaublich große Zahl an Benutzern und Anwendungen unterstützt. Um das Ausmaß zu verdeutlichen, finden Sie in folgendem Diagramm die Anzahl der Benachrichtigungen, die täglich von Anwendungen an Windows 8 gesendet werden. Vor einigen Wochen sendeten wir bereits beinahe 90 Millionen Kachelupdates pro Tag, obwohl wir uns noch nicht einmal in der Beta-Phase befinden!

Das Diagramm zeigt die Benachrichtigungen am 12. 9. 2011 bei Null. Anschließend steigen sie auf bis zu 64 Millionen am 16. 9. 2011 an, um am 18. 9. 2011 wieder auf 36 Millionen zu fallen und Anfang Oktober Höchstwerte im Bereich von 80 bis 85 Millionen zu erreichen.
Abbildung 3: Täglich an die Windows 8 Developer Preview gesendete Benachrichtigungen

Die Börsenanwendung ist eine der beliebten Testanwendungen der Developer Preview. Im folgenden Diagramm finden Sie die Gesamtzahl der im ersten Monat nach der Veröffentlichung der Developer Preview für diese Anwendung registrierten Live-Kacheln.

Gesamtzahl der Live-Kacheln für die Börsenanwendung
Abbildung 4: Für die Börsenanwendung der Developer Preview registrierte Live-Kacheln

Seit der Veröffentlichung der Developer Preview haben wir den Datenverkehr durch die Rechenzentren beobachtet und die Skalierung sorgsam nachverfolgt. Im Folgenden finden Sie eine grafische Darstellung der tatsächlichen geografischen Verteilung der Benachrichtigungen in den ersten Tagen nach der Veröffentlichung der Developer Preview auf der //build/. Beachten Sie, dass die Daten Einheiten pro Quadratmeile entsprechen und einer logarithmischen Skala angepasst wurden, um die große Bandbreite an Dichtewerten berücksichtigen zu können.


Laden Sie dieses Video herunter, und spielen Sie es in einem geeigneten Media-Player ab:
MP4 in hoher Qualität | MP4 in niedriger Qualität

Der Entwurf von WNS beruht auf der Dienstarchitektur von Windows Live Messenger. Tatsächlich wurde die Dienstkomponente der Benachrichtigungsplattform vom gleichen Team erstellt. Es gibt weltweit nicht viele Teams, die über die Fachkenntnisse und das Wissen verfügen, einen global skalierbaren Dienst zu erstellen, der in so kurzer Zeit derartig große Zahlen bewältigen kann. Zur Verdeutlichung des aktuellen Umfangs des Windows Live Messenger-Diensts finden Sie im Folgenden einige statistische Werte.

  • Monatlich 300 Millionen aktive Benutzer
  • Täglich 630 Millionen Anmeldungen
  • Täglich 10 Milliarden Benachrichtigungen
  • Spitzenwerte von mehr als 40 Millionen gleichzeitiger Onlineverbindungen
  • Mehr als 3000 Computer, die weltweit Nachrichten weiterleiten

Transparenz des Ressourcenverbrauchs der Kacheln über den Task-Manager

Uns war der Leistungsaspekt der Benachrichtigungsplattform so wichtig, dass wir dem Task-Manager eine Metrik hinzufügten, mit der Sie die von der Kachelplattform für die einzelnen Anwendungen verbrauchte Bandbreite nachverfolgen können. In der Regel sollte der Ressourcenverbrauch für die Kacheln recht gering sein. Wenn Sie die Developer Preview ausführen, wechseln Sie im Task-Manager zur Registerkarte für den Anwendungsverlauf, und zeigen Sie die Spalte [Tiles] (Kacheln) an, um zu ermitteln, wie viel Bandbreite die einzelnen Live-Kacheln über die letzten 30 Tage verbraucht haben.

Heatmap des Nutzungsverlaufs von Anwendungen im Metro-Stil vom 17.9.2011 bis zum 17.10.2011. Die Anwendung "News" zeigt einen Verbrauch von 71,9 MB für das Netzwerk und von 57,2 MB für das getaktete Netzwerk, jedoch nur 0,1 MB für die Kacheln. Es werden 18 Anwendungen aufgeführt, die in der Spalte [Tiles] (Kacheln) jeweils nur einen Verbrauch von 0 oder 0,1 MB aufweisen.
Abbildung 5: Ressourcennutzung der Live-Kacheln im Anwendungsverlauf des Task-Managers

Zusammenfassung

Wir haben für Windows 8 eine Benachrichtigungsplattform entworfen, die auf einen Blick Informationen bereitstellt, und konnten die Probleme mit der Leistung und Akkulebensdauer vermeiden, die bei herkömmlichen Plug-In- und Gadgetmodellen auftreten. Zum Erreichen dieser Zielsetzungen erfolgten all unsere Entwurfsentscheidungen aus dem Blickwinkel der Leistung und der Effizienz der Akkulebensdauer. Damit Anwendungsentwickler problemlos mitwirken können, haben wir die Windows-Pushbenachrichtigungsdienste entwickelt, damit Live-Kacheln ohne komplizierten Netzwerkverbindungscode erstellt werden können. Da für WNS Standardwebtechnologien wie z. B. HTTP POST verwendet werden, können Entwickler Benachrichtigungen einfach auf Grundlage vorhandener Webdienste integrieren.

Auf diese Weise ist eine Benachrichtigungsplattform entstanden, die Informationen auf einen Blick bietet, und auf der Sie beliebig viele Anwendungen installieren können, ohne sich über die Auswirkungen auf die Leistung oder die Akkulebensdauer kümmern zu müssen.

–Ryan Haveson

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