换个姿势去看Binder 原理，原来如此……

Binder机制可谓是Android 知识体系里的重中之重，作为偏底层的基础组件，平时我们很少关注它，而它却是无处不在，也是Android 面试易考察的点之一。网上很多文章，要么知识点比较陈旧，要么源码贴一堆，要么没有成体系地分析，导致读者一知半解，似是而非。

本篇将从流程上将Binder通信过一遍，尽量多用图展示。

通过本篇文章，你将了解到：

1. Binder的作用
2. 进程与Binder驱动如何通信
3. ServiceManager进程的作用
4. 进程添加服务到ServiceManager的流程
5. 进程从ServiceManager获取服务的流程
6. Binder服务端数据接收
7. Binder 通信全流程图

1. Binder的作用

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

我们知道，对象调用本身就是地址空间的访问。
如上，进程之间各自访问各自的内存地址，它们之间无法直接访问对方的地址，也就是说微信不能直接调用支付宝提供的接口。而内核具有访问其它进程地址空间的权限，因此微信可以将消息发送给内核，让内核帮忙转发给支付宝，这种方式叫做：存储/转发方式。
由此衍生的几种IPC(进程间通信)如：管道、消息队列、socket等，而Android 上采用了新的机制：Binder，相比传统的方式，Binder只需要一次数据拷贝，并且Binder更安全。

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

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

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

内核提供提供一系列的系统调用接口给用户进程使用，当用户进程想要访问内核时，只需要调用对应的接口，此时代码就会从用户空间切换到内核空间执行。
常见的系统调用函数如：open/read/write/ioctl/close/mmap/fork 等。
与Binder驱动通信分两步：

1. 打开Binder驱动：open(“/dev/binder”,O_RDWR | O_CLOEXEC)
2. 通过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

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

1. 其它进程添加服务到SM里
2. 其它进程向SM查询服务

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

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

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

其它进程找到SM

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

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

可以看出，分两步：

1. 先找到ServiceManager
2. 往ServiceManager里添加服务

getIServiceManager()继续往下：

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

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

1. ProcessState里维护了一个单例，每个进程只有一个ProcessState对象，创建ProcessState时候就会去打开Binder驱动，同时会设置Binder线程池里线程个数等其它参数
2. Native层构造BpBinder(handle=0表示该BpBinder是ServiceManager在客户端的引用)，再构造BinderProxyNativeData持有BpBinder。
3. 构造BinderProxy对象并持有BinderProxyNativeData，也就是间接持有BpBinder
4. 最后构造了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();
    }

其中IPCThreadState与线程相关，不同的线程会维护一个单例。
由此可见，最终还是通过BpBinder发送消息，进而发送到Binder驱动。
此时驱动收到的信息包括不限于：

1. 服务的名字
2. ServiceManager的handle
3. BBinder对象指针

驱动建立服务handle和BBinder对象指针的映射关系，并将服务的名字和服务的handle传递给ServiceManager(通过ServiceManager handle查找)。
ServiceManager拿到消息后建立映射关系，等待其它进程的请求。
至此，进程添加服务到ServiceManager过程已经分析完毕，用图表示如下：

BBinder作用

Java层传递的是Binder对象，如何与Native的BBinder关联起来呢？
重点在：

Parcel.writeStrongBinder(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,0);
        IBinder binder = reply.readStrongBinder();
        reply.recycle();
        data.recycle();
        return binder;
    }

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

1. 服务的名字
2. ServiceManager的handle

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

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

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

handle转换为Binder对象

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

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

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

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

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

6. Binder服务端数据接收

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

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

1. 微信进程调用BpBinder.transact()将handle和数据写入Binder驱动
2. Binder驱动根据handle找到system_server进程
3. system_server进程从驱动拿到数据，并取出BBinder指针，最终调用到system_server进程Java层的Binder.onTransact()

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

7. Binder 通信全流程图

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

1. 通过handle构造Client端的BpBinder(Native层)，与此对应的是Java层的BinderProxy
2. 通过handle，驱动找到Server端进程，进而调用BBinder(Native层)，与此对应的是Java层的Binder
3. 通过handle的一系列中转，Client.transact()成功调用了Server.onTransact()，一次Binder通信就过程就完成了

最后，用一张图总结Binder机制的全过程：

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

当然，jni基础知识必不可少。

本文基于Android 10

限于篇幅并没有一步步列出源码，对源码细节有疑惑之处欢迎留言讨论。

---

考虑到 Framework 中所需要学习的知识点较多，想一次性全部在这讲完有点不太现实，于是对Framework 的所有知识点整理了一条完整知识路线，并将相关的知识点解析整理成了对应的学习手册，请继续往下看：

该路线共分为5大版块，分别是：Framework 通信、Framework底层服务、Framework 系统资源、Framework事件机制、Framework UI机制，在这些里面又分了许多小分支，大家可以仔细的参考看一下。针对这图中所记录的一些小知识点相关解析汇总成了一个文档形式，有需要的可以 直接点击此处↓↓↓ 直达获取方式参考学习！

《Framework 核心知识点汇总手册》

Handler 机制实现原理部分：
1.宏观理论分析与Message源码分析
2.MessageQueue的源码分析
3.Looper的源码分析
4.handler的源码分析
5.总结

Binder 原理：

1.学习Binder前必须要了解的知识点
2.ServiceManager中的Binder机制
3.系统服务的注册过程
4.ServiceManager的启动过程
5.系统服务的获取过程
6.Java Binder的初始化
7.Java Binder中系统服务的注册过程

Zygote ：

1. Android系统的启动过程及Zygote的启动过程
2. 应用进程的启动过程

AMS源码分析 ：

1. Activity生命周期管理
2. onActivityResult执行过程
3. AMS中Activity栈管理详解

深入PMS源码：

1.PMS的启动过程和执行流程
2.APK的安装和卸载源码分析
3.PMS中intent-filter的匹配架构

WMS：
1.WMS的诞生
2.WMS的重要成员和Window的添加过程
3.Window的删除过程

《Android Framework学习手册》：

1. 开机Init 进程
2. 开机启动 Zygote 进程
3. 开机启动 SystemServer 进程
4. Binder 驱动
5. AMS 的启动过程
6. PMS 的启动过程
7. Launcher 的启动过程
8. Android 四大组件
9. Android 系统服务 - Input 事件的分发过程
10. Android 底层渲染 - 屏幕刷新机制源码分析
11. Android 源码分析实战

有需要的可以 直接点击此处↓↓↓ 直达获取方式参考学习！

作为过来人，发现很多学习者和实践者都在 Android Framework上面临着很多的困扰，比如：

• 工作场景中遇到难题，往往只能靠盲猜和感觉，用临时性的补救措施去掩盖，看似解决了问题，但下次同样的问题又会发作，原因则是缺乏方法论、思路的指引以及工具支持；
• 能力修炼中，缺乏互联网项目这一实践环境，对Framework只能通过理论知识进行想象，无法认识其在工作实战中的真实面目和实操过程；
• 职场晋升中，只管功能开发，不了解底层原理，缺少深入地思考与总结，无法完成复杂系统设计这类高阶工作，难以在工作中大展拳脚，而有挑战的工作往往留给有准备的人。

原文地址：https://blog.csdn.net/weixin_61845324