安卓MediaPlayer框架之Binder机制

最新推荐文章于 2022-04-19 22:57:39 发布

王鑫鑫鑫

最新推荐文章于 2022-04-19 22:57:39 发布

阅读量561

点赞数 4

分类专栏：安卓源码文章标签： MediaPlayer AOSP 安卓 Binder

本文链接：https://blog.csdn.net/qq_41786131/article/details/93079210

版权

安卓源码专栏收录该内容

11 篇文章 1 订阅

订阅专栏

一、Binder简介

Binder是Android系统进程间通信的主要方式之一。

1.在ASOP中，Binder使用传统的C/S通信方式：即一个进程作为服务端提供诸如视音频解封装，解码渲染，地址查询等各种服务，众多进程作为客户端向服务端发起请求，获得所需的服务。

2.面向对象的封装模式：首先Binder是作为一个实体类存在于Server端，该对象拥有一系列的借口来实现对服务端的各种操作，而在诸多的Client端，都存在一个Binder入口，通往了特定的Server端，就像是Server端的Binder实体拥有许许多多的指针遍布于各个Client中，Client就通过这个指针实现了向服务端的请求。

二、Binder结构

首先看一下安卓的整体架构，可其遍布于整个安卓系统中，自地向上形成了一个统一的接口：（转载）

当然，Client和Service端都通过一个ServiceManager进行统一管理，具体通信模型如下：

三、结合代码讲解

当然，要细说Binder机制可不是一朝一夕的事情，我们今天结合安卓MediaPlayer的native层代码，来看看Binder是如何实现跨进程通信的。如果没有这方面知识还是建议先去小补一下。附上类图：

我们知道MediaPlayer的java层代码调用的就是再往下的native层C/C++代码，其中setDataSource()函数作为开路先锋带动了往下的各个类，所以我们就抓住它来分析一下Binder机制。直接看MediaPlayer.cpp的setDataSource()代码吧。

//代码目录：/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());//通过IPC机制获取一个远程服务
    if (service != 0) {
        sp<IMediaPlayer> player(service->create(this, mAudioSessionId));//通过MediaPlayerService端创建了一个Client
        if ((NO_ERROR != doSetRetransmitEndpoint(player)) ||
            (NO_ERROR != player->setDataSource(fd, offset, length))) {//调用Client的setDataSource()
            player.clear();
        }
        err = attachNewPlayer(player);
    }
    return err;
}

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

//代码码目录：/frameworks/av/media/libmedia/IMediaDeathNotifier.cpp
/*static*/const sp<IMediaPlayerService>
IMediaDeathNotifier::getMediaPlayerService()
{
    ALOGV("getMediaPlayerService");
    Mutex::Autolock _l(sServiceLock);
    if (sMediaPlayerService == 0) {
        sp<IServiceManager> sm = defaultServiceManager();
        sp<IBinder> binder;
        do {
            binder = sm->getService(String16("media.player"));
            if (binder != 0) {
                break;
            }
            ALOGW("Media player service not published, waiting...");
            usleep(500000); // 0.5 s
        } while (true);

        if (sDeathNotifier == NULL) {
            sDeathNotifier = new DeathNotifier();
        }
        binder->linkToDeath(sDeathNotifier);
        sMediaPlayerService = interface_cast<IMediaPlayerService>(binder);
    }
    ALOGE_IF(sMediaPlayerService == 0, "no media player service!?");
    return sMediaPlayerService;
}

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

代码目录：frameworks/native/include/binder/IInterface.h
template<typename INTERFACE>
inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)
{
    return INTERFACE::asInterface(obj);
}

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

/frameworks/native/include/binder/IInterface.h
// ----------------------------------------------------------------------

#define DECLARE_META_INTERFACE(INTERFACE)                               \
    static const ::android::String16 descriptor;                        \
    static ::android::sp<I##INTERFACE> asInterface(                     \
            const ::android::sp<::android::IBinder>& obj);              \
    virtual const ::android::String16& getInterfaceDescriptor() const;  \
    I##INTERFACE();                                                     \
    virtual ~I##INTERFACE();                                            \


#define IMPLEMENT_META_INTERFACE(INTERFACE, NAME)                       \
    const ::android::String16 I##INTERFACE::descriptor(NAME);           \
    const ::android::String16&                                          \
            I##INTERFACE::getInterfaceDescriptor() const {              \
        return I##INTERFACE::descriptor;                                \
    }                                                                   \
    ::android::sp<I##INTERFACE> I##INTERFACE::asInterface(              \
            const ::android::sp<::android::IBinder>& obj)               \
    {                                                                   \
        ::android::sp<I##INTERFACE> intr;                               \
        if (obj != NULL) {                                              \
            intr = static_cast<I##INTERFACE*>(                          \
                obj->queryLocalInterface(                               \
                        I##INTERFACE::descriptor).get());               \
            if (intr == NULL) {                                         \
                intr = new Bp##INTERFACE(obj);                          \
            }                                                           \
        }                                                               \
        return intr;                                                    \
    }                                                                   \
    I##INTERFACE::I##INTERFACE() { }                                    \
    I##INTERFACE::~I##INTERFACE() { }                                   \


#define CHECK_INTERFACE(interface, data, reply)                         \
    if (!(data).checkInterface(this)) { return PERMISSION_DENIED; }     \

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

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

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

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

代码目录：/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());
    }

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

// static
sp<IBinder> IInterface::asBinder(const sp<IInterface>& iface)
{
    if (iface == NULL) return NULL;
    return iface->onAsBinder();
}

template<typename INTERFACE> inline IBinder* BpInterface<INTERFACE>::onAsBinder() { return remote(); }

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实现:

xref: /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);
            reply->writeStrongBinder(IInterface::asBinder(player));
            return NO_ERROR;
        } break;
    ...}
}

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

xref: /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());

    ALOGD("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;
}

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

//代码目录：/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());//通过IPC机制获取一个远程服务
    if (service != 0) {
        sp<IMediaPlayer> player(service->create(this, mAudioSessionId));//通过MediaPlayerService端创建了一个Client
        if ((NO_ERROR != doSetRetransmitEndpoint(player)) ||
            (NO_ERROR != player->setDataSource(fd, offset, length))) {//调用Client的setDataSource()
            player.clear();
        }
        err = attachNewPlayer(player);
    }
    return err;
}

后面就没啥说的了，直接调用Client的setDataSource进入了下一步处理。

总结一下：我们发现native层的大部分类都是采用IXXX，BpXXX，BnXXX形式的。在MediaPlayer框架层，由IMediaPlayer，IMediaPlayerService，IMediaPlayerClient三大元老组成了基本框架，由IBinder，BBinder(准确来说叫BnBinder比较合适)，BpBinder将其粘合。

我们发现，IXXX里总是一些虚抽象函数，不存在定义，由BpXXX和BnXXX继承它，BpXXX作为Client端的代理类，发起服务的请求，服务的实现则统一放在BnXXX类里。

王鑫鑫鑫

关注

4
点赞
踩
8

收藏

觉得还不错? 一键收藏
0
评论
安卓MediaPlayer框架之Binder机制

一、Binder简介 Binder是Android系统进程间通信的主要方式之一。 1.在ASOP中，Binder使用传统的C/S通信方式：即一个进程作为服务端提供诸如视音频解封...
复制链接

扫一扫