2. Android MultiMedia框架完全解析 - MediaPlayer的C/S架构与Binder机制实现

最新推荐文章于 2024-06-07 11:15:02 发布

yanbixing123

最新推荐文章于 2024-06-07 11:15:02 发布

阅读量4.3k

点赞数 15

分类专栏： Android MultiMedia框架完全解析文章标签： Android MultiMedia

本文链接：https://blog.csdn.net/yanbixing123/article/details/88926819

版权

Android MultiMedia框架完全解析专栏收录该内容

21 篇文章 182 订阅

订阅专栏

在Android中大量使用到了C/S架构来实现应用层和底层服务交互，而Binder机制无处不在。

同样MediaPlayer也使用了这种机制，MediaPlayer在运行的时候，同样可以分为Client/Server两个部分，他们分别在不同的进程中运行，不同进程间的通信使用Binder机制，我们这里就以setDataSource()为例，讲解一下他们是如何建立关系的，架构图如下：

1）如果从功能角度看，最上层是java层MediaPlayer的API，然后通过JNI层到C++层之间的IPC通信，最下边就是palyer的具体实现了（StageFrightPlayer，NuPlayer等等）

2）C++层是比较重要的环节，这一块也是C/S架构的核心，主要围绕C++层MediaPlayer通过BpMediaPlayerService这个proxy对象，经过IPC与远程服务端MediaPlayerService（BnMediaPlayerService）通信，完成C/S架构。（Bpxxx是一个代理外包，所有真正的工作是再Bnxxx里面做的，这里p指proxy，n指native）

3）当Server端接受到Client端的请求，MediaPlayerService会为每一个Client进程创建一个会话，这里就是new一个MediaPlayer::Client对象与其交互，然后这个对象再根据Client端请求的资源类型去判断创建了什么类型的Player，就是最下面那些。（最下面这些Player很多都是芯片厂商自己做的，每家做的都不一样）

继续分析setDataSource函数（setDataSource - 2）

在上一节中，我们分析了从java层到JNI层的一些步骤，这里，我们继续分析。

static void
android_media_MediaPlayer_setDataSourceFD(JNIEnv *env, jobject thiz, jobject fileDescriptor, jlong offset, jlong length)
{
    sp<MediaPlayer> mp = getMediaPlayer(env, thiz);
    if (mp == NULL ) {
        jniThrowException(env, "java/lang/IllegalStateException", NULL);
        return;
    }

    if (fileDescriptor == NULL) {
        jniThrowException(env, "java/lang/IllegalArgumentException", NULL);
        return;
    }
    int fd = jniGetFDFromFileDescriptor(env, fileDescriptor);
    ALOGV("setDataSourceFD: fd %d", fd);
    process_media_player_call( env, thiz, mp->setDataSource(fd, offset, length), "java/io/IOException", "setDataSourceFD failed." );
}

上一节中我们分析到了这里，它位于frameworks/base/media/jni/android_media_MediaPlayer.cpp文件中，下面就跳转到frameworks/av/media/libmedia/mediaplayer.cpp中：

status_t MediaPlayer::setDataSource(int fd, int64_t offset, int64_t length)
{
    ALOGV("setDataSource(%d, %" PRId64 ", %" PRId64 ")", fd, offset, length);
    status_t err = UNKNOWN_ERROR;
    const sp<IMediaPlayerService> service(getMediaPlayerService());
//获取BpMediaPlayerService这个MediaPlayerService的proxy代理
    if (service != 0) {
        sp<IMediaPlayer> player(service->create(this, mAudioSessionId));
        if ((NO_ERROR != doSetRetransmitEndpoint(player)) ||
            (NO_ERROR != player->setDataSource(fd, offset, length))) {
            player.clear();
        }
        err = attachNewPlayer(player);
    }
    return err;
}

在这个过程中，mediaplayer.cpp中的setDataSource会从ServiceManager中获取MediaPlayerService服务，然后通过服务来创建Player，这个Player就是真正干活的Player。

