|
简单说一下Android的Binder机制，你会怎么回答？ Binder是CS架构的，有对应的协议， 其中定义了众多的命令和数据结构来在不同的进程间传递数据。 在不同的进程间传递数据，是通过驱动的ioctl命令来对数据进行读写操作，也就是说，很多数据是在驱动中交互的。 在Android启动的时候，Zygote进程孵化出第一个子进程叫SystemServer，而在这个进程中，很多系统提供的服务，比如ActivityManagerSerivce, PowerManagerService等，都在此进程中的某一条线程上运行。 而很多用户开发的应用程序，也就是我们常说的APP，基于安全的考虑，在安装到系统中的时候，都会被分配一个独特的UID，运行在一个单独的进程中。 基于Linux的用户安全机制，它们是没有办法直接访问到上述系统服务的。 但是在实际中，App很多时候是需要跟这些系统服务进行通信的，也就是要进行进程间通信。 而Binder机制则是Android系统实现进程间通信（IPC）的机制之一。 —————————————————————————————————————————— Binder机制是怎么实现的呢？ 我觉得，要想知道Binder机制是怎么实现的，首先要知道下面四个概念： Server Client ServiceManager Binder驱动 Server和Client无需多说，我们只需要知道一个是用来提供服务的，一个是获取服务的，并且分别运行在不同的进程当中。 那么ServiceManager是用来干什么的呢？ 在前面一篇文章，关于Android的启动过程中，我们有提到，ServiceManager是和Zygote进程一样，是Android系统的守护进程之一。 它的主要作用，就是帮助系统去维护众多的Service列表，所以叫Service Manager。 它就像个电话本，你要打电话给某个人问点事情（想要获取某种Service），但是你没有这个人的电话（不知道Service的访问点，只知道名字），于是你先找到电话本（ServiceManager），在电话本上找到这个人的电话（通过名字找到电话），然后你才能打电话给他（开始获取Service）。 我们知道，ServiceManager，也是一个单独的进程。要找到ServiceManager，本身也要涉及到进程间通信啊，不是吗？ 是的。 从Client和Server的角度来看，ServiceManager永远都是一个Server，任何访问ServiceManager的都是Client。 我们先想一想，ServiceManager本身就是一个进程，那为什么这个进程就能够成为ServiceManager呢？ ——————————————————————————————————————————————— 在Android启动ServiceManager进程的时候，都做了什么事？ 首先打开“/dev/binder”设备文件，映射内存 利用BINDER_SET_CONTEXT_MGR命令，令自己成为上下文管理者，其实也就是成为ServiceManager。 进入一个无限循环，等待Client的请求到来。 所以，是通过Binder驱动，通过命令"BINDER_SET_CONTEXT_MGR"，让某个进程成为ServiceManager的。 ——————————————————————————————————————————————— Binder驱动是用来干什么的？ Binder驱动其实跟硬件没有什么关系，它就是一段运行在内核空间的代码，通过一个叫"/dev/binder"的文件在内核空间和用户空间来回搬数据。 它是整个Binder机制的核心。正是通过它，Binder才能实现进程间的通信。 因为Server, Client和ServiceManager是运行在用户空间，不同的进程，彼此是不能互相访问的。 那么在不同的进程间，要进行数据的传递，只有通过内核空间来传递数据， 而只有Binder驱动是工作在内核空间中的。 它负责Binder节点的建立，负责Binder在进程间的传递，负责对Binder引用的计数管理，在不同进程间传输数据包等底层操作。 整个进程间通信的大部分工作都是通过 open(), mmap()和 ioctl()等文件操作，在内核空间与用户空间中进进出出，来实现的。 面试官接着问，那"BINDER_SET_CONTEXT_MGR"又是怎么回事？ 是这样的。 ServiceManager进程启动的时候，此时它还不是ServiceManager呢。 不过，当它打开了/dev/binder文件，将BINDER_SET_CONTEXT_MGR命令传给Binder驱动的时候，Binder驱动就会为其在内核空间中创建一个节点（binder_node）， 这个节点就是binder_context_mgr_node，也就是ServiceManager的Binder实体。 而这个节点所在的进程，就是ServiceManager。 ——————————————————————————————————————————————— Binder的机制是怎么实现的呢，先简单地说一下？ 通过上面的简单描述，我们可以这样认为，每一个提供服务的Server都会通过Binder驱动，将自身给注册到ServiceManager中，方便众多想获取服务的Client可以去ServiceManager找到自己。 那么，这些Service都会经过内核空间的Binder驱动，其实这个"经过"的说法，本质上，就是Server们会将自身作为一个对象，封装在数据包中，将这些数据复制到内核空间中，由Binder驱动访问。 而Binder驱动读取数据包的时候，如果发现其中有Binder实体，类似ServiceManager那样的服务提供商，那么也会为对应的Binder实体创建对应的Binder节点（BinderNode）。 这些节点位于Server所属的进程内。 Binder驱动也会为这些服务分配句柄（大于0），同时会将这些句柄也记录在Binder驱动中，然后再将这些句柄和名字发送给ServiceManager，由ServiceManager来维护。 也就是说，Server们通过和Binder驱动通信，Binder驱动做了如下两件事： 在内核空间中创建了一个Binder节点，隶属于Server们的进程。 驱动为这些Binder节点分配一个大于0的包柄，将这些句柄和名字发送给ServiceManager。 ——————————————————————————————————————————————— Client们是怎么和Binder驱动通信的呢？ 很显然，无论如何，Client得知道要跟谁通信，它们知道一个名字。 所以， 它们就会把想要获取服务的名字，加上一个句柄为 0 的值，封装为一个数据包，打开Binder设备文件，将这个数据发送给Binder驱动。 Binder驱动接收到句柄为0，就会将这数据包扔给ServiceManager。 ServiceManager接收到这个数据包，就会分析，发现是要找某个名字的服务，于是就找找找，然后将对应服务的句柄发送回来（某大于0的句柄）。 驱动再将这个句柄发回给Client。 Client获取句柄之后，就会再加上想要的服务，还有这个句柄，再发送给Binder驱动，Binder驱动就会找到对应的句柄 ——————————————————————————————————————————————— Binder通信过程 Server启动了，他要创建一个Binder实体，它的句柄是0，比如BpBinder(0)，当设置了BINDER_SET_CONTEXT_MGR，驱动收到这个命令，它就知道是要将当前进程设置为ServiceManager，于是它就会当前这个Binder实体创建一个Binder节点（BinderNode），它在这里记录了 0 -> ServiceManager这样的mapping。 另一个Server启动了，它也会创建一个Binder实体，名字叫 XXXManagerService吧，但是它的句柄就不会是0了，是什么呢？不知道，当它这个Binder实体放到驱动中，驱动同时也会为其创建一个Binder节点，并且为其随机创建一个句柄，比如就叫 1 吧。 于是我们就知道在驱动中, 1 -> XXXManagerService的引用。 它进入驱动是为了寻找句柄0，去注册自己，也就是addService。 当然，驱动就会找到句柄0，发现其对应的是ServiceManager，就会将对应的数据，让ServiceManager来进行处理，这当然利用的就是内核空间的内存了。 在ServiceManager中，有一个服务列表svclist，保存了不同的服务名称对应的句柄，比如ServiceManager就会在自己的空间中保存这样一个对应 1- > “XXXManagerService”。 OK，到这里，XXXManagerService就将自己注册到ServiceManager中了。 有一个Client也启动了，它要找XXXManagerService请求点资源，但是它只知道XXXManagerService的名字，而不知道其具体的句柄，不同进程之间，咫尺就是天涯啊。但是它知道有个叫ServiceManager的东西，它可能知道XXXManagerService在哪里，刚好，它知道它句柄就是0，于是它就去驱动中找一个句柄为0的，找到了，跟他通信，说它要找XXXManagerService，也就是findService。 刚好XXXManagerService注册了，ServiceManager就将其句柄传给了Client，现在Client终于知道XXXManagerService的地址（句柄）了，于是它就又重新包装好数据，这次的句柄就不是0了，而是 1 了，又一头扎进驱动了，继续做该做的事情。 原文链接：https://blog.csdn.net/wojiushiwn0331/article/details/89552909 |
|
|
