Android Binder 通信原理图文详解

来自:网络
时间:2022-12-26
阅读:
目录

前言

Binder机制可谓是Android 知识体系里的重中之重,作为偏底层的基础组件,平时我们很少关注它,而它却是无处不在,也是Android 面试易考察的点之一。网上很多文章,要么知识点比较陈旧,要么源码贴一堆,要么没有成体系地分析,导致读者一知半解,似是而非。
本篇将从流程上将Binder通信过一遍,尽量多用图展示。
通过本篇文章,你将了解到:

Binder的作用

进程与Binder驱动如何通信

ServiceManager进程的作用

进程添加服务到ServiceManager的流程

进程从ServiceManager获取服务的流程

Binder服务端数据接收

Binder 通信全流程图

1. Binder的作用

先看Linux下进程地址映射关系:

Android Binder 通信原理图文详解

我们知道,对象调用本身就是地址空间的访问。

如上,进程之间各自访问各自的内存地址,它们之间无法直接访问对方的地址,也就是说微信不能直接调用支付宝提供的接口。而内核具有访问其它进程地址空间的权限,因此微信可以将消息发送给内核,让内核帮忙转发给支付宝,这种方式叫做:存储/转发方式。

由此衍生的几种IPC(进程间通信)如:管道、消息队列、socket等,而Android 上采用了新的机制:

Binder,相比传统的方式,Binder只需要一次数据拷贝,并且Binder更安全。

Binder机制是Android 里用来做IPC的主要方式。

2. 进程与Binder驱动如何通信

既然得要内核进行消息中转,那么Binder驱动得运行在内核空间,而事实上也确实如此,Binder驱动加载后在内核空间运行,进程只需要和Binder驱动取得联系,通过Binder驱动联系另一个进程,那么一次消息的传送过程就可以实现了。

Android Binder 通信原理图文详解

内核提供提供一系列的系统调用接口给用户进程使用,当用户进程想要访问内核时,只需要调用对应的接口,此时代码就会从用户空间切换到内核空间执行。

常见的系统调用函数如:open/read/write/ioctl/close/mmap/fork 等。

与Binder驱动通信分两步:

打开Binder驱动:open("/dev/binder", O_RDWR | O_CLOEXEC)

通过ioctl 与Binder驱动进行数据通信:ioctl(mDriverFD, BINDER_WRITE_READ, &bwr)
bwr 为读写数据结构

3. ServiceManager进程的作用

Binder Client、Binder Server、ServiceManager关系

为方便起见,ServiceManager简称SM。

Binder 设计为C/S架构,C为Client(客户端),S为Server(服务端),Server端提供接口(服务)给Client端使用,而这个服务是以Binder引用的形式提供的。

由之前的知识可知,C和S是不同的进程,那么C如何拿到S的Binder引用呢?

你可能会说,当然是SM了,S先将Binder引用存放在SM里,当C需要的时候向SM查询即可。

这么看似乎讲得通了,那问题又来了,SM也是一个单独的进程,那S、C如何与SM进行通信呢?这就陷入了先有鸡还是先有蛋的死循环了。

实际上C、S、SM之间都是依靠Binder通信,只是SM作为特殊的Binder(handle=0)提前放入了Binder驱动里,当C、S想要获取SM的Binder引用,只需要获取handle=0的Binder即可。

这么说没有太直观的印象,我们一步步剖析。

ServiceManager注册进Binder

Android Binder 通信原理图文详解

SM 注册进Binder驱动后就会等待来自Binder驱动的消息,这里列出了两个最常见的处理消息的Case:

其它进程添加服务到SM里

其它进程向SM查询服务

SM里维护着一个链表,链表的元素是结构体:

Android Binder 通信原理图文详解

主要记录的是name和handle字段。
当SM收到添加服务的指令后,从Binder驱动里取出handle和name,并构造结构体插入到链表。
当SM收到查询服务的指令后,从Binder驱动里取出name,并找到链表里相同的name,找到后取出handle,最后写入到Binder驱动。

4. 进程添加服务到ServiceManager的流程

其它进程找到SM

