开发者俱乐部

标题: 干货：彻底理解ANDROID BINDER通信架构（下） [打印本页]

作者: xman 时间: 2016-11-29 05:40
标题: 干货：彻底理解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()方法.
　　三、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_size0，但此时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。

　　主要功能:
　　查询目标进程的过程： handle  binder_ref  binder_node  binder_proc
　　将BINDER_WORK_TRANSACTION添加到目标队列target_list，首次发起事务则目标队列为target_proc-todo，  reply事务时则为target_thread-todo;  oneway的非reply事务，则为target_node-async_todo.
　　将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 何去何从
　　执行完binder_thread_write方法后，  通过binder_transaction()首先写入BINDER_WORK_TRANSACTION_COMPLETE写入当前线程.
　　这时bwr.read_size  0，回到binder_ioctl_write_read方法，  便开始执行binder_thread_read();
　　在binder_thread_read()方法，将获取cmd=BR_TRANSACTION_COMPLETE，再将cmd和数据写回用户空间;
　　一次Binder_ioctl完成，接着回调用户空间方法talkWithDriver()，并且刚才的数据写入mIn.
　　这时mIn有可读数据，回到waitForResponse()方法，完成BR_TRANSACTION_COMPLETE过程.
　　再回退到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系列7framework层分析文章中的第二节初始化的过程.
　　另外，此处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)来完成.整个过程如下:
　　你把信交给邮寄员(BC_TRANSACTION);
　　邮寄员收到信后，填一张单子给你作为一份回执(BR_TRANSACTION_COMPLETE). 这样你才放心知道邮递员已确定接收信，  否则就这样走了，信到底有没有交到邮递员手里都不知道，这样的通信实在太让人不省心，长时间收不到远方家人的回信，  无法得知是在路的中途信件丢失呢，还是压根就没有交到邮递员的手里. 所以说oneway也得知道信是投递状态是否成功.
　　邮递员利用交通工具(Binder  Driver)，将信交给了你的家人(BR_TRANSACTION);当你收到回执(BR_TRANSACTION_COMPLETE)时心里也不期待家人回信，  那么这便是一次oneway的通信过程.
　　如果你希望家人回信，那便是非oneway的过程，在上述步骤2后并不是直接返回，而是继续等待着收到家人的回信，经历前3个步骤之后继续执行:
　　家人收到信后，立马写了个回信交给邮递员BC_REPLY;
　　同样，邮递员要写一个回执(BR_TRANSACTION_COMPLETE)给你家人;
　　邮递员再次利用交通工具(Binder Driver)，将回信成功交到你的手上(BR_REPLY)这便是一次完成的非oneway通信过程.
　　oneway与非oneway: 都是需要等待Binder Driver的回应消息BR_TRANSACTION_COMPLETE.  主要区别在于oneway的通信收到BR_TRANSACTION_COMPLETE则返回，而不会再等待BR_REPLY消息的到来.

欢迎光临开发者俱乐部 (http://xodn.com/)