撰寫省電的背景媒體應用程式 (HTML)

[ 本文的目標對象是撰寫 Windows 執行階段 App 的 Windows 8.x 和 Windows Phone 8.x 開發人員。如果您正在開發適用於 Windows 10 的 App，請參閱 最新文件 ]

簡介

Windows 8 的新功能就是永不斷線 (AOAC) 電源模式。 這樣一來，您的應用程式可以耗用極少電力，但仍可維持連線並適時回應。 這個新的低電源狀態稱為連線待命 (CS)。 這個狀態的目標是啟用低電源音訊播放，讓背景媒體應用程式充一次電，就能連續播放數個小時。

為了達到連線待命的電源目標，網路連線必須進入低電源狀態。 這表示背景音訊應用程式無法隨心所欲存取網路。 Microsoft 媒體基礎來源仍可從網路檔案位置與串流媒體 (如果您使用收件匣來源) 播放已連接網路的內容，例如透過 HTML5 音訊標記。 但是，如果應用程式出於任何其他原因 (例如授權檢查、中繼資料或使用者統計資料) 而需要與網路通話，您就必須執行一些額外工作。

這些需求只適用於會在背景播放音訊的應用程式。 如需有關背景音訊播放的詳細資訊，請參閱如何在背景播放音訊。

如何存取網路

背景音訊應用程式存取網路的方法有三種：

1. **Background transfer API.**這是最佳選項。 只需透過背景傳輸 API 將其他網路呼叫當做檔案上傳或下載進行。 這樣就能為您完成連接和中斷網路的所有工作。 如需詳細資訊，請參閱 Windows.Networking.BackgroundTransfer。

2. **Wrap an existing MF bytestream.**背景傳輸 API 是針對檔案傳輸所設計，對於小型的快速網路通訊而言可能過於繁雜。 具現化媒體基礎來源或位元資料流時，Windows 會代它取得網路參考。 這也適用於自訂的媒體基礎來源和位元資料流。 完全自訂的來源或位元資料流相當複雜，為了簡化問題，您可以包裝收件匣位元資料流。 應用程式初始化之後，就可以視需要使用任一個網路 API 來使用網路。 網路使用完畢後，包裝函式就會開始使用收件匣位元資料流。 接著，收件匣位元資料流就會在完成時關閉網路。

   如需自訂的來源範例，請參閱即時通訊範例。

   如需有關應用程式與來源之間如何通訊的範例，請參閱媒體串流來源範例。

3. **Fully custom Media Foundation source or bytestream.**這與選項 2 很類似，但並不使用任何收件匣元件，而是由開發人員撰寫整個媒體基礎來源或位元資料流。 在這種情況下，您必須發出特性變更，將網路使用完成的消息通知媒體基礎。 下圖顯示流程範例。

   • 如需自訂來源範例，請參閱選項 2。
   • 如果是位元資料流，您必須設定 MFBYTESTREAM_DOES_NOT_USE_NETWORK = 0x00000800 旗標，且必須引發 MEByteStreamCharacteristicsChanged 事件。
   • 如果是來源，您必須設定 MFMEDIASOURCE_DOES_NOT_USE_NETWORK = 0x80 旗標，且必須引發 MESourceCharacteristicsChanged 事件。

以下是使用選項 2 或 3 的兩個歌曲播放清單範例。

如果這些解決方案都不適用於您的應用程式，請連絡 lpa_questions@microsoft.com。 請詳述確切使用狀況，以及上述選項不適用的原因。

其他考量

除了確認應用程式能夠正確存取網路之外，低電源音訊應用程式還有一些其他考量。 因為應用程式可在系統幾乎完全暫停時執行，所以當您開發應用程式時，務必考量電源需求。 將可見度變更通知 (當應用程式處於背景時，以及當裝置進入 CS 時，都會發出此通知) 當成提示，讓應用程式進入自己的低電源模式。

• 請勿執行任何 UI 更新。 如果看不到應用程式，那麼與圖形或 UI 相關的任何項目都會消耗不必要的電力。
• 盡可能減少工作。 這與 UI 更新緊密相關。 如果某個動作只有在使用者在場時才需要進行，就不需要在看不到應用程式時執行。
• 批次網路通訊。 應用程式使用的 CPU 越少越好，使用網路的時間也是越短越好。
• 連線待命時的作業時間較久。 應用程式在連線待命狀態時會進行節流處理，在 CPU 上執行的時間量也受到限制。
• 為了協助確保最佳音訊資源用量，您應該將應用程式同時使用的音訊標記數目 (包括可能已初始化但並未播放的音訊標記) 限制為一或兩個。