Android7.0 Binder通信(3) 客户进程查询和使用服务进程

前面的博客分析了Binder通信机制中，ServiceManager和服务进程的主要流程。
现在我们看看客户进程是如何查询到服务进程的，以及查询到服务进程后如何使用。

其实在了解了整个Binder通信机制的架构后，剩下的内容就比较好理解了。

我们以MediaServer进程中的MediaPlayerService为例，看看其客户端进程如何通过ServiceManager进行查询。
获取MediaPlayerService的接口定义于IMediaDeathNotifier.cpp中：

const sp<IMediaPlayerService>IMediaDeathNotifier::getMediaPlayerService(){    .........    if (sMediaPlayerService == 0) {        //前面博客分析过，通过defaultServiceManager将获取到BpServiceManager        sp<IServiceManager> sm = defaultServiceManager();        sp<IBinder> binder;        do {            //利用BpServiceManager的getService函数，获取与MediaPlayerService通信的BpBinder            binder = sm->getService(String16("media.player"));            if (binder != 0) {                break;            }            ALOGW("Media player service not published, waiting...");            usleep(500000); // 0.5 s        } while (true);        ...........        //之前的博客已经分析过，这里将利用IInterface的继承体系，用BpBinder构建出BpMediaPlayerService        sMediaPlayerService = interface_cast<IMediaPlayerService>(binder);    }    .............    return sMediaPlayerService;}

1 查询服务
从上面的代码可以看出，查询服务是通过BpServiceManager的getService函数来完成的，传入参数为待获取服务的名称：

virtual sp<IBinder> getService(const String16& name) const{    unsigned n;    //每次调用都重试5次    for (n = 0; n < 5; n++){        sp<IBinder> svc = checkService(name);        if (svc != NULL) return svc;        sleep(1);    }    return NULL;}virtual sp<IBinder> checkService( const String16& name) const {    Parcel data, reply;    data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());    data.writeString16(name);    //调用BpBinder的transact函数    remote()->transact(CHECK_SERVICE_TRANSACTION, data, &reply);    //利用返回的信息，构建BpBinder    return reply.readStrongBinder();}

之后BpBinder将调用IPCThreadState函数的transact函数，利用ioctl将请求写入到Binder设备中。这一部分内容之前的博客已经分析，此处不再赘述。
当ServiceManager收到数据后，利用svcmgr_handler进行处理。

int svcmgr_handler(....) {    ........    switch(txn->code) {    case SVC_MGR_GET_SERVICE:    case SVC_MGR_CHECK_SERVICE:        //取出待查找服务的名称        s = bio_get_string16(msg, &len);        .......        //得到对应服务的handle        handle = do_find_service(s, len, txn->sender_euid, txn->sender_pid);        ......        //将handle写入到reply中        bio_put_ref(reply, handle);        return 0;    .......    }    .......}

跟进一下do_find_service:

uint32_t do_find_service(const uint16_t *s, size_t len, uid_t uid, pid_t spid){    struct svcinfo *si = find_svc(s, len);    .........    return si->handle;}struct svcinfo *find_svc(const uint16_t *s16, size_t len) {    struct svcinfo *si;    for (si = svclist; si; si = si->next) {        if ((len == si->len) &&            !memcmp(s16, si->name, len * sizeof(uint16_t))) {            return si;        }    }    return NULL;}

从上面的代码可以看出，获取服务和注册服务的过程是完全对应的。
回忆一下，MediaPlayerService注册服务时，通过Binder机制将对应的信息发送给ServiceManager；ServiceManager利用收到的信息，构建对应的服务对象加入到svclist中。
现在客户端进程想要获取服务，同样利用Binder机制将请求发送给ServiceManager；ServiceManager收到请求后，从svclist中找到对应服务对象，并返回handle。

2 使用服务
获取BpBinder构建出BpMediaPlayerService后，就能够使用任何IMediaPlayerService定义的业务接口了。
我们以addBatteryData接口为例，看看客户发送的请求是如何被服务进程处理的。

virtual void addBatteryData(uint32_t params) {    Parcel data, reply;    data.writeInterfaceToken(IMediaPlayerService::getInterfaceDescriptor());    data.writeInt32(params);    remote()->transact(ADD_BATTERY_DATA, data, &reply);}

从上面的代码可以看出，调用BpMediaPlayerService中的接口，实际上也是通过BpBinder将请求发往服务端进程。
那么服务端是如何处理这些请求的呢？

已知MediaPlayerService运行在MediaServer进程中，MediaServer进程中有两个IPCThreadState在处理Binder设备的发来的数据。
因此，服务进程处理客户端请求的流程，肯定也是从IPCThreadState接收数据开始的。
在前面的博客中提到，在MediaServer进程main函数的最后，调用了IPCThreadState的joinThreadPool方法：

void IPCThreadState::joinThreadPool(bool isMain){    ........    do {        .......        //无限循环调用getAndExecuteCommand处理数据        result = getAndExecuteCommand();        .......    }while(result != -ECONNREFUSED && result != -EBADF);    ........}status_t IPCThreadState::getAndExecuteCommand(){    .......    //ioctl收发数据    result = talkWithDriver();    if (result >= NO_ERROR) {        ......        //这里就是服务进程，处理客户端请求的地方        result = executeCommand(cmd);        ......    }    .......}

我们跟进executeCommand：

status_t IPCThreadState::executeCommand(int32_t cmd){    switch ((uint32_t)cmd) {    ........    case BR_TRANSACTION:        {            binder_transaction_data tr;            result = mIn.read(&tr, sizeof(tr));            ............            //创建BpBinder时，指定了服务的handle            //BpBinder传输时，handle被写入到tr.target中            if (tr.target.ptr) {                .......                //按照前一篇博客中提到的Binder通信继承体系，我们知道服务端的BnMediaPlayerService将继承BBinder                //因此这里应该是调用BnMediaPlayerService的transact函数                error = reinterpret_cast<BBinder*>(tr.cookie)->transact(tr.code, buffer,                        &reply, tr.flags);                .......            } else {                .......            }            ...........        }        break;    ........    }    ........}

BnMediaPlayerService的transact函数，实际上由其父类BBinder实现，定义与Binder.cpp中：

status_t BBinder::transact(....) {    ........    switch (code) {        case PING_TRANSACTION:            reply->writeInt32(pingBinder());            break;        default:            //调用子类的onTransact函数，此时从请求从通信层，真正进入到业务层            err = onTransact(code, data, reply, flags);            break;    }    ........}

跟进BnMediaPlayerService中的onTransact函数：

status_t BnMediaPlayerService::onTransact(.....) {    switch (code) {        case CREATE:         .......        case ADD_BATTERY_DATA: {            CHECK_INTERFACE(IMediaPlayerService, data, reply);            uint32_t params = data.readInt32();            //根据前面博客中Binder的继承体系，我们知道实际的MediaPlayerService继承BnMediaPlayerService            //故此处将调用MediaPlayerService的addBatteryData            addBatteryData(params);            return NO_ERROR;        } break;        ...........    }}

以上就是客户端进程查询和使用服务进程的主要流程，当了解整个Binder通信机制的架构后，整个过程还是比较好理解的。