These guides discuss the MediaCompat APIs, which are no longer updated. We strongly recommend using the Jetpack Media3 library instead.

Эта страница переведена с помощью Cloud Translation API.

Обзор архитектуры медиа-приложения,Обзор архитектуры медиа-приложения,Обзор архитектуры медиа-приложения

В этом разделе объясняется, как разделить приложение медиаплеера на медиаконтроллер (для пользовательского интерфейса) и медиасеанс (для реального проигрывателя). В нем описываются две архитектуры мультимедийных приложений: конструкция клиент/сервер, которая хорошо работает для аудиоприложений, и конструкция с одним действием для видеоплееров. Также показано, как заставить мультимедийные приложения реагировать на аппаратные средства управления и взаимодействовать с другими приложениями, использующими поток вывода звука.

Плеер и пользовательский интерфейс

Мультимедийное приложение, воспроизводящее аудио или видео, обычно состоит из двух частей:

Проигрыватель, который принимает цифровые медиафайлы и преобразует их в видео и/или аудио.
Пользовательский интерфейс с элементами управления транспортом для запуска проигрывателя и, при необходимости, отображения состояния игрока.

ui-and-player

В Android вы можете создать свой собственный плеер с нуля или выбрать один из следующих вариантов:

Класс MediaPlayer обеспечивает базовую функциональность простого проигрывателя, поддерживающего наиболее распространенные аудио- и видеоформаты и источники данных.
ExoPlayer — это библиотека с открытым исходным кодом, построенная на основе компонентов медиа-инфраструктуры нижнего уровня, таких как MediaCodec и AudioTrack . ExoPlayer поддерживает высокопроизводительные функции, такие как DASH, которые недоступны в MediaPlayer . Вы можете настроить код ExoPlayer, упрощая добавление новых компонентов. ExoPlayer можно использовать только с Android версии 4.1 и выше.

Медиа-сессия и медиа-контроллер

Хотя API-интерфейсы для пользовательского интерфейса и проигрывателя могут быть произвольными, характер взаимодействия между двумя частями в основном одинаков для всех приложений медиаплеера. Платформа Android определяет два класса: медиа-сеанс и медиа-контроллер, которые создают четко определенную структуру для создания приложения медиаплеера.

Медиа-сеанс и медиа-контроллер взаимодействуют друг с другом с помощью предопределенных обратных вызовов, которые соответствуют стандартным действиям проигрывателя (воспроизведение, пауза, остановка и т. д.), а также расширяемых пользовательских вызовов, которые вы используете для определения особого поведения, уникального для вашего приложения.

controller-and-session

Медиа-сессия

Медиа-сессия отвечает за все общение с игроком. Он скрывает API плеера от остальной части вашего приложения. Плеер вызывается только из медиа-сессии, которая его контролирует.

Сеанс поддерживает представление состояния игрока (воспроизведение/пауза) и информацию о том, что воспроизводится. Сеанс может получать обратные вызовы от одного или нескольких медиа-контроллеров. Это позволяет управлять вашим плеером с помощью пользовательского интерфейса вашего приложения, а также сопутствующих устройств под управлением Wear OS и Android Auto. Логика, отвечающая на обратные вызовы, должна быть последовательной. Ответ на обратный вызов MediaSession должен быть одинаковым независимо от того, какое клиентское приложение инициировало обратный вызов.

Медиа-контроллер

Медиа-контроллер изолирует ваш пользовательский интерфейс. Ваш код пользовательского интерфейса взаимодействует только с медиа-контроллером, а не с самим проигрывателем. Медиа-контроллер преобразует действия по управлению транспортировкой в обратные вызовы медиа-сеанса. Он также получает обратные вызовы из медиа-сеанса при каждом изменении состояния сеанса. Это обеспечивает механизм автоматического обновления связанного пользовательского интерфейса. Медиа-контроллер может одновременно подключаться только к одному медиа-сеансу.

Когда вы используете медиа-контроллер и медиа-сеанс, вы можете развертывать различные интерфейсы и/или проигрыватели во время выполнения. Вы можете изменить внешний вид и/или производительность вашего приложения независимо от возможностей устройства, на котором оно запущено.

Видеоприложения против аудиоприложений

