Android Dev Summit, October 23-24: two days of technical content, directly from the Android team. Sign-up for livestream updates.

Descripción general de la arquitectura de las apps multimedia

En esta sección se explica la manera de separar una app de reproducción multimedia en un controlador multimedia (para la IU) y una sesión multimedia (para el reproductor). Se describen dos arquitecturas de apps multimedia: un diseño de cliente y servidor que funciona bien para apps de audio, y un diseño de actividad individual para reproductores de video. También se muestra la manera de lograr que las apps multimedia respondan a controles de hardware y cooperen con otras apps que usan el flujo de salida de audio.

Reproductor de IU

Una aplicación multimedia que reproduce audio y video generalmente consta de dos partes:

  • Un reproductor que recibe contenido multimedia digital y lo representa como video o audio
  • Una IU con controles de transporte que ejecutan el reproductor y, opcionalmente, muestran su estado

ui-and-player

En Android, puedes compilar tu propio reproductor desde cero o elegir alguna de estas opciones:

  • La clase MediaPlayer proporciona la funcionalidad básica para un reproductor simple que admite los formatos de audio y video y las fuentes de datos más comunes.
  • ExoPlayer es una biblioteca de código abierto que expone las API de audio de Android de nivel inferior. ExoPlayer admite características de alto rendimiento, como la transmisión DASH y HLS, que no están disponibles en MediaPlayer. Puedes personalizar el código de ExoPlayer para facilitar la adición de componentes nuevos. ExoPlayer solo se puede usar a partir de Android 4.1.

Sesión multimedia y controlador multimedia

Si bien las API para la IU y el reproductor pueden ser arbitrarias, la naturaleza de la interacción entre las dos piezas es básicamente la misma para todas las apps de reproducción multimedia. El marco de trabajo de Android define dos clases, una sesión multimedia y un controlador multimedia, que imponen una estructura bien definida para compilar una app de reproducción multimedia.

La sesión y el controlador multimedia se comunican entre sí mediante devoluciones de llamadas predefinidas que se corresponden con acciones comunes del reproductor (reproducción, pausa, detención, etc.), y mediante llamadas personalizadas extensibles que puedes usar para definir comportamientos especiales exclusivos de tu app.

controller-and-session

Sesión multimedia

Una sesión multimedia es responsable de toda la comunicación con el reproductor. Oculta la API de este al resto de tu app. El reproductor solo se llama desde la sesión multimedia que controla.

La sesión mantiene una representación del estado del reproductor (reproduciendo/pausado) e información sobre lo que se está reproduciendo. Una sesión puede recibir callbacks de uno o más controladores multimedia. Esto permite que el reproductor sea controlado por la IU de tu app y de dispositivos complementarios con Wear OS y Android Auto.

Controlador de medios

Un controlador multimedia aísla tu IU. El código de tu IU solo se comunica con el controlador multimedia, no lo hace directamente con el reproductor. El controlador multimedia traduce acciones de control de transporte en callbacks a la sesión multimedia. También recibe callbacks de la sesión multimedia siempre que cambia el estado de la sesión. Esto proporciona un mecanismo que permite actualizar automáticamente la IU asociada. Un controlador multimedia solo puede conectarse a una sesión multimedia a la vez.

Cuando usas un controlador multimedia y una sesión multimedia, puedes implementar diferentes interfaces o reproductores en el tiempo de ejecución. Puedes cambiar la apariencia o el rendimiento de tu app de forma independiente, según las capacidades del dispositivo en el que se está ejecutando.

Comparación de apps de video y audio

Cuando reproduces un video, usas los ojos y los oídos. Al reproducir audio usas los oídos, pero también puedes trabajar con una app diferente al mismo tiempo. Hay un diseño diferente para cada caso de uso.

App de video

Una app de video requiere una ventana para poder visualizar contenido. Por ello, las apps de video normalmente se implementan como una actividad de Android individual. La pantalla en la que aparece el video es parte de la actividad.

actividad del reproducto de video

App de audio

Los reproductores de audio no siempre necesitan que su IU sea visible. Una vez que comienza a reproducir audio, el reproductor puede ejecutarse como tarea en segundo plano. El usuario puede pasar a otra app y trabajar mientras continúa escuchando.

Para implementar este diseño en Android, puedes compilar una app de audio usando dos componentes: una actividad para la IU y un servicio para el reproductor. Si el usuario realiza un cambio a otra app, el servicio puede ejecutarse en segundo plano. Si se incluyen las dos partes de una app de audio en componentes independientes, cada una puede ejecutarse de forma más eficiente por sí misma. Por lo general, la duración de una IU es corta en comparación con la de un reproductor, que puede ejecutarse durante mucho tiempo sin una IU.

Actividad de audio y BrowserService

La biblioteca de compatibilidad proporciona dos clases para implementar este enfoque de cliente y servidor: MediaBrowserService y MediaBrowser. El componente de servicio se implementa como una subclase de MediaBrowserService que contiene la sesión multimedia y su reproductor. La actividad con la IU y el controlador multimedia deben incluir un MediaBrowser que se comunique con el MediaBrowserService.

MediaBrowserService permite que dispositivos secundarios (como Android Auto y Wear) encuentren fácilmente tu app, se conecten, exploren contenido y controlen la reproducción, sin acceder en absoluto a la actividad de tu IU.

Apps multimedia e infraestructura de audio de Android

Una app multimedia bien diseñada debe “combinarse bien” con otras apps que reproducen audio. Debe estar preparada para compartir el teléfono y cooperar con otras apps de tu dispositivo que usen audio. También debe responder a controles de hardware en el dispositivo.

plays-with-others

Este comportamiento se describe por completo en cómo controlar salida de audio.

Biblioteca media-compat

La biblioteca media-compat contiene clases que son útiles para compilar apps que reproducen audio y video. Esas clases son compatibles con dispositivos con Android 2.3 (nivel de API 9) y versiones posteriores. También se complementan con otras características de Android para crear una experiencia cómoda y familiar en Android.

El método de implementación recomendado de sesiones y controladores multimedia contempla las clases MediaSessionCompat y MediaControllerCompat, que se definen en la biblioteca de compatibilidad media-compat. Estas reemplazan las versiones anteriores de las clases MediaSession y MediaController que se introdujeron en Android 5.0 (nivel de API 21). Las clases compat ofrecen la misma funcionalidad, pero facilitan el desarrollo de tu app, ya que solo necesitas escribirle a una API. La biblioteca se ocupa de la compatibilidad con versiones anteriores al traducir los métodos de sesión multimedia a los métodos equivalentes en versiones anteriores de la plataforma, cuando estén disponibles.

Si ya tienes una app funcional que usa clases anteriores, te recomendamos que la actualices con las compatibles. Cuando usas las versiones compat, puedes quitar todas las llamadas a registerMediaButtonReceiver() y los métodos de RemoteControlClient.

Cómo medir el rendimiento

En Android 8.0 (nivel de API 26) y versiones posteriores, está disponible el método getMetrics() para algunas clases de contenido multimedia. Muestra un objeto PersistableBundle que contiene información de configuración y rendimiento, expresada como un mapa de atributos y valores. El método getMetrics() se define para estas clases de contenido multimedia:

Las métricas se recopilan por separado para cada instancia y persisten mientras estas últimas existan. Si no hay métricas disponibles, el método muestra el valor null. Las métricas reales que se muestren dependen de la clase.