通过MediaPlayer理解Binder的使用

理解Binder的使用是一件不容易的事，尤其由浅入深，本文参考Android深入浅出之Binder机制和Android Binder设计与实现这两文章为基础，从Java层的MediaPlayer开始分析Client, Server 和ServiceManager！至于Binder的实现可以搜索CSDN老罗的文章，也可以看http://blog.csdn.net/bathinbreeze/article/details/8989431，涉及到kernel这里不讨论，本文只作为分析android代码记忆用

 

首先，先从JAVA层的mediaplayer类看起

(framework/base/media/java/android/media/MediaPlayer)

在app调用MediaPlayer时，我们是先new 一个Mediaplayer，然后setDataSource,prepare,start

那这些函数在MediaPlayer是怎么实现的呢？我们看看MediaPlayer类

不看hanlder，直接看native_setup

Native_setup是一个jni函数，也就是说mediaplayer的建立不在java层，而setDataSource,start这些函数也一样不在java层

既然这样，我们就必须跑去jni层看看到底mediaplayer是怎么工作的

根据mediaplayer的包名，我可以锁定mediaplayer jni的c文件

(framework/base/media/jni/android_media_MediaPlayer.cpp)

在jni层里找到native_setup和setDataSource注册的原型

那看看这两个函数怎么实现

native_setup主要是创建了C++层的MediaPlayer对象

而setDatasource则是通过创建的mediaplayer对象，调用对象的setDataSource

 

从这里可以看出jni层实际上是通过调用C++的mediaplayer实现java层mediaplayer的功能。

 

为了进一步了解，我们跟踪到c++的mediaplayer类，同样以初始化和setdatasource为例

（framework/av/media/libmedia/mediaplayer.cpp）

从初始化看，Mediaplayer初始化只是初始化一些变量

那我们看看setdatasource函数

在这里面我们发送好像跟service有关的东西，对了，这就是Mediaplayer的客户端（Mediaplayer类是binder中的client）通过Binder的ServiceManger获取Mediaplayer服务端（MediaPlayerService是binder的 Server）实例，并调用服务端实例的函数！那Mediaplayer服务端在那里，servicemanager又是怎么一回事呢，我们继续往下分析，但这里不采取继续跟踪代码下去，我们先去了解Binder ServiceManager和MediaplayerSerice，从而了解binder的manager和server，然后再回到这边！但是我们要记住有个IServiceManager，IBinder和IMediaPlayerService这些类，等下我们就靠这些把ServiceManager，  Mediaplayer Server，

Mediaplayer client贯通起来，从而建立起binder servicemanager，server，client的使用流程

 

 

 

 

Binder ServiceManager和Mediaplayer Server在系统开机时都被启动。

 

首先我们看看servicemanager

(framework/Native/cmds/ServiceManager/)

从这里可以看到SeviceManager打开了binder设备，并向binder发送命令，告诉binder成为binder manager，并进入循环。

而循环主要是通过控制读取或写入binder设备，等待请求到来，如果有有请求则对所读到的

内容进行解析，解析之后回调给svcmgr_handler

从代码binder_transaction_data里面code知，servicemanager分了SVC_MGR_GET_SERVICE，

SVC_MGR_CHECK_SERVICE，SVC_MGR_ADD_SERVICE，SVC_MGR_LIST_SERVICES，

几个消息

另外从代码中知道， addservice 和getservice都是从 svcinfolist增查，而svcinfo的结构如下

struct svcinfo 
{
    struct svcinfo *next;
    void *ptr; // service pointer
    struct binder_death death;
    int allow_isolated;
    unsigned len;
    uint16_t name[0]; // service名字
};

增加时，回复成功

而获取service时则需把引用填充如reply，最后发到binder里

而其中要注意的

要知道svcmgr_hanlde被赋值为0，在回调函数，遇到非0的都直接return -1，不做任何操作

 

附：

在这些命令中，最常用的是BC_TRANSACTION/BC_REPLY命令对，Binder数据通过这对命令发送给接收方。这对命令所承载的数 据包由结构体struct binder_transaction_data定义。Binder交互有同步和异步之分，利用binder_transaction_data中 flag域区分。如果flag域的TF_ONE_WAY位为1则为异步交互，即Client端发送完请求交互即结束， Server端不再返回BC_REPLY数据包；否则Server会返回BC_REPLY数据包，Client端必须等待接收完该数据包方才完成一次交 互。

写数据一样，其中最重要的消息是BR_TRANSACTION 或BR_REPLY，表明收到了一个格式为binder_transaction_data的请求数据包（BR_TRANSACTION）或返回数据包 （BR_REPLY）

