干货 | 完全理解ANDROID BINDER通讯架构（下）

干货 | 完全理解ANDROID BINDER通讯架构（下）

2.10 IPC.waitForResponse

在这个过程当中, 常见的几个BR_命令:

• BR_TRANSACTION_COMPLETE: binder驱动收到BC_TRANSACTION事件后的应答消息; 对于oneway transaction,当收到该消息,则完成了本次Binder通讯;

• BR_DEAD_REPLY: 回复失败，每每是线程或节点为空. 则结束本次通讯Binder;

• BR_FAILED_REPLY:回复失败，每每是transaction出错致使. 则结束本次通讯Binder;

• BR_REPLY: Binder驱动向Client端发送回应消息; 对于非oneway transaction时,当收到该消息,则完整地完成本次Binder通讯;

规律: BC_TRANSACTION + BC_REPLY = BR_TRANSACTION_COMPLETE + BR_DEAD_REPLY + BR_FAILED_REPLY

2.10.1 IPC.executeCommand

处于剩余的BR_命令.

2.11 IPC.talkWithDriver

binder_write_read结构体用来与Binder设备交换数据的结构, 经过ioctl与mDriverFD通讯，是真正与Binder驱动进行数据读写交互的过程。 ioctl()方法通过syscall最终调用到Binder_ioctl()方法.

3、Binder driver

3.1 binder_ioctl

[→ Binder.c]

由【小节2.11】传递过出来的参数 cmd=BINDER_WRITE_READ

首先,根据传递过来的文件句柄指针获取相应的binder_proc结构体, 再从中查找binder_thread,若是当前线程已经加入到proc的线程队列则直接返回，若是不存在则建立binder_thread，并将当前线程添加到当前的proc.

• 当返回值为-ENOMEM，则意味着内存不足，每每会出现建立binder_thread对象失败;

• 当返回值为-EINVAL，则意味着CMD命令参数无效；

3.2 binder_ioctl_write_read

此时arg是一个binder_write_read结构体，mOut数据保存在write_buffer，因此write_size>0，但此时read_size=0。首先,将用户空间bwr结构体拷贝到内核空间,而后执行binder_thread_write()操做.

3.3 binder_thread_write

不断从binder_buffer所指向的地址获取cmd, 当只有BC_TRANSACTION或者BC_REPLY时, 则调用binder_transaction()来处理事务.

3.4 binder_transaction

发送的是BC_TRANSACTION时，此时reply=0。

主要功能:

1. 查询目标进程的过程： handle → binder_ref → binder_node → binder_proc

2. 将BINDER_WORK_TRANSACTION添加到目标队列target_list, 首次发起事务则目标队列为target_proc->todo, reply事务时则为target_thread->todo; oneway的非reply事务,则为target_node->async_todo.

3. 将BINDER_WORK_TRANSACTION_COMPLETE添加到当前线程的todo队列

此时当前线程的todo队列已经有事务, 接下来便会进入binder_thread_read（）来处理相关的事务.

3.5 binder_thread_read

• 当收到的是BINDER_WORK_TRANSACTION_COMPLETE, 则将命令BR_TRANSACTION_COMPLETE写回用户空间.

• 当收到的是BINDER_WORK_TRANSACTION命令, 则将命令BR_TRANSACTION或BR_TRANSACTION写回用户空间.

四. 回到用户空间

4.1 何去何从

1. 执行完binder_thread_write方法后, 经过binder_transaction()首先写入BINDER_WORK_TRANSACTION_COMPLETE写入当前线程.

2. 这时bwr.read_size > 0, 回到binder_ioctl_write_read方法, 便开始执行binder_thread_read();

3. 在binder_thread_read()方法, 将获取cmd=BR_TRANSACTION_COMPLETE, 再将cmd和数据写回用户空间;

4. 一次Binder_ioctl完成,接着回调用户空间方法talkWithDriver(),而且刚才的数据写入mIn.

5. 这时mIn有可读数据, 回到waitForResponse()方法,完成BR_TRANSACTION_COMPLETE过程.

6. 再回退到transact()方法, 对于oneway的操做, 此次Binder通讯便完成, 不然仍是要等待Binder服务端的返回.

对于startService过程, 显然没有指定oneway的方式,那么发起者进程还会继续停留在waitForResponse()方法,等待收到BR_REPLY消息. 因为在前面binder_transaction过程当中,除了向本身所在线程写入了BINDER_WORK_TRANSACTION_COMPLETE, 还向目标进程(此处为system_server)写入了BINDER_WORK_TRANSACTION命令. 而此时system_server进程的binder线程一旦空闲即是停留在binder_thread_read()方法来处理进程/线程新的事务, 收到的是BINDER_WORK_TRANSACTION命令, 通过binder_thread_read()后生成命令BR_TRANSACTION.一样的流程.

接下来,从system_server的binder线程一直的执行流: IPC.joinThreadPool –> IPC.getAndExecuteCommand() → IPC.talkWithDriver() ,但talkWithDriver收到事务以后, 便进入IPC.executeCommand(), 接下来,从executeCommand提及.

4.2 IPC.executeCommand

• 对于oneway的场景, 则到此所有结束.

• 对于非oneway, 也就是须要reply的通讯过程,则向Binder驱动发送BC_REPLY命令

