说说你对Binder的理解

发表于   |   分类于

说说你对Binder的理解

在Android开发中，涉及到多进程的通信底层都是依赖Binder IPC机制，所以Binder是Android开发绕不过去的一个知识点。这里我们具体来看一下Binder的实现原理。

为什么要使用Binder？

  1. 性能方面
  2. 安全方面

性能方面

Binder相对于传统的Socket方式，更加高效。Binder数据拷贝只需要一次，相对于传统的管道、消息队列、Socket都需要两次，效率更高，仅次于共享内存方式（一次也不需要）。

安全性方面

这才是真正使用Binder原因的重中之重，因为传统的通信对于双发的身份并没有做出严格的验证，Socket通信地址是客户端手动填入，很容易伪造，而Binder机制从协议本身就支持通信双方做身份校验，大大提升了安全性。

Socket拷贝两次是哪两次？

当应用程序向一个socket传输数据之后，该socket将创建相应的套接字缓存，并将用户数据拷贝到缓存中。当报文在各协议层传达输的过程中，每一导的报文头将插入到用户数据之前。skb为报文头申请了足够的空间，所以避免了由于插入报文头而对报文进行多次拷贝。用户数据只拷贝了两次：一是从用户空间拷贝到内核；二是报文数据从内核拷贝到网络适配器。

Android里的IPC原理是什么？

Android IPC

  1. 每个Android进程，只能运行在自己进程所拥有的虚拟地址空间。对应一个4GB（这个可以配置）的虚拟地址空间，3GB为用户空间，1GB是内核空间。
  2. 用户空间不可共享，内核空间可共享。
  3. 通信时恰恰是利用可共享的内核内存空间完成底层通信的。

Binder通信流程是什么样的？

Binder架构

  • Client进程：使用服务的进程
  • Server进程：提供服务的进程
  • ServiceManager进程：ServiceManager的作用是将字符串形式的Binder名字转化为对该Binder的引用，使得Client能够通过Binder名字获得对Server中Binder实体的引用。
  • Binder驱动：驱动负责进程之间Binder通信的建立，Binder在进程之间的传递，Binder引用计数管理，数据包在进程之间传递和交互等一系列底层支持。
  1. 注册服务（addService）：Server进程要先注册Service到ServiceManager。该过程：Server是客户端，ServiceManager是服务端。
  2. 获取服务（getService）：Client进程
  3. 使用服务：client根据得到的Service建立与Service所在的Server进程通信的通路，然后可以直接与Service交互。该过程：client是客户端，server是服务端。

注意：上述不是彼此之间直接交互的，都是通过Binder驱动进行交互的。Binder驱动位于内核空间，而Client，Server，Service Manager位于用户空间。 对于开发者来说，Binder驱动和Service Manager可以看做是Android平台的基础架构，只需要自定义实现client、Server端，借助Android平台架构可以直接进行IPC通信。

举一个Binder运行的例子？

如下是实现浮动窗口的部分代码：

1
2
3
4
5
6
//获取WindowManager服务引用
WindowManager wm = (WindowManager)getSystemService(getApplication().WINDOW_SERVICE);  
//布局参数layoutParams相关设置略...
View view=LayoutInflater.from(getApplication()).inflate(R.layout.float_layout, null);  
//添加view
wm.addView(view, layoutParams);
  • 注册服务（addService）：在Android开机启动过程中，Android系统会初始化各种Service，并将这些Service向ServiceManager注册，这一步是系统管理的。
  • 获取服务（getService）：通过context中的方法拿到Service的代理对象，然后拿到wm的WindowManager对象的引用
  • 使用服务：通过这个引用向具体的服务端发送请求，服务端执行完毕后返回。调用WindowManager的addView函数，触发的是远程调用，调用时运行在systemServer进程的WindowManager的addView方法。

使用服务的具体执行过程是什么样的？

具体执行过程

  1. client通过获得一个server的代理接口，对server进行调用。
  2. 代理接口中定义的方法与server中定义的方法时一一对应的。
  3. client调用某个代理接口中的方法时，代理接口的方法会将client传递的参数打包成Parcel对象。
  4. 代理接口将Parcel发送给内核中的binder driver。
  5. server会读取binder driver中的请求数据，如果是发送给自己的，解包Parcel对象，处理并将结果返回。
  6. 整个的调用过程是一个同步过程，在server处理的时候，client会block住。因此client调用过程不应在主线程。

Binder通信的整体架构是什么样的？

以startService为例

Binder整体架构

  1. 发起端线程向Binder Driver发起binder ioctl请求后，采用环不断talkWithDriver，此时线程处于阻塞状态，直到收到BR__XXX命令才会结束该过程。
    • BR_TRANSACTION_COMPLETE: oneway模式下,收到该命令则退出
    • BR_REPLY: 非oneway模式下,收到该命令才退出;
    • BR_DEAD_REPLY: 目标进程/线程/binder实体为空, 以及释放正在等待reply的binder thread或者binder buffer;
    • BR_FAILED_REPLY: 情况较多,比如非法handle, 错误事务栈, security, 内存不足, buffer不足, 数据拷贝失败, 节点创建失败, 各种不匹配等问题
    • BR_ACQUIRE_RESULT: 目前未使用的协议;
  2. 左图中waitForResponse收到BR_TRANSACTION_COMPLETE,则直接退出循环, 则没有机会执行executeCommand()方法, 故将其颜色画为灰色. 除以上5种BR_XXX命令, 当收到其他BR命令,则都会执行executeCommand过程.
  3. 目标Binder线程创建后, 便进入joinThreadPool()方法, 采用循环不断地循环执行getAndExecuteCommand()方法, 当bwr的读写buffer都没有数据时,则阻塞在binder_thread_read的wait_event过程. 另外,正常情况下binder线程一旦创建则不会退出.

从通信协议来看startService过程是什么样的？

startService过程

  • Binder客户端或者服务端向Binder Driver发送的命令都是BC_开头的，例如BC_TRANSACTION和BC_REPLY。
  • 只有当BC_TRANSACTION或者BC_REPLY时，才会调用binder_transaction()来处理事物，并且都会回应调用者一个BINDER_WORK_TRANSACTION_COMPLETE事物，经过binder_thread_read()会转变成BR_TRANSACTION_COMPLETE.
  • startService过程是一个非oneway的过程。

一个oneway的通信过程

一个oneway的通信过程

为什么oneway通信还需要等待回应

以寄信举例：

  1. 当把信交给邮寄员(BC_TRANSACTION)
  2. 邮寄员收到信后, 填一张单子给你作为一份回执(BR_TRANSACTION_COMPLETE). 这样你才放心知道邮递员已确定接收信, 否则就这样走了,信到底有没有交到邮递员手里都不知道,这样的通信实在太让人不省心, 长时间收不到远方家人的回信, 无法得知是在路的中途信件丢失呢,还是压根就没有交到邮递员的手里. 所以说oneway也得知道信是投递状态是否成功.
  3. 邮递员利用交通工具(Binder Driver),将信交给了你的家人(BR_TRANSACTION);

oneway与非oneway有什么区别？

oneway与非oneway: 都是需要等待Binder Driver的回应消息BR_TRANSACTION_COMPLETE. 主要区别在于oneway的通信收到BR_TRANSACTION_COMPLETE则返回,而不会再等待BR_REPLY消息的到来. 另外，oneway的binder IPC则接收端无法获取对方的pid.