Binder - 5、一次平平无奇的Binder通信

一、前言

在Binder - 4、获取Service的过程中，我们通过驱动层拿到了SurfaceFlinger对应的handle 0，然后用其创建了BpBinder，并在随后将其转换成为了BpSurfaceComposer。

在本文中，我们以BpSurfaceComposer的一次调用为例，看下Binder调用是怎么从Client端调用到Server端的。

二、源码分析

我们在前文中，是以SurfaceComposerClient为切入点，这次我们依然从这里开始，通过connectLocked拿到BpBinder之后，将其存储在了mComposerService对象中，我们找一个方法开始分析，这里以createDisplay为例：

frameworks\native\libs\gui\SurfaceComposerClient.cpp

sp<IBinder> SurfaceComposerClient::createDisplay(const String8& displayName, bool secure) {

    return ComposerService::getComposerService()->createDisplay(displayName,

            secure);

}

其中，getComposerService得到的就是mComposerService，我们直接进入其实现中

2.1 Client进程-createDisplay调用开始

frameworks\native\libs\gui\ISurfaceComposer.cpp

sp<IBinder> createDisplay(const String8& displayName, bool secure) override {

    Parcel data, reply;

    data.writeInterfaceToken(ISurfaceComposer::getInterfaceDescriptor());

    status_t status = data.writeString8(displayName);

    if (status) {

        return nullptr;

    }

    //...

    status = remote()->transact(BnSurfaceComposer::CREATE_DISPLAY, data, &reply);

    if (status) {

        return nullptr;

    }

    sp<IBinder> display;

    status = reply.readNullableStrongBinder(&display);

    if (status) {

        return nullptr;

    }

    return display;

}

可以看到直接调用了remote()->transact，我们已经知道remote()指代的就是BpBinder，接下来就进入了BpBinder的transact()方法，接下来大部分的过程与我们在Binder - 3、注册Service的过程一节中一样，只是handle发生了变化，我们重点看下发生变化的部分：

IPCThreadState::transact

没有变化

->

IPCThreadState::writeTransactionData

->

IPCThreadState::waitForResponse

->

IPCThreadState::talkWithDriver

进入驱动层

->

binder_thread_write

->

binder_transaction

2.2 Client进程-binder_transaction BC_TRANSACTION

static void binder_transaction(struct binder_proc *proc,

                   struct binder_thread *thread,

                   struct binder_transaction_data *tr, int reply,

                   binder_size_t extra_buffers_size)

{

    if (reply) {

        //...

    } else {

        //此时我们作为Client，handle不为0

        if (tr->target.handle) {

            struct binder_ref *ref;

            //获取目标进程中handle对应的binder_ref对象

            ref = binder_get_ref_olocked(proc, tr->target.handle,

                             true);

            if (ref) {

                //增加binder_node的强引用，并将其返回

                target_node = binder_get_node_refs_for_txn(

                        ref->node, &target_proc,

                        &return_error);

            }

        } else {

            //ServiceManager

        }

    }

    //...

  


    //获取offset

    off_start_offset = ALIGN(tr->data_size, sizeof(void *));

    buffer_offset = off_start_offset;

    off_end_offset = off_start_offset + tr->offsets_size;

    sg_buf_offset = ALIGN(off_end_offset, sizeof(void *));

    sg_buf_end_offset = sg_buf_offset + extra_buffers_size -

        ALIGN(secctx_sz, sizeof(u64));

    off_min = 0;

    //根据offset来切分data，在这个例子中，由于只写入了两个基础数据，所以没有object，也就是offsets_size=0，不需要进入循环

    for (buffer_offset = off_start_offset; buffer_offset < off_end_offset;

         buffer_offset += sizeof(binder_size_t)) {

    }

    //唤醒对端

    return;

}

一些重复的方法我们再次略去，只关注变化的部分。

此时，我们目标是对端的Binder对象，所以不再是ServiceManager了。

2.3 Server进程-BR_TRANSACTION

在Binder驱动将Server进程唤醒之后，Server进程的工作线程被唤醒开始工作，并进入BR_TRANSACTION相关的case中：

这部分我们在Binder - 3、注册Service的过程里面已经讲过，但是发生了一些变化

