走进Android Binder机制（驱动篇上）

转载https://blog.csdn.net/ming_147/article/details/65633571

由于篇幅限制，驱动篇文章分为上下两章，还请大家注意，此篇是上篇。

Binder的实现是比较复杂的，想要完全弄明白是怎么一回事，并不是一件容易的事情。

这里面牵涉到好几个层次，每一层都有一些模块和机制需要理解。这部分内容预计会分为三篇文章来讲解。本文是第一篇，首先会对整个Binder机制做一个架构性的讲解，然后会将大部分精力用来讲解Binder机制中最核心的部分：Binder驱动的实现。Binder机制简介

Binder源自Be Inc公司开发的OpenBinder框架，后来该框架转移的Palm Inc，由Dianne Hackborn主导开发。OpenBinder的内核部分已经合入Linux Kernel 3.19。

Android Binder是在OpneBinder上的定制实现。原先的OpenBinder框架现在已经不再继续开发，可以说Android上的Binder让原先的OpneBinder得到了重生。

Binder是Android系统中大量使用的IPC（Inter-process communication，进程间通讯）机制。无论是应用程序对系统服务的请求，还是应用程序自身提供对外服务，都需要使用到Binder。

因此，Binder机制在Android系统中的地位非常重要，可以说，理解Binder是理解Android系统的绝对必要前提。

在Unix/Linux环境下，传统的IPC机制包括：

管道

消息队列

共享内存

信号量

Socket

Android系统中对于传统的IPC使用较少（但也有使用，例如：在请求Zygote fork进程的时候使用的是Socket IPC），大部分场景下使用的IPC都是Binder。

Binder相较于传统IPC来说更适合于Android系统，具体原因的包括如下三点：

Binder本身是C/S架构的，这一点更符合Android系统的架构

性能上更有优势：管道，消息队列，Socket的通讯都需要两次数据拷贝，而Binder只需要一次。要知道，对于系统底层的IPC形式，少一次数据拷贝，对整体性能的影响是非常之大的。

安全性更好：传统IPC形式，无法得到对方的身份标识（UID/GID)，而在使用Binder IPC时，这些身份标示是跟随调用过程而自动传递的。Server端很容易就可以知道Client端的身份，非常便于做安全检查。

整体架构
Binder整体架构如下所示：