深入浅出Android-Binder机制（图文+源码深入剖析

Binder 产生的背景

首先我们说说为什么会出现 Binder 这个东西。作为 iOS 开发者，我还是情不自禁地想去谈谈 iOS app，事实上，iOS 的每一个 app 都是一个独立的进程，它没有 Android 那种比较开放的多进程通讯能力，甚至 App 与 Extension （如通知中心插件）之间都不能有一种非常直接的通讯方式，当然不是说 iOS 没有 IPC 技术，其实 mach 内核也是有着不错的 IPC 技术的，但这不是本文的重点。Android 则不太一样，Android apps 基本上都需要各式各样的 IPC 需求，甚至启动一个 Activity 也需要用到 IPC，有一些 IPC 调用也许你并不知晓，可能对开发者最可见的就是用 AIDL 去写一个 Remote Service 接口了。

Android 很多核心功能都是由一系列 Services 支持的，比如 ActivityService、WindowService 等等等等，应用需要频繁地与这些 Services 发生交互，正是基于这种场景，就亟需一种好的 IPC 解决方案。

你可能会想，为什么不是 Local Socket？或者 Shared Memory，那是因为安全性无法得到保障。Android 的权限系统需要一种可靠的方式来保证各种 Services 的访问是在权限系统的监控下进行的，上述提到的解决方案就做不到了，因为不管是套接字还是共享内存，现有的 Linux 内核都不存在一种检验双方身份的方法存在，任何通过套接字或者共享内存走的数据都可以伪造，而在这个基础上做任何验证，代价都是相当高的。Android 的选择是基于内核，重新开发一套 IPC 机制，让它固有这些特性，也就是让系统可以在 Ring0 级保障交互双方身份的正确性，并且这种基于内核的方案效率还很高。

既然要基于内核，就一定要对内核动手脚，Android 采用驱动的方式实现这个技术，而不是直接修改 Linux 内核。这样你就可以假设，手机中有一个“设备”，应用之间通过这个设备来交互，而这个设备自身有一套身份校验机制，这样就比基于用户态的 IPC 方案来的安全得多，也快得多了。

Binder