收发都是 消息ID+消息数据（binder_transaction_data）

在android代码为数据接口binder_txn

其中其data在android表示为如下

Servicemanager就分析到这里，在这里没发现跟mediaplayer一点有关的东西，那我们去看看Mediaplayer Server

（framework/av/Media/MediaServer/Main_mediaserver.cpp）

在main函数中我们看到，创建了一个proc，获取了servicemanager，并初始化了MediaplayerService，并开启了线程池！在这里我们发现了跟media有关的MediaplayerService，暂时不理会，我们代码从第一个看起！

 

首先是ProcessState:self()

从代码中我们看出processstate构造函数初始化列表打开了binder设备，并向binder设备发送了两条命令，我们可以说processstate 记录着打开的binder设备，以便提供给后面提供操作。

代码的第二步是获取一个servicemanager对象，我们跟踪进去看他是怎么获取的！

首先通过processstate获取了servicemanager的IBinder对象，并转化为IServiceManager（前面的MediaplayerClient也是这样获取哦），即获取了servicemanager对象

 

继续跟踪程序，看怎么获取IBinder对象和转化为IServiceManager

 

1.IBinder对象的获取

从代码可以看到，IBinder对象的获取实际上是new BpBinder(0);

 

那BpBinder是什么呢？

BpBinder继承于IBinder，而IBinder实际是ServiceManager抽象出来的接口类，为Server提供接口操作binder，而BpBinder则是IBinder的实现，也可以说代理了Binder的操作（ transact等）

2.IBinder转化为IServiceManager

从代码可以看出interface_cast 模版函数把IBinder转化成ISeriviceManager实际上调用的是IServiceManager的asInteface函数，那我跟踪到IServiceManager类看看

在IServiceManager类中没看到asInterface函数哦，但是有个DECLARE_META_INTERFACE的宏，我们往这个走下去，看能找到asInterface不！

果然，asInterface用连接的方式写在了宏里面，那我们看看是怎么转，在前面

我们是传入了IServiceManager.asInterface(new BpBinder(0));

而asInterface把IBinder转化成IserviceManager，确是

New BpServiceManager(new BpBinder(0));也就是把IBinder对象赋予了IServiceManager子类BpServiceManager

而BpServiceManager则是代理了IBinder的操作，

如果addService，调用了BpBinder（IBinder）的transact函数，发送ADD_SERVICE_TRANSACTION到Binder

而BpBinder

则通过IPCThreadState:self()的transact发送数据给Binder

 

ServiceManager已经获得（通过new bpBinder（0），并转化成BpSeriviceManager），

接着MediaplayerService把自己注册到ServiceManager里面

可以看到是调用BpServiceManager的addService（前面说到addService实际上就是通过new BpBinder(0)的transact函数，而BpBinder则是通过IPCThreadState的transact把数据发送给了binder），把自己注册给了ServiceManager，而ServiceManager也把他记录了起来

 

到这里我们就知道ServiceManager和MediaServer大概工作方式

从继承结构可以看出这是一个对象适配器模式，而不是代理模式，因为他们没有共同的父类，更多的是对象的适配，而IBinder和BnBinder，和BpBinder才是代理模式，IServiceManager，BnServiceManager，BpServiceManger也是代理模式

void MediaPlayerService::instantiate() {
    defaultServiceManager()->addService(
            String16("media.player"), new MediaPlayerService());
}

 virtual status_t addService(const String16& name, const sp<IBinder>& service,
            bool allowIsolated = false)
    {
        Parcel data, reply;
        data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
        data.writeString16(name);
        data.writeStrongBinder(service);
        data.writeInt32(allowIsolated ? 1 : 0);
        status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
        return err == NO_ERROR ? reply.readExceptionCode() : err;
    }

 

addService把MediaPlayerService传给了ServiceManager，BnMediaPlayerService的onTransact则负责接收实现功能（进程中开启的IPCThreadState::self()->joinThreadPool();里面调用BBinder接收信息，而MediaplayerService的父类BnMediaPlayerService则实现接收信息处理onTransact）

同时也开放了代理类，让客户端调用。

根据服务端，我们再回头看看 Media Client端，他是怎么通过ServiceManager跟MediaServer进行通讯的

代码中，先获取了Mediaplayer server，跟踪进去看看做了什么

首先获取了serviceManager，这个是media server是一样的！

然后通过获取到的serviceManager的getService函数获取到mediaplayer server，getService其实跟addService是一样的，但是我们为了清楚，跟踪进去看看

打开BpManagerService类，

getService函数，实际上就是根据名字向binder发送CHECK_SERVICE_TRANSACTION命令，从而让serviceManager回应获取到Mediaplayer server

