Binder机制，从Java到C （9. IPC通信过程）

1.一次IPC通信過程的幾個步驟

一次通信过程简单的说有下面5个步骤，第一眼看上去，肯定不知道什么玩意，多看几遍，慢慢看，其实是能理解的。

1. Client将数据封装成Parcel。 （前面已经讲过啦）

2. Client process 发送 BC_TRANSACTION 命令协议到kernel，（Client跟kernel说，我要开始远程通信啦）

kernel找到Service process後，向Client process发送一个BR_TRANSACTION_COMPLETE返回协议，表示通信请求已被接受。（kernel说，准了）

Client处理后，开始等待service的返回结果。（client收到“准了”，然后默默等待，或者也可以干点其他什么事情）

3. kernal同時發送 BR_TRANSACTION 返回协议到Service process，请求service处理。（kernel就去找client要找的人，跟他说，有人在请求你的服务）

4. Service process 处理了 BR_TRANSACTION 返回协议，发送BC_REPLY命令协议到kernel，（server跟kernel说，我做完了，这是结果）

kernel找到client process後，向service发送 BR_TRANSACTION_COMPLETE返回协议，表示返回的通信就结果收到了，（kernel说，结果我收到啦）

service处理后，就开始等待下一个请求。（service做完事情，又默默的等着了）

5 kernel同時发送 BR_REPLY 返回协议到Client process，并将结果返回。（kernel把结果返回给client）
    Client process 处理BR_REPLAY返回协议，获得reply数据，结束通信。（client收到结果，大功告成！）

下面就开始一步步详细的分析每一步的流程，会有一点烦躁

2.一次IPC通信過程的代码流程

Service需要注册到ServiceManager，也就是addService的IPC通信过程：
1.将数据封装成Parcel：
看一下MediaPlayerService的注册代码
./frameworks/av/media/libmediaplayerservice/MediaPlayerService.cpp

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

这个的defaultServiceManager()返回的其实是Service Manager代理对象BpServiceManager,实际上是调用了BpServiceManager的addService。

那就看一下这个addService():

./frameworks/native/libs/binder/IServiceManager.cpp

 class BpServiceManager : public BpInterface<IServiceManager>
 {
 Public:
     …
     virtual status_t addService(const String16& name, const sp<IBinder>& service,
             bool allowIsolated)
     {
         Parcel data, reply;
         data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
         data.writeString16(name); //service的名称
         data.writeStrongBinder(service); //将IBinder object 封装成一个flat_binder_object写进parcel，传递給Binder驱动。
         data.writeInt32(allowIsolated ?  : );
         status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
         return err == NO_ERROR ? reply.readExceptionCode() : err;
     }
     …
 };

Parcel內部有mData和mObjects两个缓冲区
mData：包含整数，字符串或者Binder对象(flat_binder_object)
mObjects：记录了mData中Binder对象的位置。

我们看一下怎么把一个Binder对象写进结构体flat_binder_object的：

writeStrongBinder的实现：
./frameworks/native/libs/binder/Parcel.cpp

 status_t Parcel::writeStrongBinder(const sp<IBinder>& val)
 {
     return flatten_binder(ProcessState::self(), val, this);
 }

 status_t flatten_binder(const sp<ProcessState>& proc,
     const sp<IBinder>& binder, Parcel* out)
 {
     flat_binder_object obj;//定义一个结构体

     obj.flags = 0x7f | FLAT_BINDER_FLAG_ACCEPTS_FDS; //0x7f表示Server线程的优先级不能低于0x7f
     if (binder != NULL) {
         IBinder *local = binder->localBinder();
         if (!local) {
             ...
         } else {//我们要注册MediaPlayerService，传进来的是Binder本地对象
             obj.type = BINDER_TYPE_BINDER; //所以把type写成Binder本地对象
             obj.binder = local->getWeakRefs(); //weekref
             obj.cookie = local; //Binder本地对象local的地址值
         }
     } else {
         ...
     }

     return finish_flatten_binder(binder, obj, out); //将flat_binder_object写到Parcel中。
 }

2.发送和处理BC_TRANSACTION命令协议
 remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
前面说过，这里的remote()是一个BpBinder对象,调用的代码是：