status_t IPCThreadState::executeCommand(int32_t cmd)

{

    BBinder* obj;

    RefBase::weakref_type* refs;

    status_t result = NO_ERROR;

  


    switch ((uint32_t)cmd) {

        case BR_TRANSACTION_SEC_CTX:

        case BR_TRANSACTION:

            {

                binder_transaction_data_secctx tr_secctx;

                binder_transaction_data& tr = tr_secctx.transaction_data;

                //读取binder_transaction_data_secctx数据

                if (cmd == (int) BR_TRANSACTION_SEC_CTX) {

                    result = mIn.read(&tr_secctx, sizeof(tr_secctx));

                } else {

                    result = mIn.read(&tr, sizeof(tr));

                    tr_secctx.secctx = 0;

                }

  


                Parcel buffer;

                //转换为Parcel对象

                buffer.ipcSetDataReference(

                    reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),

                    tr.data_size,

                    reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),

                    tr.offsets_size/sizeof(binder_size_t), freeBuffer);

                //...

  


                Parcel reply;

                status_t error;

                //这次我们的目标不为0了

                if (tr.target.ptr) {

                    //试图拿到目标target对应的BBinder对象，然后执行transact

                    if (reinterpret_cast<RefBase::weakref_type*>(

                            tr.target.ptr)->attemptIncStrong(this)) {

                        error = reinterpret_cast<BBinder*>(tr.cookie)->transact(tr.code, buffer,

                                &reply, tr.flags);

                        //

                        reinterpret_cast<BBinder*>(tr.cookie)->decStrong(this);

                    } else {

                        error = UNKNOWN_TRANSACTION;

                    }

                } else {

                    //之前我们是`servermanager`，但是这次不是

                    error = the_context_object->transact(tr.code, buffer, &reply, tr.flags);

                }

                if ((tr.flags & TF_ONE_WAY) == 0) {

                    LOG_ONEWAY("Sending reply to %d!", mCallingPid);

                    if (error < NO_ERROR) reply.setError(error);

  


                    constexpr uint32_t kForwardReplyFlags = TF_CLEAR_BUF;

                    //告诉对端，Binder通信完成

                    sendReply(reply, (tr.flags & kForwardReplyFlags));

                } else {

                    //...

                }

                //...

            }

            break;

    }

    return result;

}

这次我们的目标已经发生了变化，不再是ServiceManager，所以会调用到相应Binder的transact方法去，这里的Binder对象也是我们在注册Service的时候注册进去的。

2.4 server-进程-reinterpret_cast

在拿到cookie之后，我们看到调用了一次reinterpret_cast，这个reinterpret_cast实际上是C++的强制类型转换，只是非常灵活，这里的cookie其实是我们之前传给Binder驱动的BBinder对象的地址，经过reinterpret_cast一转换，我们就可以直接拿到BBinder对象，也就是Service对象了。

2.5 Server进程-transact

status_t BBinder::transact(

    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)

{

    data.setDataPosition(0);

  


    status_t err = NO_ERROR;

    switch (code) {

        //...

        default:

            err = onTransact(code, data, reply, flags);

            break;

    }

    //...

    return err;

}

默认情况下，会直接调用到onTransact函数，这个函数是被各个Service自己来实现的，在这里，我们的Service也就是BBinder，类型是BnSurfaceComposer，真正的实现是SurfaceFlinger。

我们看下BnSurfaceComposer真正的实现：

2.6 Server进程-onTransact

status_t BnSurfaceComposer::onTransact(

    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)

{

    switch(code) {

        case CREATE_DISPLAY: {

            CHECK_INTERFACE(ISurfaceComposer, data, reply);

            String8 displayName;

            SAFE_PARCEL(data.readString8, &displayName);

            bool secure = false;

            SAFE_PARCEL(data.readBool, &secure);

            //真正调用实现

            sp<IBinder> display = createDisplay(displayName, secure);

            //写到reply里面去

            SAFE_PARCEL(reply->writeStrongBinder, display);

            return NO_ERROR;

        }

    }

}

在BnSurfaceComposer的onTransact方法中，真正调用了createDisplay方法，而这个createDisplay方法由SurfaceFlinger来实现，最终将返回值写入reply中（这里的返回值刚好是Binder对象）。