При воспроизведении видео задействованы и глаза, и уши. При воспроизведении аудио вы слушаете, но одновременно можете работать с другим приложением. Для каждого варианта использования существует свой дизайн.

Видео приложение

Видеоприложению необходимо окно для просмотра контента. По этой причине видеоприложение обычно реализуется как единое действие Android. Экран, на котором появляется видео, является частью активности.

video player activity

Аудио приложение

Пользовательский интерфейс аудиоплеера не всегда должен быть видимым. Как только он начнет воспроизводить звук, плеер можно будет запустить в качестве фоновой задачи. Пользователь может переключиться на другое приложение и работать, продолжая слушать.

Чтобы реализовать этот дизайн в Android, вы можете создать аудиоприложение, используя два компонента: действие для пользовательского интерфейса и сервис для проигрывателя. Если пользователь переключается на другое приложение, служба может работать в фоновом режиме. Разделив две части аудиоприложения на отдельные компоненты, каждая из них может работать более эффективно сама по себе. Пользовательский интерфейс обычно недолговечен по сравнению с плеером, который может работать долгое время без пользовательского интерфейса.

Audio activity and BrowserService

Библиотека поддержки предоставляет два класса для реализации этого подхода клиент/сервер: MediaBrowserService и MediaBrowser . Компонент службы реализован как подкласс MediaBrowserService содержащий медиа-сеанс и его проигрыватель. Действия с пользовательским интерфейсом и медиа-контроллером должны включать MediaBrowser , который взаимодействует с MediaBrowserService .

Использование MediaBrowserService позволяет сопутствующим устройствам (например, Android Auto и Wear) легко обнаруживать ваше приложение, подключаться к нему, просматривать контент и управлять воспроизведением, вообще не обращаясь к активности пользовательского интерфейса вашего приложения. Фактически, к одному и тому же MediaBrowserService может быть подключено несколько приложений одновременно, причем каждое приложение имеет свой собственный MediaController . Приложение, предлагающее MediaBrowserService должно иметь возможность обрабатывать несколько одновременных подключений.

Медиа-приложения и аудиоинфраструктура Android

Хорошо спроектированное мультимедийное приложение должно «хорошо работать вместе» с другими приложениями, воспроизводящими звук. Он должен быть готов к совместному использованию телефона и взаимодействию с другими приложениями на вашем устройстве, использующими звук. Он также должен реагировать на аппаратные средства управления устройством.

plays-with-others

Все это поведение описано в разделе «Управление аудиовыходом» .

Библиотека медиа-совместимости

Библиотека медиа-совместимости содержит классы, полезные для создания приложений, воспроизводящих аудио и видео. Эти классы совместимы с устройствами под управлением Android 2.3 (уровень API 9) и выше. Они также работают с другими функциями Android, создавая удобный и привычный интерфейс Android.

Рекомендуемой реализацией медиа-сессий и медиа-контроллеров являются классы MediaSessionCompat и MediaControllerCompat , которые определены в библиотеке поддержки медиа-совместимости . Они заменяют более ранние версии классов MediaSession и MediaController , которые были представлены в Android 5.0 (уровень API 21). Классы совместимости предлагают ту же функциональность, но упрощают разработку приложения, поскольку вам нужно писать только для одного API. Библиотека обеспечивает обратную совместимость, переводя методы медиа-сессии в эквивалентные методы на старых версиях платформы, если они доступны.

Если у вас уже есть работающее приложение, использующее старые классы, мы рекомендуем обновить его до совместимых классов. Когда вы используете совместимые версии, вы можете удалить все вызовы registerMediaButtonReceiver() и любые методы из RemoteControlClient .

Измерение производительности

В Android 8.0 (уровень API 26) и более поздних версиях метод getMetrics() доступен для некоторых медиа-классов. Он возвращает объект PersistableBundle , содержащий информацию о конфигурации и производительности, выраженную в виде карты атрибутов и значений. Метод getMetrics() определен для следующих медиа-классов:

Метрики собираются отдельно для каждого экземпляра и сохраняются на протяжении всего времени существования экземпляра. Если метрики недоступны, метод возвращает значение null. Фактические возвращаемые метрики зависят от класса.