这篇文章主要介绍“ANDROID BINDER通信架构怎么掌握”，在日常操作中，相信很多人在ANDROID BINDER通信架构怎么掌握问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”ANDROID BINDER通信架构怎么掌握”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
创新互联公司长期为上1000家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为峨边彝族企业提供专业的成都网站建设、网站设计，峨边彝族网站改版等技术服务。拥有10年丰富建站经验和众多成功案例,为您定制开发。
在这个过程中, 常见的几个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
处于剩余的BR_命令.
binder_write_read结构体用来与Binder设备交换数据的结构, 通过ioctl与mDriverFD通信，是真正与Binder驱动进行数据读写交互的过程。 ioctl()方法经过syscall最终调用到Binder_ioctl()方法.
[→ Binder.c]
由【小节2.11】传递过出来的参数 cmd=BINDER_WRITE_READ
首先,根据传递过来的文件句柄指针获取相应的binder_proc结构体, 再从中查找binder_thread,如果当前线程已经加入到proc的线程队列则直接返回，如果不存在则创建binder_thread，并将当前线程添加到当前的proc.
当返回值为-ENOMEM，则意味着内存不足，往往会出现创建binder_thread对象失败;
当返回值为-EINVAL，则意味着CMD命令参数无效；
此时arg是一个binder_write_read结构体，mOut数据保存在write_buffer，所以write_size>0，但此时read_size=0。首先,将用户空间bwr结构体拷贝到内核空间,然后执行binder_thread_write()操作.
不断从binder_buffer所指向的地址获取cmd, 当只有BC_TRANSACTION或者BC_REPLY时, 则调用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（）来处理相关的事务.
当收到的是BINDER_WORK_TRANSACTION_COMPLETE, 则将命令BR_TRANSACTION_COMPLETE写回用户空间.
当收到的是BINDER_WORK_TRANSACTION命令, 则将命令BR_TRANSACTION或BR_TRANSACTION写回用户空间.
执行完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说起.
对于oneway的场景, 则到此全部结束.
对于非oneway, 也就是需要reply的通信过程,则向Binder驱动发送BC_REPLY命令
[→ 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
[Binder.java]
当发生RemoteException, RuntimeException, OutOfMemoryError, 对于非oneway的情况下都会把异常传递给调用者.
[→ ActivityManagerNative.java]
4.7 AMS.startService
历经千山万水, 总算是进入了AMS.startService. 当system_server收到BR_TRANSACTION的过程后, 再经历一个类似的过程,将事件告知app所在进程service启动完成.过程基本一致,此处就不再展开.
到此，关于“ANDROID BINDER通信架构怎么掌握”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！
