阅读 140

MediaSession在57中的开场白

用技术提升美好事物发生的概率
Technologically, for greater probability to be happy.

从Chrome57开始,MediaSession就可以在Chrome中被使用了。MediaSession让我们可以对通知栏进行自定义操作,方便了用户直接在通知栏对媒体的控制。在有了MediaSession后,即使在锁屏界面,我们也可以看到媒体的信息,以及控制播放状态。对于提供了播放列表的网页,我们还可以直接切换至另一个媒体。

官方提供的样图

调起MediaSession的经过

在Chromium运行时,有一个Browser进程,若干个Render进程和一个GPU进程。后面会涉及到Browser进程以及Render进程。通常情况下,一个Tab或者多个Tab对应一个Render进程。

MediaSession的代码在browser端,且在c++端和java端都有相对应的部分。接下来先分析一下调起MediaSession的代码实现。

看播放视频的时候是如何调起MediaSession的(多种情况,此处只举出一种)。情景为点击播放媒体按键,开始创建播放器与MediaSession。下面是主要的流程。

下面的是相对应的代码。

最初,会创建一个HTMLMediaElement的DOM节点。该代码在HTMLMediaElement.cpp中。在这里会调用play(),若调用成功媒体能正常播放,则promise为完成态,否则为拒绝态。接下来进入到刚刚被调用的play()方法中。
若视频能播放,则调用PlayInternal(),否则就返回错误信息。代码也在HTMLMediaElement.cpp中。

PlayInternal()中设置好当前是否暂停的状态与能否自动播放后继续调用UpdatePlayState()。UpdatePlayState()中在开始播放前设置好播放速率和声音,然后调用GetWebMediaPlayer的Play()开始播放。代码都在HTMLMediaElement.cpp里面。

同样,这里也是调用UpdatePlayState()来更新播放状态。此处与前面提到的play()与UpdatePlayState()有什么关系呢?前面的我们理解为在Webkit层的播放器,而后者理解为Content层的播放器。此处代码在http://webmediaplayer_impl.cc中。
UpdateSate()里调用SetDelegateState()来处理媒体状态,然后在SetDelegateState()中处理了三种状态,即关闭、播放与暂停。播放的话,则调用DidPlay()。代码在http://webmediaplayer_impl.cc。
DidPlay()中主要向Browser端发送了IPC消息,于是播放媒体的消息就传给了Browser端了。代码在http://renderer_webmediaplayer_delegate.cc里面。下面的代码就直接到Browser部分了。

这里Browser端收到IPC消息后执行OnMediaPlaying(),此处看到203行,已经调用了MediaSessionControllersManager的RequestPlay(),后面部分开始已经到MediaSession的主体了。代码在http://media_web_contents_observer.cc。

MediaSessionControllersManager控制所有的MediaSessionController。在RequestPlay()的时候会创建一个MediaSessionController,在构造控制器的时候还会设置好对应的MediaSession,一个MediaSessionController控制一个MediaSession。通过controller初始化MediaSession里的播放器。代码在http://media_session_controllers_manager.cc里面。

C++端整体逻辑

MediaSessionControllersManager:由MediaWebContentsObserver调用,通过MediaSessionController来控制MediaSession。上面就是一个map,通过MediaPlayerId来对应不同的Controller,这里也可以看出一个播放器对应了一个Controller。

MediaSessionController:当我们在通知中对媒体进行操作时,Java端会发送消息过来,在Controller中收到后向Renderer发送IPC消息,控制Renderer里面的WebMediaPlayer。在构造MediaSessionController的时候还会给他对应的MediaSessionImpl赋值,此处可以看出每个MediaSessionController控制一个MediaSessionImpl。
MediaSessionImpl:整个MediaSession的中心,处理所有媒体与通知有关的事项。主要是播放状态与焦点状态的控制。其中的NotifyAboutStateChange()提供了能否控制与是否暂停两个状态,这两个值对控制播放的非常重要。能否控制表示我们是否能通过通知栏控制这个播放器,如果不能控制,则通知栏中不会出现。
MediaSessionServiceImpl:提供一些服务,主要是设置播放状态与播放支持的动作,且这两项决定了通知栏所展现的界面。代码中setMetadata()也就是设置元数据,里面包含图片,aritst,title等数据。Action部分也就是与支持的动作有关,如播放、暂停、前进、后退这些。

MediaMetadataSanitizer:功能性的类,MediaMetadataSanitizer检查与处理元数据格式的合理性,调用了Sanitize()。

AudioFocusDelegateAndroid:RequestAudioFocus()和AbandonAudioFocus()分别为通过JNI获取与丢失焦点。当系统要求MediaSession进行暂停、继续等操作的时候,从Java端发送消息给MediaSession,如电话(系统级别),上面给出OnSuspend()的例子。AudioFocus相关简介下面提到一些。

MediaSessionAndroid:MediaSession通过JNI主要向Java端发送的是三个状态变化,即MediaSessionStateChanged、MediaSessionMetadataChanged和MediaSessionActionsChanged。用户在通知栏进行操作时消息会从Java端传过来(UI级别),如上面例子给出的Suspend()。

Audio Focus

  1. Audio Focus 是用来处理多处音频同时出现的情况。
  2. 音频焦点类型有persistent和transient,长音频为persistent,会停止所有其他音频;短音频(如短信音效)为transient,只会降低其他音频的声音。
  3. 音频都需与MediaSession交互,且MediaSession状态(ACTIVE, SUSPENDED, INACTIVE)代表当前是否获取到焦点与是否有音频。
  4. AudioFocusManager提供焦点支持。音频需要播放时通知MediaSession,MediaSession向AudioFocusManager请求获取焦点,成功获取焦点则播放,同时通知其他MediaSession焦点变化。
  5. 音频停止播放则从MediaSession移除,同时丢弃焦点,AudioFocusManager通知其他MediaSession焦点变化。
  6. 焦点的控制是通过一个栈来实现。(实际为一个list容器,除了出入栈还用到了remove)

Java端整体逻辑

AudioFocusDelegate.java:主要有requestAudioFocus()和abandonAudioFocus(),分别用来获取与丢弃焦点。这一部分通过SDK里面的AudioManager,最终调用了API来获取与丢弃系统的音频焦点。
MediaSessionImpl.java:主要有mediaSessionStateChanged()、mediaSessionMetadataChanged()、mediaSessionActionsChanged(),都是native端传给Java端的消息,分别表示媒体会话的状态、元数据、动作的改变。此处动作表示网页支持的操作集合。

MediaSessionTabHelper.java :一方面处理native端传过来的信息,令一方面对各种操作都基本调用MediaNotificationManager来处理,相当于传递了控制信息。

到这里整个MediaSession的整个流程就走完了。MediaSession从播放器创建的时候创建出来, 并沟通了浏览器与通知栏,同时对媒体焦点的支持,让其成为一个非常好的特性。

关注下面的标签,发现更多相似文章
评论