Android Multimedia框架总结（四）MediaPlayer中从Java层到C++层类关系及prepare及之后其他过程

前言：
在上篇中，分析了MediaPlayer的从创建到setDataSource过程，
尽管看了代码，但是没有从MediaPlayer生态上认识各类库之间依赖调用关系，
在本篇中将作一个补充整体上的认识。

看下今天的Agenda:
（1）MediaPlayer各个so库之间关系结构图
（2）MediaPlayer各个具体类之间依赖关系图
（3）prepare的执行过程
（4）prepareAsync执行过程
（5）prepare和prepareAsync区别
（6）start执行过程
（7）pause执行过程

一、MediaPlayer各个so库之间关系结构图

在各个so中，libmedia.so位于核心的位置，它对上层的提供的jni主要是Java中MediaPlayer类，
类libmedia_jni.so通过调用MediaPlayer类提供对Java的接口，并且实现了Android.media.MediaPlayer类。

libmediaplayerservice.so是Media的服务器，它通过继承libmedia.so的类实现服务器的功能，而libmedia.so中的另外一部分内容则通过IPC和libmediaplayerservice.so进行通信。

libmediaplayerservice.so的真正功能通过调用OpenCore Player来完成解码。OpenCore是一个多媒体的框架，从宏观上来看，它主要包含了两大方面的内容：

1. PVPlayer
   提供媒体播放器的功能，完成各种音频(Audio)、视频(Video)流的回放(Playback)功能

2. PVAuthor
   提供媒体流记录的功能，完成各种音频(Audio)、视频(Video)流的以及静态图像捕获功能

3. PVPlayer和PVAuthor以SDK的形式提供给开发者
   可以在这个SDK之上构建多种应用程序和服务。在移动终端中常常使用的多媒体应用程序，例如媒体播放器、照相机、录像机、录音机等等。

4. OpenCore组织了codec等一些组建，统一接口
   MediaPlayer调用OpenCore的东西，不用太关心下层的codec是什么，这个库在6.0上已经不用，代替它的是Stagefright，比OpenCore简洁很多。

MediaPlayer部分的头文件在frameworks/base/include/media/目录中，
这个目录是和libmedia.so库源文件的目录frameworks/base/media/libmedia/相对应的。
主要的头文件有以下几个：
IMediaPlayerClient.h
mediaplayer.h
IMediaPlayer.h
IMediaPlayerService.h
MediaPlayerInterface.h

在这些头文件mediaplayer.h提供了对上层的接口，而其他的几个头文件都是提供一些接口类（即包含了纯虚函数的类），这些接口类必须被实现类继承才能够使用。

二、MediaPlayer各个具体类之间依赖关系图

整个MediaPlayer在运行的时候，可以分成Client和Server两个部分，它们分别在两个进程中运行，它们之间使用Binder机制实现IPC通信。

框架结构上来看，
IMediaPlayerService.h、IMediaPlayerClient.h和MediaPlayer.h三个类定义了MeidaPlayer的接口和架构，MediaPlayerService.cpp和mediaplayer.cpp两个文件用于MeidaPlayer架构的实现，
MeidaPlayer的具体功能在PVPlayer（ 库libopencoreplayer.so ）中的实现。

三、prepare的执行过程

prepare播放器为playback，这是个同步方法，
当setDataSource且展现了surface，你应当开始调用prepare或prepareAsync方法，
对于文件类型，调用prepare方法将暂时block，直到MediaPlayer已经为playback准备好。
接着调用native层android_media_MediaPlayer_prepare方法：

上述1，2，3 我们在上一篇中，曾经介绍过，
1中getVideoSurfaceTexture是获取一个IGraphicBufferProducer类型指针，
2中是setVideoSurfaceTexture,这个xxx中最后的部分介绍过，这里不再细说。
3中是个判定并且notify的方法，这里是送进mp->prepare的方法调用的状态送入，如果不ok，就notify相关error或者抛出异常。

我们知道还有一个prepareAsync方法，我们前面的思路都是顺着MediaPlayer中create方法来的。

四、prepareAsync的执行过程

如果是下面这种场景,一个网络url送过来，视频非常大：这时就要用到异步prepare

看下MediaPlayer中prepareAsync方法：
准备好播放器为接下来playback，这是个异步方法，
当setDataSource且展现了surface，你应当开始调用prepare或prepareAsync方法了，
对于流类型，你应该调用prepareAsync方法能立马返回，而不是在没有足够的流数据被缓冲时一直block