现在SM已经翘首以盼其它进程的请求了,接着来看看如何添加一个服务到SM里。
以Java层添加服务为例,我们选择振动服务作为切入点分析。

Android Binder 通信原理图文详解

在system_server 进程里构造振动服务(VibratorService继承自Binder),并添加到SM里。

Android Binder 通信原理图文详解

可以看出,分两步:

先找到ServiceManager

往ServiceManager里添加服务

getIServiceManager()继续往下:

Android Binder 通信原理图文详解

BinderInternal.getContextObject() 是native方法,后续流程较多,我们用图表示。

Android Binder 通信原理图文详解

寻找ServiceManager的过程涉及到Java层和Native层,主要的重点在Native层查找 ServiceManager对应的BpBinder对象,没有找到的话则创建新的并存入缓存里以备下次直接获取。

ProcessState里维护了一个单例,每个进程只有一个ProcessState对象,创建ProcessState时候就会去打开Binder驱动,同时会设置Binder线程池里线程个数等其它参数

Native层构造BpBinder(handle=0表示该BpBinder是ServiceManager在客户端的引用),再构造BinderProxyNativeData持有BpBinder。

构造BinderProxy对象并持有BinderProxyNativeData,也就是间接持有BpBinder

最后构造了ServiceManagerProxy对象,它实现了IServiceManager接口,它的成员变量mRemote指向了BinderProxy

可以看出,获取ServiceManager的过程并不是真正去获取ServiceManager的Binder对象,而是获取它在当前进程的代理:BpBinder

添加服务到ServiceManager

既然找到了SM的Binder代理,接下来看看如何使用它给SM添加服务。

    #ServiceManagerNative.ServiceManagerProxy
    public void addService(String name, IBinder service, boolean allowIsolated, int dumpPriority)
            throws RemoteException {
        //构造Parcel
        Parcel data = Parcel.obtain();
        Parcel reply = Parcel.obtain();
        data.writeInterfaceToken(IServiceManager.descriptor);
        data.writeString(name);
        //写入Binder
        data.writeStrongBinder(service);
        data.writeInt(allowIsolated ? 1 : 0);
        data.writeInt(dumpPriority);
        //通过BinderProxy发送
        mRemote.transact(ADD_SERVICE_TRANSACTION, data, reply, 0);
        reply.recycle();
        data.recycle();
    }

Android Binder 通信原理图文详解

其中IPCThreadState与线程相关,不同的线程会维护一个单例。

由此可见,最终还是通过BpBinder发送消息,进而发送到Binder驱动。

此时驱动收到的信息包括不限于:

服务的名字

ServiceManager的handle

BBinder对象指针

驱动建立服务handle和BBinder对象指针的映射关系,并将服务的名字和服务的handle传递给ServiceManager(通过ServiceManager handle查找)。

ServiceManager拿到消息后建立映射关系,等待其它进程的请求。

至此,进程添加服务到ServiceManager过程已经分析完毕,用图表示如下:

Android Binder 通信原理图文详解

BBinder作用

Java层传递的是Binder对象,如何与Native的BBinder关联起来呢?
重点在:

Parcel.writeStrongBinder(Binder)

Android Binder 通信原理图文详解

也即是说Server端的Java Binder对象在Native层的代表是BBinder。
Binder驱动记录了BBinder的地址,当有消息过来时通过找到BBinder对象进而找到Java层的Binder对象,最终调用Binder.onTransact()。

5. 进程从ServiceManager获取服务的流程

其它进程找到SM

振动服务添加完成后,某些进程想要获取振动服务进行振动,比如微信收到消息后需要振动用以提示用户。
接着来看看如何获取振动服务。

    private void vibrate() {
        //获取振动服务
        Vibrator vibrator = (Vibrator)getSystemService(Context.VIBRATOR_SERVICE);
        //开始振动
        vibrator.vibrate(1000);
    }

与添加服务类似,想要获取服务先要找到SM,找SM的过程上边分析过了,此处不再细说。

