在 Android 系统中，Binder 起着非常重要的作用，它是整个系统 IPC 的基石。网上已经有很多文章讲述 Binder 的原理，有的讲的比较浅显，没有触及到关键，有的讲的太过于深入底层，难以理解，本文会比较全面，以一个比较轻松的方式，从面到点，大处着眼，小处着手的形式去讲述 Binder 在 Android 中是如何使用的。理解 Binder 的基本原理，对学习 Android 也有很大的帮助，很多问题也能够得到解释，例如 ContentProvider 中的 CRUD 是否是线程安全的？又例如在使用 AIDL 的时候，在 Service 中实现的接口是否是线程安全的？
本文分为以下几个部分去介绍
- Android 整体架构
- Binder IPC 的架构
- 手动实现 Binder IPC
- 使用 AIDL 实现 Binder IPC
如果觉得文章太长，可以先只看「小结」部分，小结会把每个部分的重点总结出来，有些部分可以跳过。
Android 整体架构
不识庐山真面目，只缘身在此山中，所以我们先来大概看下 Android 这座大山的整体轮廓。我们先从 Android 的整体架构来看看 Binder 是处于什么地位，这张图引自 Android 项目开源网站：
从下往上依次为
- 内核层：Linux 内核和各类硬件设备的驱动，这里需要注意的是，Binder IPC 驱动也是在这一层实现，比较特殊
- 硬件抽象层：封装「内核层」硬件驱动，提供可供「系统服务层」调用的统一硬件接口
- 系统服务层：提供核心服务，并且提供可供「应用程序框架层」调用的接口
- Binder IPC 层：作为「系统服务层」与「应用程序框架层」的 IPC 桥梁，互相传递接口调用的数据，实现跨进层的通讯
- 应用程序框架层：这一层可以理解为 Android SDK，提供四大组件，View 绘制体系等平时开发中用到的基础部件
在一个大的项目里面，分层是非常重要的，处于最底层的接口最具有「通用性」，接口粒度最细，越往上层通用性降低。理论上来说上面的每一层都可以「开放」给开发者调用，例如开发者可以直接调用硬件抽象层的接口去操作硬件，或者直接调用系统服务层中的接口去直接操作系统服务，甚至是像 Windows 开发一样，开发者可以在内核层写程序，运行在内核中。不过开放带来的问题就是开发者权利太大，对于系统的稳定性是没有任何好处的，一个病毒制作者写了一个内核层的病毒，系统也许永远也起不来了。所以谷歌的做法是将开发者的权利收拢到了「应用程序框架层」，开发者只能调用这一层提供的接口。
上面的层次中，内核层与硬件抽象层均用 C/C++ 实现，系统服务层是以 Java 实现，硬件抽象层编译为 so 文件，以 JNI 的形式供系统服务层使用。系统服务层中的服务随系统的启动而启动，只要不关机，就会一直运行。这些服务干什么事情呢？其实很简单，就是完成一个手机该有的核心功能如短信的收发管理、电话的接听、挂断以及应用程序的包管理、Activity 的管理等等。每一个服务均运行在一个独立进程中，因为是以 Java 实现，所以本质上来说就是运行在一个独立进程的 Dalvik 虚拟机中。问题就来了，开发者的 APP 运行在一个新的进程空间，如何调用到系统服务层中的接口呢？答案是 IPC（Inter-Process Communication），进程间通讯，缩写与 RPC（Remote Procedure Call）是不一样的，实现原理也是不一样的。每一个系统服务在应用层序框架层都有一个 Manager 与之对应，方便开发者调用其相关的功能，具体关系大致如下
IPC 的方式有很多种，例如 socket、共享内存、管道、消息队列等等，我们就不去深究为何要使用 Binder 而不使用其他方式去做，到目前为止，这座大山的面目算是有个大概的轮廓了。
小结
- Android 从下而上分了内核层、硬件抽象层、系统服务层、Binder IPC 层、应用程序框架层
- Android 中「应用程序框架层」以 SDK 的形式开放给开发者使用，「系统服务层」中的核心服务随系统启动而运行，通过应用层序框架层提供的 Manager 实时为应用程序提供服务调用。系统服务层中每一个服务运行在自己独立的进程空间中，应用程序框架层中的 Manager 通过 Binder IPC 的方式调用系统服务层中的服务。