这是个native方法，我们看android_media_MediaPlayer_prepareAsync方法：

从代码上看，除了最后process_media_player_call中mp->prepareAsync()判断状态时，不一样，
其他和prepare都是一样。它的操作结果经过回调通知给Java层。
看下media/mediaplayer.h中prepareAsync函数，c++代码：

接着看 MediaPlayerService::Client::prepareAsync()

接着看 AwesomePlayer::prepareAsync_l()

五、prepare和prepareAsync区别

上面代码总结为：
首先判断mFlags，此时不是preparing。
接着启动mQueue(类TimedEventQueue)。
之后修改mFlags的状态为PREPARING，表示现在正在准备处理文件的音视频流。
然后通过实例一个AwesomeEvent，然后放到之前启动的mQueue中进行通知出去。
queue中处理的结果就是调用AwesomePlayer::onPrepareAsyncEvent函数。
后面的过程就是初始化解码器，将流解码出来，也能知道视频流的宽高等属性，
然后通知prepared.不再向下跟踪。
prepare的流程就完成了。

接下来，我们再回到java层中之前prepare方法中的scanInternalSubtitleTracks()方法

这个方法是扫描内嵌字幕并进行跟踪.

六、start执行过程

接下来分析看下MediaPlayer中start过程：

以上代码总结为：
start方法用于start或者重新恢复播放，如果playback先前已暂停，playback将开始从paused状态变成在start状态，
如果playback已经是stopped，或之前从来没有started过，playback将会开始start。

3中执行stayAwake()中是对屏幕进行操作：

（1）首先PowerManager pm = (PowerManager)getSystemService(Context.POWER_SERVICE);
（2）通过 Context.getSystemService().方法获取PowerManager实例。
（3）然后通过PowerManager的newWakeLock((int flags, String tag)来生成WakeLock实例。int flags指示要获取哪种WakeLock，不同的Lock对CPU、屏幕、键盘灯有不同影响。获取WakeLock实例后通过acquire()获取相应的锁，然后进行其他业务逻辑的操作，最后使用release()释放（释放是必须的）。
（4）关于int flags,各种锁的类型对CPU 、屏幕、键盘的影响：
PARTIAL_WAKE_LOCK:保持CPU 运转，屏幕和键盘灯有可能是关闭的。
SCREEN_DIM_WAKE_LOCK：保持CPU运转，允许保持屏幕显示但有可能是灰的，允许关闭键盘灯
SCREEN_BRIGHT_WAKE_LOCK：保持CPU运转，允许保持屏幕高亮显示，允许关闭键盘灯
FULL_WAKE_LOCK：保持CPU运转，保持屏幕高亮显示，键盘灯也保持亮度
ACQUIRE_CAUSES_WAKEUP：正常唤醒锁实际上并不打开照明。相反，一旦打开他们会一直仍然保持。当获得wakelock，这个标志会使屏幕或/和键盘立即打开。一个典型的使用就是可以立即看到那些对用户重要的通知。

最后通过updateSurfaceScreenOn()进行，更新屏幕上的Surface.
我们还是回到最上面start方法中。最后会调用_start方法到native jni中。

从中间的mp-start开始，就调到底层c++,在native中引入media/mediaplayer.h，我们进入这个头文件看看：

从接口中可以看出MediaPlayer类实现了一个MediaPlayer的基本playback操作，播放（start）、停止（stop）、暂停（pause）, 重置（reset）等。
另外的一个类DeathNotifier在MediaPlayer类中定义，它继承了IBinder类中的DeathRecipient类，这些作用都是为了进程间通信准备：

以下过程就是和mediaplayerservice通过IPC进行通信，不再向下分析。
可以发现start后，底层来返回一个状态，是ok还是不ok的。这就回到process_media_player_call中判定这个返回的状态，然后notify java层中的回调函数。

七、pause的执行过程

接下来，再看下pause方法，

在对应的jni中找到android_media_MediaPlayer_pause方法

pause方法，可以看到和start的流程类似，也是通过 mp->pause()返回对应的状态，然后notify上层去pause

还有一个stop方法也是类似，这里不再分析。

本文转自： https://blog.csdn.net/hejjunlin/article/details/52420803