标签：
转载请把头部出处链接和尾部二维码一起转载，本文出自：http://blog.csdn.net/hejjunlin/article/details/52420803
前言：在上篇中，分析了MediaPlayer的从创建到setDataSource过程，尽管看了代码，但是没有从MediaPlayer生态上认识各类库之间依赖调用关系，在本篇中将作一个补充整体上的认识。看下今天的Agenda:
在各个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是一个多媒体的框架，从宏观上来看，它主要包含了两大方面的内容：
在这些头文件mediaplayer.h提供了对上层的接口，而其他的几个头文件都是提供一些接口类（即包含了纯虚函数的类），这些接口类必须被实现类继承才能够使用。
整个MediaPlayer在运行的时候，可以分成Client和Server两个部分，它们分别在两个进程中运行，它们之间使用Binder机制实现IPC通信。从框架结构上来看，IMediaPlayerService.h、IMediaPlayerClient.h和MediaPlayer.h三个类定义了MeidaPlayer的接口和架构，MediaPlayerService.cpp和mediaplayer.cpp两个文件用于MeidaPlayer架构的实现，MeidaPlayer的具体功能在PVPlayer（库libopencoreplayer.so）中的实现。
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方法来的。
如果是下面这种场景,一个网络url送过来，视频非常大：这时就要用到异步prepare
看下MediaPlayer中prepareAsync方法： 准备好播放器为接下来playback，这是个异步方法，当setDataSource且展现了surface，你应当开始调用prepare或prepareAsync方法了，对于流类型，你应该调用prepareAsync方法能立马返回，而不是在没有足够的流数据被缓冲时一直block
本文出自逆流的鱼yuiop：http://blog.csdn.net/hejjunlin/article/details/52420803
这是个native方法，我们看android_media_MediaPlayer_prepareAsync方法：
从代码上看，除了最后process_media_player_call中mp->prepareAsync()判断状态时，不一样，其他和prepare都是一样。它的操作结果经过回调通知给Java层。
看下media/mediaplayer.h中prepareAsync函数，c++代码：
上面代码总结为：首先判断mFlags，此时不是preparing。接着启动mQueue(类TimedEventQueue)。之后修改mFlags的状态为PREPARING，表示现在正在准备处理文件的音视频流。然后通过实例一个AwesomeEvent，然后放到之前启动的mQueue中进行通知出去。
queue中处理的结果就是调用AwesomePlayer::onPrepareAsyncEvent函数。后面的过程就是初始化解码器，将流解码出来，也能知道视频流的宽高等属性，然后通知prepared.不再向下跟踪。prepare的流程就完成了。
接下来，我们再回到java层中之前prepare方法中的scanInternalSubtitleTracks()方法
这个方法是扫描内嵌字幕并进行跟踪.
接下来分析看下MediaPlayer中start过程：
以上代码总结为：start方法用于start或者重新恢复播放，如果playback先前已暂停，playback将开始从paused状态变成在start状态，如果playback已经是stopped，或之前从来没有started过，playback将会开始start。
3中执行stayAwake()中是对屏幕进行操作：
最后通过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方法，
在对应的jni中找到android_media_MediaPlayer_pause方法
pause方法，可以看到和start的流程类似，也是通过 mp->pause()返回对应的状态，然后notify上层去pause
还有一个stop方法也是类似，这里不再分析。
第一时间获得博客更新提醒，以及更多android干货，源码分析，欢迎关注我的微信公众号，扫一扫下方二维码或者长按识别二维码，即可关注。
如果你觉得好，随手点赞，也是对笔者的肯定，也可以分享此公众号给你更多的人，原创不易
Android Multimedia框架总结（四）MediaPlayer中从Java层到C++层类关系及prepare及之后其他过程
标签：
原文地址：http://blog.csdn.net/hejjunlin/article/details/52420803
