Binder
注：传统的跨进程通信需拷贝数据2次，但Binder机制只需1次，主要是使用到了内存映射。
Android 系统基本上可以看作是一个基于 Binder 通信的 C/S 架构。 Binder 就像网络一样，把系统的各个部分连接在了一起，因此它是非常重要的。
Android Binder机制大都涉及Java层、Native层、驱动层这三三个方面。
默认情况下，同一个应用程序中的所有组件运行在同一个进程中，而且绝大多数的应用程序也都是这样的。这个默认进程是用这个应用的包名来命名的。
我们在运行App的时候经常需要使用一些系统服务，比如剪切板服务，而剪切板服务是运行在SystemServer进程中的。那我们的App是怎么使用剪切板服务的呢，我们都知道进程是相互独立的，静态变量等等都无法共用。这就涉及到进程间的通信了，即IPC。
Binder对象是一个可以跨进程引用的对象，它的实体位于一个进程中，而它的引用却遍布于系统的各个进程之中。最诱人的是，这个引用和java里引用一样既可以是强类型，也可以是弱类型，而且可以从一个进程传给其它进程，让大家都能访问同一Server，就象将一个对象或引用赋值给另一个引用一样。Binder模糊了进程边界，淡化了进程间通信过程，整个系统仿佛运行于同一个面向对象的程序之中。
我们都知道Android是基于Linux内核的，那我们简单介绍下Linux下的几种IPC机制：
1，管道（Pipe）
2，Socket
3，Binder
用Binder的优势：
采用C/S的通信模式
有更好的传输性能
安全性更高
应用案例：Laucher进程向AMS进程发送启动根Activity的请求：
关于Java层的Binder机制，我们只需要理解以BinderProxy代表的代理端和Binder代表的服务端的概念即可，例如我们本例中的AMS，AMS是运行在SystemServer进程中的服务端，它间接继承于Binder，在得到相关请求后，会调用AMS重写的onTransact函数进行逻辑处理。那么这个请求就是是AMS的客户端ActivityManagerProxy通过Binder的方式发给它的，ActivityManagerProxy发送这个请求的方式，是通过调用其内部的成员变量mRemote,这个mRemote其实是BinderProxy的对象，然后BinderProxy通过JNI调用Native层对应函数，最终通过Binder驱动达到与SystemServer交互的目的。
三层Binder交互流程图如下：
需要注意的是此处的Service Manager是指Native层的ServiceManager（C++），并非指framework层的ServiceManager(Java)。ServiceManager是整个Binder通信机制的大管家，图中的Client,Server,Service Manager之间交互都是虚线表示，是由于它们彼此之间不是直接交互的，而是都通过与Binder驱动进行交互的，从而实现IPC通信方式。
每个Android的进程，只能运行在自己进程所拥有的虚拟地址空间。对应一个4GB的虚拟地址空间，其中3GB是用户空间，1GB是内核空间，当然内核空间的大小是可以通过参数配置调整的。对于用户空间，不同进程之间彼此是不能共享的，而内核空间却是可共享的。Client进程向Server进程通信，恰恰是利用进程间可共享的内核内存空间来完成底层通信工作的，Client端与Server端进程往往采用ioctl等方法跟内核空间的驱动进行交互。