binder
Android应用程序是由Activity、 Service、 Broadcast Receiver和 Content Provider四种类型的组件构成的， 它们有可能运行在同一个进程中， 也有可能运行在不同的进程中。 此外， 各种系统组件也运行在独立的进程中， 例如， Activity管理服务ActivityManagerService和Package管理服务PackageManagerService都运行在系统进程System中。
Android系统是基于Linux内核开发的。 Linux内核提供了丰富的进程间通信机制， 如管道（Pipe） 、 信号（Signal） 、 消息队列（Message） 、 共享内存（Share Memory） 和 插口（Socket） 等。
而 Android系统开发了一套新的进程间通信机制——Binder。
Binder进程间通信机制在进程间传输数据时， 只需要执行一次复制操作， 所以，提高了效率，节省了内存空间。Binder进程间通信机制是在OpenBinder的基础上实现的， 它采用CS通信方式， 其中， 提供服务的进程称为Server进程， 而访问服务的进程称为Client进程。
同一个Server进程可以同时运行多个组件来向Client进程提供服务， 这些组件称为Service组件。同一个Client进程也可以同时向多个Service组件请求服务， 每一个请求都对应有一个Client组件( Service代理对象) 。
Binder进程间通信机制的每一个Server进程和Client进程都维护一个Binder线程池来处理进程间的通信请求， 因此， Server进程和Client进程可以并发地提供和访问服务。 Server进程和Client进程的通信要依靠运行在内核空间的Binder驱动程序来进行。
Binder驱动程序向用户空间暴露了一个设备文件/dev/binder， 使得应用程序进程可以间接地通过它来建立通信通道。
Service组件在启动时， 会将自己注册到一个Service Manager组件中， 以便Client组件可以通过Service Manager组件找到它。
因此， 我们将Service Manager组件称为Binder进程间通信机制的上下文管理者， 同时由于它也需要与普通的Server进程和Client进程通信， 我们也将它看作是一个Service组件， 只不过它是一个特殊的Service组件。
Binder进程间通信机制 :
Client、 Service 和 Service Manager 运行在用户空间， 而Binder驱动程序运行在内核空间， 其中， Service Manager 和 Binder驱动程序由系统负责提供， 而 Client 和 Service 组件由应用程序来实现。 Client、 Service和Service Manager均是通过系统调用 open、 mmap 和 ioctl 来访问设备文件 /dev/binder， 从而实现与 Binder 驱动程序的交互， 而交互的目的就是为了能够间接地执行进程间通信。
分析 Binder 进程间通信机制的四个使用情景， 分别是：
（1） Service Manager的启动过程。
（2） Service Manager代理对象的获取过程。
（3） Service组件的启动过程。
（4） Service代理对象的获取过程。
上述四个使用情景都是基于Binder进程间通信机制的C/C++实现来分析