下面仔细分析一些这个步骤：

1）通过Binder获取远程服务

通过getMediaPlayerService得到的service就是BpMediaPlayerService，这是和MediaPlayerService进程中对应的BnMediaPlayerService负责Binder通信，BpMediaPlayerService中的create只是通过binder机制将CREATE命令发送出去，真正的工作是在Bn端做的，这个发送命令的代码位于frameworks/av/media/libmedia/IMediaPlayerService.cpp中：

    virtual sp<IMediaPlayer> create(
            const sp<IMediaPlayerClient>& client, audio_session_t audioSessionId) {
        Parcel data, reply;
        data.writeInterfaceToken(IMediaPlayerService::getInterfaceDescriptor());
        data.writeStrongBinder(IInterface::asBinder(client));
        data.writeInt32(audioSessionId);

        remote()->transact(CREATE, data, &reply);
        return interface_cast<IMediaPlayer>(reply.readStrongBinder());
    }

在这个函数中，Parcel是Binder进行通信的数据载体，Bp端向Bn端发送的数据结构是data，Bn端向Bp端回复的数据是reply。然后通过remote()->transact()发送CREATE命令到Bn端。

在服务端的Bn端，BnMediaPlayerService通过onTransact()接受这个命令，并把结果通过replay返回。代码同样位于frameworks/av/media/libmedia/IMediaPlayerService.cpp中：

status_t BnMediaPlayerService::onTransact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
    switch (code) {
        case CREATE: {
            CHECK_INTERFACE(IMediaPlayerService, data, reply);
            sp<IMediaPlayerClient> client =
                interface_cast<IMediaPlayerClient>(data.readStrongBinder());
            audio_session_t audioSessionId = (audio_session_t) data.readInt32();
            sp<IMediaPlayer> player = create(client, audioSessionId);
//BnMediaPlayerService的子类是MediaPlayerService，所以这里会调用MediaPlayerService的create方法
            reply->writeStrongBinder(IInterface::asBinder(player));
            return NO_ERROR;
        } break;
case CREATE_MEDIA_RECORDER: 
......
}
}

BnMediaPlayerService的子类是MediaPlayerService，即MediaPlayerService继承自BnMediaPlayerService。这里首先生成了一个IMediaPlayerClient，这个类用于MediaPlayerService与MediaPlayer通信。然后调用MediaPlayerService类的create函数，这里就把客户端的指令最终传送到服务端了，等服务端完成这个指令后，通过Binder通信，填写reply这个Parcel，把最终的结果回馈给客户端，这个流程就算执行完毕了。

这里创建了2个匿名Binder Server：IMediaPlayerClient和IMediaPlayer。

2）服务端创建会话

最终调用了MediaPlayerService的create方法，文件位于frameworks/av/media/libmediaplayerservice/MediaPlayerService.cpp中：

sp<IMediaPlayer> MediaPlayerService::create(const sp<IMediaPlayerClient>& client,
        audio_session_t audioSessionId)
{
    pid_t pid = IPCThreadState::self()->getCallingPid();
    int32_t connId = android_atomic_inc(&mNextConnId);

    sp<Client> c = new Client(
            this, pid, connId, client, audioSessionId,
            IPCThreadState::self()->getCallingUid());

    ALOGV("Create new client(%d) from pid %d, uid %d, ", connId, pid,
         IPCThreadState::self()->getCallingUid());

    wp<Client> w = c;
    {
        Mutex::Autolock lock(mLock);
        mClients.add(w);
    }
    return c;
}

在这个函数中，创建了一个MediaPlayerService::Client实例，也就是说，MediaPlayerService会为每个client应用程序创建一个相应的MediaPlayerServece::Client，来提供服务。也就是说，mediaplayer.cpp中执行的setDataSource函数，在MediaPlayerService.cpp中，实际上只是创建了一个client，并将两者对应起来，如果再次执行setDataSource函数，会创建第二个client。同时看这个函数的返回值类型，为sp<IMediaPlayer>，而在函数的最后，return c，这个c的类型是sp<Client>，从而从侧面也证明了两者几乎是等同的关系。

