[ 本文适用于编写 Windows 运行时应用的 Windows 8.x 和 Windows Phone 8.x 开发人员。如果你要针对 Windows 10 进行开发，请参阅 最新文档 ]
简介
Windows 8 的新增功能是随时启用、始终连接 (AOAC) 电源模型。 采用这种方式后，你的应用只会耗费极少电量，同时仍能保持连接和灵敏响应。 这种新的低功耗状态称为连接待机 (CS)。 此状态的一个目标是启用低功耗音频播放，以便后台媒体应用可以在单次电池充电后播放许多个小时。
要达到连接待机的功耗目标，网络连接必须进入低功耗状态。 这意味着后台音频应用无法随意访问网络。 Microsoft 媒体基础源仍然可以播放网络上的内容，例如，如果你使用内置源，可从网络文件位置和流媒体，通过 HTML5 音频标记播放。 但是，如果应用由于其他原因需要与网络对话（例如许可证检查、元数据或用户统计信息），你就需要进行额外操作。
这些要求仅适用于在后台播放音频的应用。 有关后台音频播放的详细信息，请参阅如何在后台播放音频。
如何访问网络
后台音频应用可通过以下三种方式访问网络：
**Background transfer API.**这是最佳选项。 只需在文件上载或下载时，通过后台传输 API 进行额外网络调用。 系统将会为你完成开启或关闭网络的所有操作。 有关详细信息，请参阅 Windows.Networking.BackgroundTransfer。
**Wrap an existing MF bytestream.**后台传输 API 旨在用于文件传输，可能不适用于小型、快速的网络通信。 当媒体基础源或字节流实例化时，Windows 会代为进行网络引用。 这也适用于自定义媒体基础源和字节流。 完全自定义的源或字节流相当复杂，要简化问题，你可以包装内置字节流。 初始化后，应用可在必要时通过任何网络 API 使用网络。 当使用完网络后，包装器会初始化内置字节流的使用。 内置字节流反过来会在完成时关闭网络。
有关自定义源示例，请参阅实时通信示例。
有关如何在应用和源之间通信，请参阅媒体流源示例。
**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 的两首歌曲播放列表的示例。
.png "使用选项 2 或 3 的两首歌曲播放列表的示例流。")
如果这些解决方案都对你的应用不起作用，请联系 lpa_questions@microsoft.com。 请详细描述确切的使用情况以及为何上述选项对你不起作用。
其他注意事项
对于低功耗音频应用，除了确保应用正确访问网络之外，还有一些其他注意事项。 因为应用可以在大部分系统暂停时运行，你必须在开发应用时，时刻考虑到功耗需求。 使用可见性更改通知（会在应用位于后台以及设备进入连接待机时发生）作为提示，将应用切换到其低功耗模式。
- 不要执行任何 UI 更新。 如果应用不可见，任何相关的图形或 UI 会不必要地耗电。
- 你应该尽可能减少工作量。 这与 UI 更新有很紧密的关联。 如果某项工作没有必要，除非用户存在，则在应用不可见时执行这一工作是毫无意义的。
- 批处理网络通信。 在 CPU 或网络使用时间较低的情况下，应用运行的时间越长越好。
- 在连接待机中，操作可能需要更长时间。 在连接待机中，应用会受到限流，只有有限的时间量在 CPU 上运行。
- 为了有助于确保最佳的音频资源使用情况，你应该将应用程序中使用的音频标记数量限制为同时只有 1 或 2 个（包括可能已经初始化但并未主动播放的标记）。