如果仔细看的话，会发现BpSurfaceManager的调用和BnSurfaceComposer的被调用是在一个文件里面的，只是一个是Client一个是Server，虽然在一个文件里面，但是这二者调用却经历了太多的过程，远没有表面那么和谐。

2.7 Server进程-sendReply

回到刚才的executeCommand方法中，现在我们调用完成，而且reply中已经有了数据，可以说是"满载而归"，是时候将数据返回回去了，也即sendReply:

status_t IPCThreadState::sendReply(const Parcel& reply, uint32_t flags)

{

    status_t err;

    status_t statusBuffer;

    err = writeTransactionData(BC_REPLY, flags, -1, 0, reply, &statusBuffer);

    if (err < NO_ERROR) return err;

  


    return waitForResponse(nullptr, nullptr);

}

非常的简单，首先是写入transaction数据，然后通过waitForResponse与binder驱动进行通信，但是此时waitForResponse传了两个空参数，也就是说，等数据发完，这边的调用就完毕了。

话不多说，我们直接进入驱动层。

2.8 driver-binder_thread_write BC_REPLY

重新进入驱动，还是这几个方法，但是这次code不一样，code现在是BC_REPLY:

static int binder_thread_write(struct binder_proc *proc,

            struct binder_thread *thread,

            binder_uintptr_t binder_buffer, size_t size,

            binder_size_t *consumed)

{

    uint32_t cmd;

    struct binder_context *context = proc->context;

    void __user *buffer = (void __user *)(uintptr_t)binder_buffer;

    void __user *ptr = buffer + *consumed;

    void __user *end = buffer + size;

    while (ptr < end && thread->return_error.cmd == BR_OK) {

        int ret;

        if (get_user(cmd, (uint32_t __user *)ptr))

            return -EFAULT;

        ptr += sizeof(uint32_t);

        switch (cmd) {

        //再回头看，BC_TRANSACTION和BC_REPLY是并列的，说明这两个数据流向是一样的。

        case BC_TRANSACTION:

        case BC_REPLY: {

            struct binder_transaction_data tr;

            //从用户进程读取binder_transaction_data

            if (copy_from_user(&tr, ptr, sizeof(tr)))

                return -EFAULT;

            ptr += sizeof(tr);

            binder_transaction(proc, thread, &tr,

                       cmd == BC_REPLY, 0);

            break;

        }

        *consumed = ptr - buffer;

        }

    }

    return 0;

}

还是走的以前一样的流程，进入binder_transaction，但是此时reply变成了true:

static void binder_transaction(struct binder_proc *proc,

                   struct binder_thread *thread,

                   struct binder_transaction_data *tr, int reply,

                   binder_size_t extra_buffers_size)

{

    if (reply) {

        in_reply_to = thread->transaction_stack;

        //检查线程

        if (in_reply_to->to_thread != thread) {

            //error

        }

        thread->transaction_stack = in_reply_to->to_parent;

        //获取目标线程

        target_thread = binder_get_txn_from_and_acq_inner(in_reply_to);

        if (target_thread == NULL) {

            //error

        }

        if (target_thread->transaction_stack != in_reply_to) {

            //error

        }

        target_proc = target_thread->proc;

        target_proc->tmp_ref++;

    } else {

        //...

    }

    //获取offset

    off_start_offset = ALIGN(tr->data_size, sizeof(void *));

    buffer_offset = off_start_offset;

    off_end_offset = off_start_offset + tr->offsets_size;

    sg_buf_offset = ALIGN(off_end_offset, sizeof(void *));

    sg_buf_end_offset = sg_buf_offset + extra_buffers_size -

        ALIGN(secctx_sz, sizeof(u64));

    off_min = 0;

    //根据offset来切分data，在这里，我们已经写入了Binder对象，所以会执行一次复制，跟以前一样

    for (buffer_offset = off_start_offset; buffer_offset < off_end_offset;

         buffer_offset += sizeof(binder_size_t)) {

    }

    //唤醒对端

    return;

}

这里获取到了对端，也就是Client端的执行线程，我们接着进入Client端，此时Client端进入读取数据方法，并执行BINDER_WORK_TRANSACTION：

2.9 Client进程-handlePolledCommands

