Написание фоновых мультимедийных приложений, позволяющих экономить энергию (HTML)
[ Эта статья адресована разработчикам приложений среды выполнения Windows для Windows 8.x и Windows Phone 8.x. В случае разработки приложений для Windows 10 см. раздел последняя документация]
Введение
Одно из новшеств Windows 8 — режим питания "всегда включен, всегда подключен" (AOAC). Благодаря ему ваше приложение будет потреблять очень мало энергии, оставаясь подключенным и отвечающим на вызовы. Этот новый энергосберегающий режим называется "режим ожидания с подключением". Задача этого режима — снижение энергопотребления при воспроизведении звуковых файлов, которое позволит мультимедиа-приложениям фонового режима воспроизводить аудиозаписи в течение нескольких часов без повторной зарядки батареи.
Чтобы режим ожидания с подключением был эффективен, сетевое подключение должно перейти в состояние пониженного энергопотребления. При этом мультимедиа-приложение фонового режима не сможет произвольно подключаться к сети. В то же время источники Microsoft Media Foundation смогут воспроизводить содержимое, передаваемое по сети (например, через звуковой тег HTML5) — как файлы, расположенные в сети, так и потоки мультимедиа, если вы используете входящие источники. Но для обмена другими данными по сети, например номерами лицензий, метаданными или пользовательской статистикой, потребуются дополнительные действия.
Это касается только приложений, воспроизводящих звуковые файлы в фоновом режиме. Дополнительные сведения см. в разделе Воспроизведение звука в фоновом режиме.
Доступ к сети
Мультимедиа-приложения фонового режима могут выходить в сеть тремя способами.
Background transfer API. Это оптимальный вариант. Просто отправляйте дополнительные вызовы сети с помощью API фоновой передачи, как при отправке и скачивании файлов. Все остальное будет сделано за вас. Дополнительные сведения см.в разделе Windows.Networking.BackgroundTransfer.
Wrap an existing MF bytestream. API фоновой передачи служат для передачи данных и могут быть слишком громоздкими для быстрых сетевых коммуникаций. При создании экземпляра источника Media Foundation или байтового потока сетевую ссылку принимает Windows. Это относится также к пользовательским источникам Media Foundation и байтовым потокам. С полностью пользовательскими источниками Media Foundation и байтовыми потоками работать довольно сложно, поэтому для байтовых потоков лучше создать программу-оболочку. После инициализации приложение сможет использовать сеть с помощью любых сетевых API. После обмена данными с сетью программа-оболочка запускает входящий байтовый поток. В свою очередь входящий байтовый поток после завершения работы отключает сеть.
Пример пользовательского источника см. в примере связи в реальном времени.
Пример взаимодействия приложения и источника см. в примере источника передачи мультимедиа.
Fully custom Media Foundation source or bytestream. напоминает вариант 2, но разработчик не задействует входящие компоненты, а полностью создает источник Media Foundation или байтовый поток. В этом случае вы должны уведомить Media Foundation, опубликовав сообщение об изменении характеристик. На рисунке показан пример блок-схемы.
- Примеры пользовательских источников см. в варианте 2.
- Для байтовых потоков нужно установить флажок MFBYTESTREAM_DOES_NOT_USE_NETWORK = 0x00000800. Тогда должно сработать событие MEByteStreamCharacteristicsChanged.
- Для источников нужно установить флажок MFMEDIASOURCE_DOES_NOT_USE_NETWORK = 0x80. Тогда должно сработать событие MESourceCharacteristicsChanged.
Ниже пример двух списков воспроизведения, использующих варианты 2 или 3.
Если для вашего приложения не подходит ни одно из этих решений, обратитесь к lpa_questions@microsoft.com. Подробно опишите сценарий вашего приложения и объясните, почему предложенные варианты вам не подходят.
Прочие аспекты
Кроме проверки взаимодействия вашего приложения с сетью есть еще несколько моментов, которые нужно учесть, разрабатывая мультимедиа-приложение с низким энергопотреблением. Поскольку приложение может работать, когда система практически полностью приостановлена, при разработке приложения необходимо помнить о его энергопотреблении. Предусмотрите для приложения индивидуальный энергосберегающий режим и уведомления об изменении видимости (уведомления нужны, когда приложение работает в фоновом режиме и когда устройство переходит в режим ожидания с подключением).
- Не обновляйте пользовательский интерфейс. Если приложения не видно, то все, что связано с графикой или интерфейсом, будет расходовать энергию впустую.
- Откажитесь от всего лишнего. То же касается и обновлений пользовательского интерфейса. Все, что не нужно в отсутствие пользователя, не нужно и в случае, когда приложения не видно.
- Объединяйте данные, передаваемые по сети, в пакеты. Чем дольше приложение может обходиться без существенного расхода времени ЦП или сети, тем лучше.
- В режиме ожидания с подключением операции могут занимать больше времени. При этом приложение регулируется и может использовать ЦП ограниченное время.
- Чтобы обеспечить оптимальное потребление ресурсов, ограничьте число звуковых тегов, одновременно используемых приложением, до одного-двух (это относится и к тегам, которые инициализируются, но не воспроизводятся).