我们到ServiceManger那边看看他怎么解析这些数据，并返回了什么

int svcmgr_handler(struct binder_state *bs,
                   struct binder_txn *txn,
                   struct binder_io *msg, /** 是data */
                   struct binder_io *reply)
{
struct svcinfo *si;
    uint16_t *s;
    unsigned len;
    void *ptr;
    uint32_t strict_policy;
    int allow_isolated;

//    ALOGI("target=%p code=%d pid=%d uid=%d\n",
//         txn->target, txn->code, txn->sender_pid, txn->sender_euid);

    if (txn->target != svcmgr_handle)
        return -1;

    // Equivalent to Parcel::enforceInterface(), reading the RPC
    // header with the strict mode policy mask and the interface name.
    // Note that we ignore the strict_policy and don't propagate it
    // further (since we do no outbound RPCs anyway).
    strict_policy = bio_get_uint32(msg);
    s = bio_get_string16(msg, &len);
    if ((len != (sizeof(svcmgr_id) / 2)) ||
        memcmp(svcmgr_id, s, sizeof(svcmgr_id))) {
        fprintf(stderr,"invalid id %s\n", str8(s));
        return -1;
    }

    switch(txn->code) {
    case SVC_MGR_GET_SERVICE:
    case SVC_MGR_CHECK_SERVICE:
        s = bio_get_string16(msg, &len);
        ptr = do_find_service(bs, s, len, txn->sender_euid);
        if (!ptr)
            break;
	// 如果找到则填充ptr入reply
        bio_put_ref(reply, ptr);
        return 0;

.....
}
}

从代码看出是通过do_find_service找出Media.Player

void *do_find_service(struct binder_state *bs, uint16_t *s, unsigned len, unsigned uid)
{
    struct svcinfo *si;
    si = find_svc(s, len);

//    ALOGI("check_service('%s') ptr = %p\n", str8(s), si ? si->ptr : 0);
    if (si && si->ptr) {
        if (!si->allow_isolated) {
            // If this service doesn't allow access from isolated processes,
            // then check the uid to see if it is isolated.
            unsigned appid = uid % AID_USER;
            if (appid >= AID_ISOLATED_START && appid <= AID_ISOLATED_END) {
                return 0;
            }
        }
        return si->ptr;
    } else {
        return 0;
    }
}

看到返回的是SVCINFO的ptr，而这个就是MediaplayserService被写成flat_binder_object对象的引用

bio_put_ref(reply, ptr);
void bio_put_ref(struct binder_io *bio, void *ptr)
{
    struct binder_object *obj;

    if (ptr)
        obj = bio_alloc_obj(bio);
    else
        obj = bio_alloc(bio, sizeof(*obj));

    if (!obj)
        return;

    obj->flags = 0x7f | FLAT_BINDER_FLAG_ACCEPTS_FDS;
    obj->type = BINDER_TYPE_HANDLE;
    obj->pointer = ptr;
    obj->cookie = 0;
}

把flat_binder_object赋值给了binder_object,通过Binder发回给MediaClient

MediaClient（BpMediaPlayerService）则

sp<IBinder> Parcel::readStrongBinder() const
{
    sp<IBinder> val;
    unflatten_binder(ProcessState::self(), *this, &val);
    return val;
}

解出里面的Binder（MediaPlayerService）

在ServiceManager那边返回的flat->type都为handle，所以获取Binder也是

通过*out = proc->getStrongProxyForHandle(flat->handle); 只不过这里的handler不是为0

相当于new BpBinder(flat->handle);

这样MediaClient获取获取到了mediaserver的对象，但获取到是binder对象，还需要转化成IMediaPlayerService这样，MediaClient才能跟MediaServer对话

从代码看出binder对象转化成了BpMediaPlayerService( new BpMediaPlayerService(binder))

我们看看BpMediaPlayerService

BpMediaPlayerService跟BpServiceManager类似，代理了binder和mediaplayerservice的之间交互。

此时这里的mHandle不为0哦

用MediaPlayer Server的binder（MediaplayerService）发送 create命令，而MediaPlayerService（MediaPlayerService继承BnMediaPlayerService继承BBinder继承IBinder）接收到create命令后

在BR_TRANSACTION回调给MediaplayerService（BPBinder）

创建了Mediaplayer的client

 

其他Mediaplayer client start，sotp等函数都类似！

 

 

最后总结下binder 的server client servicemanager模式

第一步：通过binder向servicemanager注册自己的service

第二步：client通过servicemanager获取server

第三步：获取到server后，client通过binder跟sserver进行通讯