安卓MediaPlayer源码跟读解析

简介：

        安卓通过MediaPlayer这个类提供了一整套接口呈现给给客户实现视音频的播放。可是凡事必究其根，我们今天就来看看安卓的MediaPlayer框架(基于Android 8.0)究竟是怎么实现的。因为框架层全是C/C++代码，建议读者拥有相关基础，没有也没关系，都能看懂。

概要： 

        先给出网上扒的MediaPlayer状态图，MediaPlayer常用的方法也就这些了。

        因为音视频相关的编解码，解封装，渲染等操作需要大量的运算，所以谷歌将这些方法通过底层C/C++代码来实现了。但是java怎么调用的C++代码呢？于是JNI(java native interface)就应运而生了。JNI允许Java代码和其他语言写的代码进行交互。JNI一开始是为了本地已编译语言，尤其是C和C++而设计的，但是它并不妨碍你使用其他编程语言，只要调用约定受支持就可以了。使用java与本地已编译的代码交互，通常会丧失平台可移植性。

        因此我们可以给出MediaPlayer框架的层次架构图：

        我们写java程序如果要用到视音频播放肯定少不了MediaPlayer，常见的调用方法大致如下：

         是不是很熟悉？先通过creat()函数创建一个mediaPlayer，再设置音频流类型，设计播放窗口，就start()，一般都是固定的几步，可是它的底层是怎么运作的呢？我们现在来分析一下。就看creat()函数吧，跟着它往下读。

         当然先去MediaPlayer.java里找一找了。

         目录：xref: /frameworks/base/media/java/android/media/MediaPlayer.java

          我把这几个相关的函数穿了起来，层层调用。java对上层那么多的重载函数，在底层都是互相调用，最终归为一两个特别的函数上。还记得初学java的MediaPlayer时，网上说可以new一个MediaPlayer也可以不new，直接调用creat()函数，我觉得不可思议，现在算是真相大白了。creat()函数在内部先new了一个MediaPlayer来处理业务，然后调用MediaPlayer的setDataSource()函数来设置播放资源，setDataSource()函数是我们研究框架的开路先锋，他是最重要的一个函数了。注意最后一个函数的native标志，它标示了这是一个底层函数的声明，你在当前目录是找不到它的定义的，这就是JNI。

         但是看native层的代码之前，我们注意到在MediaPlayer.java的构造函数之前有一段静态代码段：

        嗯？提前调用了native层的native_init方法。没完呢，我们注意到在MediaPlayer.java的构造函数里也有一段native代码：

        这两个native函数在new一个MediaPlayer时就会调用，别放过，很重要，我们马上就看看。

        JNI的全称就是Java Native Interface，就是Java和C/C++相互通信的接口，实现了一个工程，多种语言并存。那么什么时候需要用到JNI呢？

        1.需要调用java语言不支持的依赖于操作系统平台的特性的一些功能；

        2.为了整合一些以前使用非java语言开发的某些系统，例如C和C++；

        3.为了节省程序的运行时间，必须采用一些低级或中级语言。

       关于JNI的用法请看：JNI的用法

       MediaPlayer.java调用了底层JNI，根据JNI特有的命名规则，我们要找android_media_MediaPlayer.cpp文件。好了我们上面看到java层调用了native层的函数，有native_init(),native_setup(),_setDataSource()，然后我们兴高采烈的在android_media_MediaPlayer.cpp文件中并没有找到这三个函数的定义，什么情况？

        不慌，细心的人就会发现JNI有这么一块代码，实现了对函数换名！

        原来我们上层的函数在这里进行了统一的名称替换(如果对JNI的语法规则不明白的自行百度，这里不需要深究)。这就真相大白了，android_media_MediaPlayer_native_init()函数只是设置JNI层相关参数，感兴趣请自行查看，我们看看android_media_MediaPlayer_native_setup()函数：

        先创建了一个MediaPlayer，不过这个MediaPlayer是C++版的，用来与MediaPlayerService进行通信。然后调用setMediaPlayer将这个mp与上层java关联了起来(记住这个地方，后面会用到)。

        好的，那我们继续寻找android_media_MediaPlayer_setDataSourceFD()函数，下面给出代码：

        这里有必要说一下，JNIEnv是用来向上层回调，jobject是java的类，后面三个不说了。sp是什么玩意儿？不慌，strong pointer，强指针，此外还有wp,weak pointer,弱指针。这两个都是C++的模板类，实现了对指针的封装，我们直接将它们看成指针即可，ASOP中有太多这样的用法了。wp可以实现对原指针的更改，wp不可以。

        好了我们看函数，显式调用getMediaPlayer()函数，得到上面new出来的C++版的mediaPlayer，最后调用了C++版的MediaPlayer的setDataSource()函数，然后是process_media_player_call()是将处理结果返回给上层java。至此，我们正式进入MediaPlayer框架层，下面给出类图：

        MediaPlayer框架采用C/S架构，分别处在两个进程上，采用Bindler机制进行进程间通信。我们发现native层的大部分类都是采用IXXX，BpXXX，BnXXX形式的。在MediaPlayer框架层，由IMediaPlayer，IMediaPlayerService，IMediaPlayerClient三大元老组成了基本框架，由IBinder，BBinder(准确来说叫BnBinder比较合适)，BpBinder将其粘合。此外，IXXX类里总是一些虚抽象函数，不存在定义，由BpXXX和BnXXX继承它，BpXXX作为Client端的代理类，发起服务的请求，服务的实现则统一放在BnXXX类里。

         接着上面，我们来看MediaPlayer的setDataSource()函数，代码贴上：

        getMediaPlayerService()函数：一眼望去，就是请求Service无疑了。MediaPlayer.cpp中并没有这个函数的实现方法，所以我们去他的父类IMediaDeathNotify寻找，嘿，果然在这儿！

        这段代码就是Client端的请求服务了，通过调用defaultServiceManager()得到IServiceManager，通过调用IServiceManager的getService()函数来查询“media.player”是否注册，如果注册则返回对应的IBinder，留给Client进行通信。然后就是通过interface_cast将IBinder转化为服务端IMediaPlayerService的指针返回。可是这个inteface_cast()是什么呢？是一个强制类型转换吗？不不不，一叶障目罢了，我们来看看它的定义：

        好家伙，直接返回自身的，即IMediaPlayerService::asInteface(),我们继续追,额，我就不贴代码了，你会发现IMediaPlayerService中并没有这个函数的定义，怎么回事儿？去父类看看！一对比就能发现蹊跷了：

        IInterface中有这么一段奇怪的代码段，不妨，仔细看一下，哦，原来是一对宏声明和定义！而IMediaPlayerService里刚好有这两个宏的调用！那么就见泰山了。我们将IMediaPlayerService置换进去，就能看到IBinder转IMediaPlayerService的实现了！我就不再贴出了。

        好了扯远了，我们通过getDefaultService得到了一个注册名为“mediapalyer"的服务，并通过interface_cast转换为一个IMediaPlayerService的指针返回。我们继续往下看：

        sp player(service->create(this, mAudioSessionId));

        原来是调用IMediaPlayer的creat()函数，我们去看看：

        asBinder()是直接将client转化为binder接口，而没有经过ServiceManager这个中介，说明这是个匿名管道，只能在这两个进程间进行通信。来看一下：

        remote()得到的就是远端的BpBinder。remote() ->transact(),这个函数要好好说道一下

   1.BpBinder,BBinder,IBinder是安桌Binder机制的抽象，其中BpBinder不在这些继承关系中。

   2.remote()是在BpRefBase的子类中实现的，返回的就是一个BpBinder。

   3.BpBinder的transact实现，就是直接调用IPCThreadState::self()->transact()发送数据。

   4.Service端通过IPCThreadState接收到client的请求后，首先会调用BBinder的transact()方法。

   5.BBinder的transact方法又会调用子类实现的虚拟方法onTransact。这个虚拟方法是在BnXXXService中实现的

        所以，我们直接在BnMediaPlayerService中寻找onTransact()的CREAT实现:

         首先又将BpBinder转回了sp,然后调用了creat()方法，可是我们发现BnMediaPlayerService中只有一个onTransact()的实现，所以这个creat()我们要去它的子类寻找，果然就在MediaPlayerService中： 

         代码简单易懂，创建了它一个自身类Client并返回指针供远端调用，这个Client包含了上层java的大部分接口。好了，回到我们的开始地方：

         这部分都是牵扯了Bindler机制，扯得有点远了。不过好坏算是回来了。

         哦，后面就简单了许多，直接调用了Client的setDataSource()函数，我们去看看：

         首先调用MediaPlayerFactory::getPlayerType()函数获得了播放器的类型，我们看看实现：

        这个叫打分机制，sFactoryMap存储了各个播放器的工厂类，通过scoreFactory()来获取对应播放类型的权值最大的工厂类，并将其返回。一般情况下播放网流或者本地资源都是调用的NuPlayerFactory,可以看一下它的打分机制：

         根据各个播放类型设置权值，并对应着返回。就不一一解释了，因为有些类型我也看不懂^_^。获得了播放器类型后就要创建播放器了，这一步是调用：

    sp p = setDataSource_pre(playerType)

          来实现的，我们看看setDataSource_pre()的定义：

          额，代码有点多，我们只抓重点，返回的p是什么？sp p = createPlayer(playerType)，原来如此，我们直接跳过去吧：

         mPlayer是上次播放调用的"播放器"，重点在p = MediaPlayerFactory::createPlayer(playerType, this, notify, mPid)，又调用了MediaPlayerFactory的函数，通过播放器类型创建了一个播放器吗？我们去看看：

        代码很简单，从工厂map中找出对应的播放器工厂，然后通过工厂创建一个“播放器”。我们来看一下工厂类型： 

         可见一共注册了五种播放器，但是我们最多用的还是NuPlayer。我们继续看代码，调用NuPlayer的creatplayer()函数：

         好敷衍，直接新建了一个NuPlayerDriver类，我们的NuPlayer播放器呢？不慌，我们看看NuPlayer的构造函数：

           原来是在构造函数里新建了一个播放器。这样就明白了，所以现在回到setDataSource_pre()中，它反悔了一个NuPlayerDriver,我们继续看Client的setDataSource函数：

        调用了NuPlayerDriver的setDataSource()函数啊，看来要进入安卓内置播放器了：

        之前我们看到，mPlayer就是NuPlayer类型，NuPlauerDriver调用了NuPlayer的setdataSourceAsync()函数。这样就进入了内置播放器，其他函数的调用都大致如此，但是没有setDataSource这么复杂，抓住一条线，就能顺理成章的搞懂框架的调用关系。