Media App Architecture overview

Media app architecture overview

这部分解释了如何将一个Media app拆分成一个Media controller（媒体控制器，给UI使用）和一个media session（每天会话，给实际的player使用).
有两种Media app的架构设计：

1. 基于client/server 设计： 这种设计一般用于在audio app
2. 单一activity设计：一般用户vedio players。
   同时本模块也展示了如何使媒体应用程序响应硬件控制，并与使用音频输出流的其他应用程序协作的。

播放器（player）和界面（UI）

播放音频或视频的多媒体应用程序通常有两部分：

1. 接收数字媒体并将其呈现为视频和/或音频的播放器
2. 带有传输控件(transport controls)的UI，用于运行播放机并可选地显示播放机的状态
   
   在Android中，您可以从头开始构建自己的播放器，也可以从以下选项中进行选择：
3. MediaPlayer
   MediaPlayer类为支持最常见音频/视频格式和数据源的裸体播放器提供基本功能
4. ExoPlayer
   ExoPlayer是一个开源库，构建在MediaCodec和AudioTrack等较低级别的媒体框架组件之上。ExoPlayer支持MediaPlayer中没有的高性能功能，如DASH。您可以自定义ExoPlayer代码，以便添加新组件。ExoPlayer只能与Android版本4.1及更高版本一起使用。

媒体会话(Media session)和媒体控制器(Media controller)

虽然UI和播放器的API可以是任意的，但对于所有媒体播放器应用程序，这两部分之间的交互本质基本相同。Android框架定义了两个类，一个媒体会话和一个媒体控制器，它们为构建媒体播放器应用程序提供了定义良好的结构。

媒体会话和媒体控制器使用预定义回调(predefined callbacks)进行相互通信。这些回调不光处理play, pause, stop等标准的player action，同时也处理自定义App特有的一些可扩展调用。

Media Session

MediaSession 负责所有与播放器的通信，它对app其余部分隐藏了播放器的API， 仅从控制播放机的媒体会话调用播放机.

该会话维护播放器状态（播放/暂停）以及有关播放内容的信息。会话可以接收来自一个或多个媒体控制器的回调。这使得您的播放器不光可以由应用程序的UI控制，也可以由对应Wear OS和Android Auto的配套设备控制。响应回调的逻辑必须一致。对MediaSession回调的响应应该是相同的，无论哪个客户端应用启动了回调。

Media Controller

媒体控制器隔离了UI和播放器。用户界面代码仅与媒体控制器通信，而不是与播放机本身通信。媒体控制器将传输控制操作转换为对媒体会话的回调。
每当会话状态更改时，它也会从媒体会话接收回调。这就提供了一种自动更新关联UI的机制。在同一时间，一个媒体控制器只能连接到一个媒体会话。

使用媒体控制器和媒体会话时，可以在运行时部署不同的接口和/或播放机。根据应用程序运行时的设备功能，您可以独立更改应用程序的外观和/或性能。

Video app VS audio apps

播放视频时，需要您的眼睛和耳朵同时投入，而播放音频时，您只需收听，可以同时使用其他应用程序。根据这个不同，设计用户用列则不同。

Video appVideo

应用程序由于需要一个展示给用户的UI，所以一般将Video app设计成一个单独的Activity。Video展示的屏幕只是该activity的一部分。

Audio app

音频播放器并不需要其UI一直处于前台，一旦其开始播放音频，播放器可以作为后台任务在后台运行，用户可以切换到其他应用，同时继续收听音频。

Android为了实现这一设计，用户可以使用两部分来创建一个音频应用：用于UI展示的Activity，和用于播放的服务，如果用户切换到其他应用，该服务可以继续在后台运行。
通过将音频应用程序的两个部分分解为单独的组件，每个组件都可以自己更高效地运行。和播放器相比，用户界面通常是短暂的，而播放器则可以在没有用户界面的情况下运行很长时间。

支持库提供了两个类来实现这种客户机/服务器方法：MediaBrowserService和MediaBrowser。
服务组件实现为MediaBrowserService的一个子类，包含媒体会话及其播放器。带有UI和媒体控制器的Activity应包括一个MediaBrowser，这个MediaBrowser的作用是用于和MediaBrowserService通信。

使用MediaBrowserService可以让配套设备（如Android Auto和Wear OS）轻松发现应用程序、连接应用程序、浏览内容和控制播放，而无需访问应用程序的UI Activity。事实上，可以有多个应用同时连接到同一个MediaBrowserService，每个应用都有自己的MediaController。提供MediaBrowserService的应用程序应该能够同时处理多个连接。

Media apps and the Android audio infrastructure

一款设计较好的媒体应用应该和其他播放音频的应用“合作愉快”，具备共享phone的能力，可以和设备上其他应用共享共用audio，同时也能相应设备上的硬件控制。

所有这些行为都在 Controlling Audio Output有说明.

Media-compat library

media-compat库包含有助于构建播放音频和视频的应用程序的类。这些类兼容运行Android 2.3（API级别9）及更高版本的设备。他们还与其他安卓功能合作，创造舒适、熟悉的安卓体验。

media-compat支持库中定义了MediaSession和MediaController的推荐实现类：MediaSessionCompat/MediaControllerCompat，他俩替代了早期Android5.1版本中引入的MediaSession/MediaController这两类。compat类提供了相同的功能，但更易于开发应用程序，因为您只需编写一个API。该库通过将Media session方法转换为旧平台版本（如果可用）上的等效方法来实现向后兼容性。

如果您已经有一个正在使用旧类的工作应用程序，我们建议您更新到compat类。使用compat版本时，可以从RemoteControlClient中删除对RegisterDiaButtonReceiver（）的所有调用和任何方法。

Measuring performance

在Android 8.0（API级别26）及更高版本中，getMetrics（）方法可用于某些媒体类。它返回一个PersistableBundle对象，其中包含配置和性能信息，表示为属性和值的映射。getMetrics（）方法是为以下媒体类定义的：
MediaPlayer.getMetrics（）
MediaRecorder.getMetrics（）
MediaCodec.getMetrics（）
MediaExtractor.getMetrics（）

为每个实例分别收集Metrics，并在实例的生命周期内保持Metrics。如果没有可用的Metrics，该方法将返回null。返回的实际度Metrics取决于类。