./frameworks/native/libs/binder/BpBinder.cpp

 status_t BpBinder::transact(
     uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
 {
     // Once a binder has died, it will never come back to life.
     if (mAlive) {
         status_t status = IPCThreadState::self()->transact(
             mHandle, code, data, reply, flags);
 //mHandle 是这个Binder代理对象的句柄值，现在Binder代理对象是ServiceManager代理对象，so mHandle = 0；
 //code ：ADD_SERVCIE_TRANSACTION
 //data: 要传递给Binder驱动的通信数据
 //reply: 输出參數，保存通信結果
 //flags：描述是同步还是异步，默认是同步
         if (status == DEAD_OBJECT) mAlive = ;
         return status;
     }

     return DEAD_OBJECT;
 }

下面就要调用transact()了：

.framework/native/libs/binder/IPCThreadState.cpp

 status_t IPCThreadState::transact(int32_t handle,
                                   uint32_t code, const Parcel& data,
                                   Parcel* reply, uint32_t flags)
 {
     status_t err = data.errorCheck();
     ...
     if (err == NO_ERROR) {
         ...
         err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL); （1）
     }
     ...
     if ((flags & TF_ONE_WAY) == ) { //判断是否是同步通信，如果是，reply不为null。
        ...
         if (reply) {
             err = waitForResponse(reply); //发送BC_TRANSACTION命令协议。
         } else {
             ...
         }
        ...
     return err;
 }

 status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
 {
     int32_t cmd;
     int32_t err;

     while () {
         if ((err=talkWithDriver()) < NO_ERROR) break; //循环调用talkWithDriver()和Binder驱动程序交互
         ...
     }
     …
     Return err;
 } 

（1） ： BC_TRANSACTION命令协议后面跟的数据是使用一个struct binder_transaction_data描述的。这里要把parcel写入到这个struct中。这个struct添加到IPCThreadState的成员变量mOut中，表示有命令需要发送。

下面图是mOut里的一条命令的储存格式：

target.handle 就是代表了servicemanager

code  在后面用来区分到底是要调用那个函数

data_size  不用说，就是数据大小

data.ptr.buffer 是存储的数据，有一般数据和binder数据

offsets_size   偏移数组的大小

data.ptr.offsets  binder数据在整个数据中的偏移位置，加上上面偏移数组的大小，就可以知道读出每个binder对象了。

接着看，和Binder驱动开始交互了：

.framework/native/libs/binder/IPCThreadState.cpp

 status_t IPCThreadState::talkWithDriver(bool doReceive) //mIn保存返回协议,mOut保存命令命令
 {
    ...
     binder_write_read bwr; //BC_TRANSACTION是通过IO控制命令BINDER_WRITE_READ发送到Binder驱动的，所以上文中的binder_transaction_data
                                     要写入binder_write_read结构体中。 里面的read_buffer/write_buffer对应mIn/mOut
     const bool needRead = mIn.dataPosition() >= mIn.dataSize();
     const size_t outAvail = (!doReceive || needRead) ? mOut.dataSize() : ;

     bwr.write_size = outAvail;
     bwr.write_buffer = (long unsigned int)mOut.data(); 

     if (doReceive && needRead) {
         bwr.read_size = mIn.dataCapacity();
         bwr.read_buffer = (long unsigned int)mIn.data();
     } else {
         bwr.read_size = ;
         bwr.read_buffer = ;
     }
     ...
     if ((bwr.write_size == ) && (bwr.read_size == )) return NO_ERROR;

     bwr.write_consumed = ;
     bwr.read_consumed = ;
     status_t err;
     do {
        ...
         if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= ) //这里会调用kernel binder module的binder_thread_write()
                                                                             和binder_thread_read()來处理命令和返回結果。
             err = NO_ERROR;
         else
             err = -errno;
       ...
      mOut.remove(, bwr.write_consumed);  //將已经处理的命令移除
      ...
      mIn.setDataSize(bwr.read_consumed);  //将读取出來的返回协议保存在mIn中，在返回到前面的waitForResponse時，就可以解析mIn的內容了。
      mIn.setDataPosition();
 …
 }

上面的 ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0) 。

代码实现是在 .kernel/.../android/binder.c，不再android代码范畴了，就不详细列出了，下面是在kernel里处理的步骤：

------------------------------------------------------------------------------------
1.从参数中读取BC_TRANSACTION命令协议和binder_transaction_data。