4.3 BBinder.transact

[→ Binder.cpp ::BBinder ]

4.4 JavaBBinder.onTransact

[→ android_util_Binder.cpp]

还记得AndroidRuntime::startReg过程吗, 其中有一个过程即是register_android_os_Binder(),该过程会把gBinderOffsets.mExecTransact即是Binder.java中的execTransact()方法.详见见Binder系列7—framework层分析文章中的第二节初始化的过程.

另外,此处mObject是在服务注册addService过程,会调用writeStrongBinder方法, 将Binder对象传入了JavaBBinder构造函数的参数, 最终赋值给mObject. 在本次通讯过程当中Object为ActivityManagerNative对象.

此处斗转星移, 从C++代码回到了Java代码. 进入AMN.execTransact, 因为AMN继续于Binder对象, 接下来进入Binder.execTransact

4.5 Binder.execTransact

[Binder.java]

当发生RemoteException, RuntimeException, OutOfMemoryError, 对于非oneway的状况下都会把异常传递给调用者.

4.6 AMN.onTransact

[→ ActivityManagerNative.java]

4.7 AMS.startService

历经千山万水, 总算是进入了AMS.startService. 当system_server收到BR_TRANSACTION的过程后, 再经历一个相似的过程,将事件告知app所在进程service启动完成.过程基本一致,此处就再也不展开.

五. 总结

本文详细地介绍如何从AMP.startService是如何经过Binder一步步调用进入到system_server进程的AMS.startService. 整个过程涉及Java framework, native, kernel driver各个层面知识. 仅仅一个Binder IPC调用, 就花费了如此大篇幅来说解, 可见系统之庞大. 整个过程的调用流程:

5.1 通讯流程

从通讯流程角度来看整个过程:

前面第二至第四段落,主要讲解过程 BC_TRANSACTION –> BR_TRANSACTION_COMPLETE –> BR_TRANSACTION.有兴趣的同窗能够再看看后面3个事务的处理:BC_REPLY –> BR_TRANSACTION_COMPLETE –> BR_REPLY,这两个流程基本是一致的.

5.2 通讯协议

从通讯协议的角度来看这个过程:

• Binder客户端或者服务端向Binder Driver发送的命令都是以BC开头,例如本文的BC_TRANSACTION和BC_REPLY, 全部Binder Driver向Binder客户端或者服务端发送的命令则都是以BR开头, 例如本文中的BR_TRANSACTION和BR_REPLY.

• 只有当BC_TRANSACTION或者BC_REPLY时, 才调用binder_transaction()来处理事务. 而且都会回应调用者一个BINDER_WORK_TRANSACTION_COMPLETE事务, 通过binder_thread_read()会转变成BR_TRANSACTION_COMPLETE.

• startService过程即是一个非oneway的过程, 那么oneway的通讯过程以下所述.

5.3 说一说oneway

上图是非oneway通讯过程的协议图, 下图则是对于oneway场景下的通讯协议图:

到BR_TRANSACTION_COMPLETE则程序返回,有人可能以为好奇,为什么oneway怎么还要等待回应消息? 我举个例子,你就明白了.

你(app进程)要给远方的家人(system_server进程)邮寄一封信(transaction), 你须要经过邮寄员(Binder Driver)来完成.整个过程以下:

1. 你把信交给邮寄员(BC_TRANSACTION);

2. 邮寄员收到信后, 填一张单子给你做为一份回执(BR_TRANSACTION_COMPLETE). 这样你才放心知道邮递员已肯定接收信, 不然就这样走了,信到底有没有交到邮递员手里都不知道,这样的通讯实在太让人不省心, 长时间收不到远方家人的回信, 没法得知是在路的中途信件丢失呢,仍是压根就没有交到邮递员的手里. 因此说oneway也得知道信是投递状态是否成功.

3. 邮递员利用交通工具(Binder Driver),将信交给了你的家人(BR_TRANSACTION);

当你收到回执(BR_TRANSACTION_COMPLETE)时内心也不期待家人回信, 那么这即是一次oneway的通讯过程.

若是你但愿家人回信, 那即是非oneway的过程,在上述步骤2后并非直接返回,而是继续等待着收到家人的回信, 经历前3个步骤以后继续执行:

1. 家人收到信后, 立马写了个回信交给邮递员BC_REPLY;

2. 一样,邮递员要写一个回执(BR_TRANSACTION_COMPLETE)给你家人;

3. 邮递员再次利用交通工具(Binder Driver), 将回信成功交到你的手上(BR_REPLY)

这即是一次完成的非oneway通讯过程.

oneway与非oneway: 都是须要等待Binder Driver的回应消息BR_TRANSACTION_COMPLETE. 主要区别在于oneway的通讯收到BR_TRANSACTION_COMPLETE则返回,而不会再等待BR_REPLY消息的到来.

想了解更多？

那就赶忙来关注咱们

小米开放平台公众号

小米开放平台官方地址：

http://dev.xiaomi.com?hmsr=%E5%BC%80%E6%BA%90%E4%B8%AD%E5%9B%BD%E5%8D%9A%E5%AE%A2%E9%A2%91%E9%81%93&hmpl=&hmcu=&hmkw=&hmci=

小米开放平台官方交流群：398616987