Schreiben von energiesparenden, im Hintergrund ausgeführten Medien-Apps (HTML)

  • Artikel

[ Dieser Artikel richtet sich an Windows 8.x- und Windows Phone 8.x-Entwickler, die Windows-Runtime-Apps schreiben. Wenn Sie für Windows 10 entwickeln, finden Sie weitere Informationen unter neueste Dokumentation ]

Einführung

Zu den Neuerungen in Windows 8 gehört das AOAC-Energiesparmodell (Always On Always Connected). In diesem Modus verbraucht Ihre App nur sehr wenig Energie und ist trotzdem immer verbunden und aktiv. Dieser neue Energiesparzustand wird Verbindungsstandby (Connected Standby, CS) genannt. Mit diesem Zustand soll u. a. eine stromsparende Audiowiedergabe ermöglicht werden, sodass im Hintergrund ausgeführte Medien-Apps mit nur einer Akkuladung mehrere Stunden Audioinhalte wiedergeben können.

Um die Energieziele für den Verbindungsstandby zu erreichen, muss die Netzwerkverbindung in den Energiesparmodus wechseln. Das heißt, im Hintergrund ausgeführte Medien-Apps können nicht nach Belieben auf das Netzwerk zugreifen. Microsoft Media Foundation-Quellen können zwar weiterhin Netzwerkinhalte abspielen (z. B. über einen HTML5-Audiotag), die sich an Speicherorten an einer Netzwerkadresse oder, wenn Sie Eingangsboxquellen verwenden, auf Streamingmedien befinden. Wenn eine App jedoch aus anderen Gründen mit dem Netzwerk kommunizieren muss, z. B. für Lizenzüberprüfungen, Metadaten oder Benutzerstatistiken, sind weitere Schritte erforderlich.

Diese Anforderungen gelten nur für Apps, die Audioinhalte im Hintergrund wiedergeben. Weitere Informationen zur Audiowiedergabe im Hintergrund finden Sie unter So wird's gemacht: Wiedergeben von Audio im Hintergrund.

So wird's gemacht: Zugreifen auf das Netzwerk

Eine App, die Audioinhalte im Hintergrund wiedergibt, kann auf drei verschiedene Arten auf das Netzwerk zugreifen:

  1. Background transfer API. Dies ist die beste Option. Legen Sie zusätzliche Netzwerkaufrufe über die Hintergrundübertragungs-API einfach als Datei-Upload oder -Download fest. Das Ein- und Ausschalten des Netzwerks wird automatisch für Sie ausgeführt. Weitere Informationen finden Sie unter Windows.Networking.BackgroundTransfer.

  2. Wrap an existing MF bytestream. Die Hintergrundübertragungs-API wurde für den Transfer von Dateien entwickelt und eignet sich möglicherweise nicht für kleine, schnelle Netzwerkkommunikationsvorgänge. Wenn eine Media Foundation-Quelle oder ein Datenstrom instanziiert wird, verwendet Windows in dessen Namen eine Netzwerkreferenz. Dies gilt auch für benutzerdefinierte Media Foundation-Quellen und Datenströme. Vollständig benutzerdefinierte Quellen bzw. Datenströme sind sehr komplex. Um den Prozess zu vereinfachen, können Sie die Eingangsboxdatenströme wrappen. Nach der Initialisierung kann die App das Netzwerk jederzeit mit einer beliebigen Netzwerk-API verwenden. Wenn die Netzwerkvorgänge abgeschlossen sind, initiiert der Wrapper die Verwendung des Eingangsboxdatenstroms. Der Eingangsboxdatenstrom wiederum schaltet das Netzwerk nach Abschluss der Vorgänge aus.

    Ein Beispiel für eine benutzerdefinierte Quelle finden Sie unter Beispiel für Echtzeitkommunikation.

    Ein Beispiel für die Kommunikation zwischen einer App und einer Quelle finden Sie unter Beispiel für Media Stream Source (Mediendatenquelle).

  3. Fully custom Media Foundation source or bytestream. Diese Option ähnelt Option 2, es werden jedoch anstatt beliebiger Eingangsboxkomponenten vollständig vom Entwickler geschriebene Media Foundation-Quellen bzw. Datenströme verwendet. In diesem Fall müssen Sie nach Abschluss der Netzwerkvorgänge Media Foundation durch Ausgabe einer Merkmaländerung benachrichtigen. Die Abbildung zeigt ein Beispiel für den Datenfluss.

Hier sehen Sie ein Beispiel für eine Wiedergabeliste mit zwei Titeln unter Verwendung von Option 2 und Option 3.

Beispiel für den Datenfluss mit einer Wiedergabeliste mit zwei Titeln unter Verwendung von Option 2 und Option 3

Wenn für Ihre App keine dieser Lösungen in Frage kommt, schreiben Sie eine E-Mail an lpa_questions@microsoft.com. Beschreiben Sie das Verwendungsszenario möglichst genau, und erläutern Sie, warum die oben genannten Optionen in Ihrem Fall nicht funktionieren.

Weitere Überlegungen

Zum einen müssen Sie sicherstellen, dass Ihre App bei Bedarf auf das Netzwerk zugreifen kann. Es sind jedoch noch weitere Überlegungen bezüglich sparsamer Audio-Apps wichtig. Da die App auch ausgeführt werden kann, wenn der Großteil des Systems angehalten ist, müssen Sie bei der App-Entwicklung den Energiebedarf berücksichtigen. Verwenden Sie Benachrichtigungen für Sichtbarkeitsänderungen als Hinweis, um die App in ihren eigenen Energiesparmodus zu versetzen. Diese Benachrichtigungen werden angezeigt, wenn sich die App im Hintergrund befindet und wenn das Gerät in den CS wechselt.

  • Führen Sie keine Aktualisierung der UI durch. Wenn die App gerade nicht sichtbar ist, wird durch Grafik- oder UI-Vorgänge unnötigerweise Energie verbraucht.
  • Reduzieren Sie nach Möglichkeit die Anzahl der Vorgänge. Dies knüpft an die Überlegung in Bezug auf die UI-Aktualisierungen an. Das Ausführen von Vorgängen, die nur bei anwesendem Benutzer notwendig sind, ist sinnlos, wenn die App nicht sichtbar ist.
  • Verarbeiten Sie Netzwerkkommunikation im Stapel. Je länger die App ohne bedeutende CPU- oder Netzwerkverwendungszeit auskommt, umso besser.
  • Im Verbindungsstandby dauern Vorgänge möglicherweise länger. Die App wird im Verbindungsstandby gedrosselt, d. h., sie verfügt nur über einen begrenzten Zeitraum für die Ausführung auf der CPU.
  • Um eine optimale Nutzung der Audioressourcen sicherzustellen, verwenden Sie in Ihrer App jeweils nur ein oder zwei Tags gleichzeitig, einschließlich der Tags, die initialisiert werden, jedoch nicht aktiv wiedergeben.