3）回执后setDataSource的流程

继续回到frameworks/av/media/libmedia/mediaplayer.cpp中的MediaPlayer::setDataSource函数中，上面执行完了create函数，MediaPlayerService创建了一个client对应，同时将这个client返回到MediaPlayer中，那就继续执行下面的：

player->setDataSource(fd, offset, length)

此时，这个player就对应刚创建的client，以后每次执行有关player的操作，都会对应执行到MediaPlayerService::Client中的操作，所以，这里就执行到了MediaPlayerService::Client::setDataSource函数中：

status_t MediaPlayerService::Client::setDataSource(int fd, int64_t offset, int64_t length)
{
    ALOGV("setDataSource fd=%d (%s), offset=%lld, length=%lld",
            fd, nameForFd(fd).c_str(), (long long) offset, (long long) length);
............

    player_type playerType = MediaPlayerFactory::getPlayerType(this,
                                                               fd,
                                                               offset,
                                                               length);
    sp<MediaPlayerBase> p = setDataSource_pre(playerType);
    if (p == NULL) {
        return NO_INIT;
    }

    // now set data source
    setDataSource_post(p, p->setDataSource(fd, offset, length));
    return mStatus;
}

这里面有三个重点，我都标红了。这三个重点放在后面再讲，这里先分析Media这块的Binder机制：

class BpMediaPlayerService: public BpInterface<IMediaPlayerService>

class BnMediaPlayerService: public BnInterface<IMediaPlayerService>

class IMediaPlayerService: public IInterface

IMediaPlayerService类中定义了MediaPlayerService中能够提供的服务函数，这个IMediaPlayerService类定义在IMediaPlayerService.h中，并且，需要通过DECLARE_META_INTERFACE宏来声明asInterface这个函数，这个函数与interface_cast相关。interface_cast函数就能够通过asInterface这个函数，创建一个BpMediaPlayerService。当然，具体实现是在asInterface函数中实现的，而asInterface函数的实现是在IMPLEMENT_META_INTERFACE宏中。

在IMediaPlayerService.h中，包含对IMediaPlayerService类的声明和BnMediaPlayerService的声明。

IMediaPlayerService类中包含BpMediaPlayerService需要实现的虚函数，相当于IMediaPlayerService.cpp 的头文件。BnMediaPlayerService中只声明一个onTransact函数。

在IMediaPlayerService.cpp中，包含了BpMediaPlayerService类的实现和BnMediaPlayerService类中onTransact函数的实现。

下面来看一下简单的代码实现（IMediaPlayerService.h）：

class IMediaPlayerService: public IInterface
{
public:
    DECLARE_META_INTERFACE(MediaPlayerService);

    virtual sp<IMediaRecorder> createMediaRecorder(const String16 &opPackageName) = 0;
    virtual sp<IMediaMetadataRetriever> createMetadataRetriever() = 0;
    virtual sp<IMediaPlayer> create(const sp<IMediaPlayerClient>& client, int 
		audioSessionId = 0)= 0;

    virtual sp<IOMX>            getOMX() = 0;
    virtual sp<ICrypto>         makeCrypto() = 0;
    virtual sp<IDrm>            makeDrm() = 0;
    virtual sp<IHDCP>           makeHDCP(bool createEncryptionModule) = 0;
    virtual sp<IMediaCodecList> getCodecList() const = 0;

    virtual sp<IRemoteDisplay> listenForRemoteDisplay(const String16 &opPackageName,
            const sp<IRemoteDisplayClient>& client, const String8& iface) = 0;

    enum BatteryDataBits {
xxxxxx
    };

    virtual void addBatteryData(uint32_t params) = 0;
    virtual status_t pullBatteryData(Parcel* reply) = 0;
};

// ----------------------------------------------------------------------------