在Client进程收到epoll事件之后，照样与Server进程一样，进行

handlePolledCommands ->

getAndExecuteCommand ->

talkWithDriver ->

executeCommand

但是此次进入binder数据读取

2.10 内核态-binder_thread_read BINDER_WORK_TRANSACTION

static int binder_thread_read(struct binder_proc *proc,

                  struct binder_thread *thread,

                  binder_uintptr_t binder_buffer, size_t size,

                  binder_size_t *consumed, int non_block)

{

    void __user *buffer = (void __user *)(uintptr_t)binder_buffer;

    void __user *ptr = buffer + *consumed;

    void __user *end = buffer + size;

  


    while (1) {

        uint32_t cmd;

        struct binder_transaction_data_secctx tr;

        struct binder_transaction_data *trd = &tr.transaction_data;

        struct binder_work *w = NULL;

        struct list_head *list = NULL;

        struct binder_transaction *t = NULL;

        struct binder_thread *t_from;

        size_t trsize = sizeof(*trd);

       

        //任务出队

        w = binder_dequeue_work_head_ilocked(list);

  


        switch (w->type) {

            case BINDER_WORK_TRANSACTION: {

                //根据binder_work获取binder_transaction

                t = container_of(w, struct binder_transaction, work);

            } break;

        }

        //此次target_node为0，cmd变为BR_REPLY

        if (t->buffer->target_node) {

            //...

        } else {

            trd->target.ptr = 0;

            trd->cookie = 0;

            cmd = BR_REPLY;

        }

        trd->code = t->code;

        trd->flags = t->flags;

        //写数据

        //将cmd写入用户空间，此时cmd为BR_REPLY

        if (put_user(cmd, (uint32_t __user *)ptr)) {

            //...

        }

        ptr += sizeof(uint32_t);

        //将tr写入用户空间，tr是binder_transaction_data的一层包装

        //binder_transaction_data中包含了用户空间buffer的地址

        if (copy_to_user(ptr, &tr, trsize)) {

            //...

        }

    }

}

这次cmd变成了BR_REPLY，我们再进入Client进程：

2.11 Client进程-BR_REPLY

status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)

{

    uint32_t cmd;

    int32_t err;

  


    while (1) {

        if ((err=talkWithDriver()) < NO_ERROR) break;

        err = mIn.errorCheck();

        if (err < NO_ERROR) break;

        if (mIn.dataAvail() == 0) continue;

        cmd = (uint32_t)mIn.readInt32();

        switch (cmd) {

        case BR_REPLY:

            {

                binder_transaction_data tr;

                //读取数据

                err = mIn.read(&tr, sizeof(tr));

                if (reply) {

                    if ((tr.flags & TF_STATUS_CODE) == 0) {

                        //设置到reply里面

                        reply->ipcSetDataReference(

                            reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),

                            tr.data_size,

                            reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),

                            tr.offsets_size/sizeof(binder_size_t),

                            freeBuffer);

                    } else {

                        //error

                    }

                } else {

                   //...

                }

            }

            goto finish;

        }

    }

  


    return err;

}

2.12 结束

自此，createDisplay进入结束阶段，

sp<IBinder> createDisplay(const String8& displayName, bool secure) override {

    Parcel data, reply;

    data.writeInterfaceToken(ISurfaceComposer::getInterfaceDescriptor());

    status_t status = data.writeString8(displayName);

    if (status) {

        return nullptr;

    }

    //...

    status = remote()->transact(BnSurfaceComposer::CREATE_DISPLAY, data, &reply);

    if (status) {

        return nullptr;

    }

    sp<IBinder> display;

    //读取reply

    status = reply.readNullableStrongBinder(&display);

    if (status) {

        return nullptr;

    }

    return display;

}

将返回的对象从reply中读取出来，并将其变为IBinder对象，然后返回给调用者，createDisplay结束。

图2.1 - 一次binder过程

三、总结

一次Binder调用看起来简单，但是实际上却极为复杂，而且中间牵涉了太多的细节。

我们在这里只是将主流程做了一下分析，在主流程明了之后，我们也就知道Binder到底做了什么样的事情，也不至于对其产生畏惧心理，对其内部更多细节的探究也可以从主干去展开。