2.根据binder_transaction_data中的target.handle找到target Binder实体对象(kernel中记录binder的形式，实体对象是用binder_node记录)。
   根据target Binder实体对象找到Server process。

3.处理数据中的binder对象(flat_binder_object)，凡是传递的binder对象，都会在kernel留下蛛丝马迹。
   如果这个binder对象是在kernel中第一次遇见，那么会为它创建Binder实体对象(binder_node)或者Binder引用对象(binder_ref)。
   如果kernel中可以找到这个binder对象，就获取它。

4.将一个BINDER_WORK_TRANSACTION_COMPLETE工作项添加到Client process(media player)队列中处理。
   同时将一个BINDER_WORK_TRANSACTION工作项添加到Server process(service manager)队列中处理。
   这两个工作项是并行处理的。

5.处理BINDER_WORK_TRANSACTION_COMPLETE工作项，将一个BR_TRANSACTION_COMPLETE返回协议发送到Client process中，把返回协议写到mIn中。
-------------------------------------------------------------------------------------------------------------

现在已经返回到IPCThreadState的talkWithDriver()。又返回到waitForResponse()中,处理BR_TRANSACTION_COMPLETE。
然后开始等待Server process返回结果。

3.发送和处理BR_TRANSACTION返回協議
在前面处理BC_TRANSACTION中，会并行将一个BINDER_WORK_TRANSACTION工作项添加到Server process(service manager)队列中处理。

接着kernel中会处理上面的工作项：

1.kernel根据BINDER_WORK_TRANSACTION工作项，向Server process发送了一个BR_TRANSACTION返回协议。
2.Server process，现在就是servicemanager，被唤醒后，会调用binder_parse()处理返回协议。
3.servicemanager分局参数，判断执行操作SVC_MGR_ADD_SERVICE。调用对应的函數do_add_service(),为要注册的Service创建svcinfo结构提，并添加到全局队列svclist中。以后要查找这个service的时候，就从svclist中找了。

binder_parse()之后的函数在下面的文件中：
./frameworks/base/cmds/servicemanager/binder.c
./frameworks/base/cmds/servicemanager/service_manager.c

4.发送和处理BC_REPLY命令协议

servicemanager进程注册成功后，就会通过IO控制命令BINDER_WRITE_READ将BC_REPLY发送到kernel
/frameworks/base/cmds/servicemanager/binder.c

 int binder_write(struct binder_state *bs, void *data, unsigned len)
 {
     struct binder_write_read bwr;
     int res;
     bwr.write_size = len;
     bwr.write_consumed = ;
     bwr.write_buffer = (unsigned) data;
     bwr.read_size = ;
     bwr.read_consumed = ;
     bwr.read_buffer = ;
     res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);
     if (res < ) {
         fprintf(stderr,"binder_write: ioctl failed (%s)\n",
                 strerror(errno));
     }
     return res;
 }

之后的，都是在Kernel中完成的操作，在kernel中的处理：
1.读取BC_REPLY命令协议。
2.找到target process(现在是Client process)。
3.将一个BINDER_WORK_TRANSACTION_COMPLETE工作项添加到servicemanager process队列中处理。
  同时将一个BINDER_WORK_TRANSACTION工作项添加到Client process队列中处理。
   这两个工作项是并行处理的。
4.处理BINDER_WORK_TRANSACTION_COMPLETE工作项，将一个BR_TRANSACTION_COMPLETE返回协议发送到servicemanager中。

servicemanager处理完BR_TRANSACTION_COMPLETE后，就又开始等待新的进程间通信请求了。

5.发送和处理BR_REPLY返回协议

在前面处理BC_REPLY中，会并行将一个BINDER_WORK_TRANSACTION工作项添加到Client process队列中处理。

接着kernel中会处理上面的工作項：

1.kernel根据BINDER_WORK_TRANSACTION工作項，向Client process發送了一個BR_REPLY返回协议。

Client process返回到IPCThreadState的talkWithDriver(),再回到waitForResponse中处理BR_REPLY。

waitForResponse()中將返回的結果取出，保存在Parcel對象reply中。之後，就跳出循环，結束該方法。Service的註冊過程就執行完了。

Service註冊之後，就会启动Binder thread pool，等待client的請求。
此時Service不是在注册的時候作为Client请求servicemanager的服务了。而是作为Service处理收到的请求。收到请求后会通过executeCommand()來处理。