class BnMediaPlayerService: public BnInterface<IMediaPlayerService>
{
public:
    virtual status_t    onTransact( uint32_t code,
                                    const Parcel& data,
                                    Parcel* reply,
                                    uint32_t flags = 0);
};

在IMediaPlayerService.cpp中，直接声明BpMediaPlayerService，它继承自BpInterface<IMediaPlayerService>，然后实现Bp端的代码。

同时，还包含BnMediaPlayerService::onTransact函数的具体实现。

以sp<IMediaPlayer> create函数为例(frameworks/av/media/libmedia/IMediaPlayerService.cpp)：

    virtual sp<IMediaPlayer> create(
            const sp<IMediaPlayerClient>& client, int audioSessionId) {
        Parcel data, reply;
        data.writeInterfaceToken(IMediaPlayerService::getInterfaceDescriptor());
        data.writeStrongBinder(IInterface::asBinder(client));
        data.writeInt32(audioSessionId);

        remote()->transact(CREATE, data, &reply);
        return interface_cast<IMediaPlayer>(reply.readStrongBinder());
    }

在Binder中，我们知道，Bp端只是一个Proxy，真正的实现是在Bn端，所以，在看这个文件中，就能够看到，Bp端只是填写data这个Parcel，然后通过remote()->transact()来把真正需要做的内容(CREATE命令)传递给Bn端。而Bn端其实只有一个onTransact函数，在这个函数中根据不同的case来分别处理：