从ServiceManager获取服务

    #ServiceManagerNative.ServiceManagerProxy
    public IBinder getService(String name) throws RemoteException {
        //构造Parcel
        Parcel data = Parcel.obtain();
        Parcel reply = Parcel.obtain();
        data.writeInterfaceToken(IServiceManager.descriptor);
        //写入名字
        data.writeString(name);
        //通过BinderProxy发送
        mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
        IBinder binder = reply.readStrongBinder();
        reply.recycle();
        data.recycle();
        return binder;
    }

Android Binder 通信原理图文详解

由此可见,最终还是通过BpBinder发送消息,进而发送到Binder驱动。
此时驱动收到的信息包括不限于:

服务的名字

ServiceManager的handle

Binder驱动收到消息后,找到SM,并将服务的名字传给SM,SM从自己维护的链表里找到服务名相同的节点,最终取出该服务的handle,发送给Binder驱动。

用图表示如下:

Android Binder 通信原理图文详解

对比添加服务流程和获取服务流程,两者前半部分都很相似,都是先拿到SM的BpBinder引用,然后写入驱动,最后由SM进程处理。只是对于获取服务流程来说,还需要将查询的结果(handle)写入驱动返回给调用方(对应图上红色部分)。

到这,大家可能会有疑惑了:"handle是整形值,而微信获取的振动服务是一个Binder对象,这两者是怎么结合起来的呢?"

handle转换为Binder对象

handle表示的即是Binder服务端在客户端的索引句柄,只要客户端拿到了handle,它就能通过Binder驱动调用到服务端。

        mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
        IBinder binder = reply.readStrongBinder();

再回过头看看获取服务的代码,当微信进程将查询命令发给Binder驱动后就等待驱动回复的结果,SM查询到结果后将handle写入驱动,而后微信进程从驱动将结果读出并将结果存入reply字段。
最后通过reply拿到Binder引用,也就是说重点在reply.readStrongBinder()方法。
直接看图:

Android Binder 通信原理图文详解

如上,通过驱动返回的handle构造BpBinder,最终封装为Java层的BinderProxy。

至此,获取服务流程就结束了,用图展示简化的流程

Android Binder 通信原理图文详解

6. Binder服务端数据接收

微信进程拿到振动服务(在system_server进程里)的Binder(BinderProxy)后,就可以调用振动方法了,而后指令发送给驱动,驱动通过振动服务的handle找到对应的服务BBinder指针,从而调用服务的接收方法。
微信进程发送指令给Binder驱动前面已经分析过,重点来看看system_server进程是如何接收并处理指令的。

Android Binder 通信原理图文详解

system_server进程启动的时候就会开启Binder线程池,并等待驱动数据到来。
当system_server进程添加振动服务到SM时,会将Java层的Binder转为Native层的BBinder,并将BBinder对象指针写入Binder驱动。
当微信进程调用system_server接口时:

微信进程调用BpBinder.transact()将handle和数据写入Binder驱动

Binder驱动根据handle找到system_server进程

system_server进程从驱动拿到数据,并取出BBinder指针,最终调用到system_server进程Java层的Binder.onTransact()

如此一来,微信成功调用了振动服务,也就是说一次Client到Server端的通信就完成了。

7. Binder 通信全流程图

纵观Binder机制设计,最核心的点是handle。

通过handle构造Client端的BpBinder(Native层),与此对应的是Java层的BinderProxy

通过handle,驱动找到Server端进程,进而调用BBinder(Native层),与此对应的是Java层的Binder

通过handle的一系列中转,Client.transact()成功调用了Server.onTransact(),一次Binder通信就过程就完成了

最后,用一张图总结Binder机制的全过程:

Android Binder 通信原理图文详解

以上就是整个Binder机制的梳理过程,此间省略了Binder驱动里的映射逻辑,可以将Binder驱动当做一个黑盒,而更重要的是Binder客户端和服务端是如何进行映射的。
Binder流程比较绕,尤其是IPCThreadStsate作为客户端的发送和服务端的数据接收的实体,需要区分不同的场景。
当然,jni基础知识必不可少。

本文基于Android 10

以上就是Android Binder 通信原理图文详解的详细内容,更多关于Android Binder 通信原理的资料请关注其它相关文章!

返回顶部
顶部