status_t BnMediaPlayerService::onTransact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
    switch (code) {
        case CREATE: {
            CHECK_INTERFACE(IMediaPlayerService, data, reply);
            sp<IMediaPlayerClient> client =
                interface_cast<IMediaPlayerClient>(data.readStrongBinder());
            int audioSessionId = data.readInt32();
            sp<IMediaPlayer> player = create(client, audioSessionId);
            reply->writeStrongBinder(IInterface::asBinder(player));
            return NO_ERROR;
        } break;

mediaplayer.cpp这个是客户端，客户端提出的请求，最终由服务端来完成，服务端就是MediaPlayerService.cpp，由上面的代码，调用到create函数，这个函数在MediaPlayerService.cpp中实现：

sp<IMediaPlayer> MediaPlayerService::create(const sp<IMediaPlayerClient>& client,
        int audioSessionId)
{
    pid_t pid = IPCThreadState::self()->getCallingPid();
    int32_t connId = android_atomic_inc(&mNextConnId);

    sp<Client> c = new Client(
            this, pid, connId, client, audioSessionId,
            IPCThreadState::self()->getCallingUid());

    ALOGV("Create new client(%d) from pid %d, uid %d, ", connId, pid,
         IPCThreadState::self()->getCallingUid());

    wp<Client> w = c;
    {
        Mutex::Autolock lock(mLock);
        mClients.add(w);
    }
    return c;
}

在create函数中，其实是创建了一个MediaPlayerService::Client的实例，并且这个实例通过一个线程来维护。也就是说，MediaPlayerService会为每个客户端创建一个相应的MediaPlayerService::Client实例，用来提供服务。

这里又使用了一个小技巧，注意上面我标红的代码，首先是Bp端：data.writeStrongBinder(IInterface::asBinder(client));

这段代码又什么用呢？

它实际上是生成了一个匿名Binder Server，生成的Binder名字叫做IMediaPlayerClient，通过IInterface::asBinder(client)，这个Binder的BpMediaPlayerClient获取到BnMediaPlayerClient的handle，这样就能够将Bp端和Bn端联系起来。具体的代码在这里就不仔细分析了。总之，这个Binder没有注册到ServiceManager中，只能在这个进程内部使用。

同时这个IMediaPlayerClient并没有创建完整，后续的代码继续看上面标红的代码，这次在Bn端：

sp<IMediaPlayerClient> client =

interface_cast<IMediaPlayerClient>(data.readStrongBinder());

这次是真正的创建好IMediaPlayerClient了，然后就是下面的代码，来创建player，在创建player的create函数中，需要把这个Client传进去，同时，又再次用了上面介绍的匿名Binder Server的方法，再次创建了一个匿名Binder server，这次创建的是IMediaPlayer。

sp<IMediaPlayer> player = create(client, audioSessionId);

reply->writeStrongBinder(IInterface::asBinder(player));

这里可能要晕了，怎么弄了这么多Binder Server？

所以这里把这些Binder的关系屡屡。

首先是一个大Boss——IMediaPlayerService：

class IMediaPlayerService: public IInterface —— IMediaPlayerService.h

class BnMediaPlayerService: public BnInterface<IMediaPlayerService> —— IMediaPlayerService.h

class BpMediaPlayerService: public BpInterface<IMediaPlayerService> —IMediaPlayerService.cpp

这个MediaPlayerService需要处理的事情很多，对于IMediaPlayer的事情它要管，对于IMediaMetadataRetriever的事情它也要管，同时还有其他的如：IMediaRecorder，IOMX，IMediaCodecList等等。所以在内部，它会把一些任务分流，比如IMediaPlayer，它执行完create函数后，它为每个客户创建了一个MediaPlayerService::Client实例，并启用一个线程来负责它。

在log信息中可以看到：

01-01 00:06:02.373 230 535 V MediaPlayerService: Client(1) constructor

01-01 00:06:02.373 230 535 V MediaPlayerService: Create new client(1) from pid 1841, uid 10036,

每个客户端都对应MediaPlayerService中的一个Client，并且都有自己的一个connId。

除此之外，还启动了一个IMediaPlayerClient：

class IMediaPlayerClient: public IInterface —— IMediaPlayerClient.h

class BnMediaPlayerClient: public BnInterface<IMediaPlayerClient> —— IMediaPlayerClient.h

class BpMediaPlayerClient: public BpInterface<IMediaPlayerClient> —— IMediaPlayerClient.cpp

这个IMediaPlayerClient负责一个客户端的回调函数，比如对于一个MediaPlayer，MediaPlayerService通过IMediaPlayerClient来通知对应的MediaPlayer。

具体这个可以分析NuPlayerDriver: notifyListener_l(0xb5f17080), (5, 1024, 768)的执行流程。

这个IMediaPlayerClient只负责notify这个过程，它相当于包裹在MediaPlayer外面的一层wrapper。

那么最里面的是什么?肯定是IMediaPlayer啊~

class IMediaPlayer: public IInterface —— IMediaPlayer.h

class BnMediaPlayer: public BnInterface<IMediaPlayer> —— IMediaPlayer.h

class BpMediaPlayer: public BpInterface<IMediaPlayer> —— IMediaPlayer.cpp

这个就于playback息息相关了，对于每个MediaPlayer常用的函数，start，stop，setDataSource，pause，seekTo等等，都是通过它来传递给MediaPlayerService::Client的。

比如对于start的流程，首先mediaplayer.cpp中发出start的函数 ---> 到达IMediaPlayer的Bp端 ---> 传到IMediaPlayer的Bn端 ---> 到达MediaPlayerService::Client端的MediaPlayerService::Client::start函数 ---> NuPlayerDriver::start ---> NuPlayer: kWhatStart

就这样执行下去了。

后面再分析一个seekto，invoke，notify的流程。

理论上是除了setDataSource外，其他函数的流程都是相同的，notify可能例外一点。

至此，终于把Binder这一块的知识大致缕清了。

yanbixing123

关注

15
点赞
踩
17

收藏

觉得还不错? 一键收藏
1
评论
2. Android MultiMedia框架完全解析 - MediaPlayer的C/S架构与Binder机制实现

在Android中大量使用到了C/S架构来实现应用层和底层服务交互，而Binder机制无处不在。同样MediaPlayer也使用了这种机制，MediaPlayer在运行的时候，同样可以分为Client/Server两个部分，他们分别在不同的进程中运行，不同进程间的通信使用Binder机制，我们这里就以setDataSource()为例，讲解一下他们是如何建立关系的，架构图如下：1）...
复制链接

扫一扫

专栏目录