Binder的基本原理

多进程有哪些优点？

多进程一般在webView、图片加载、推送、闹钟之类的比较常见，还有比如在使用getSystemService获取系统服务的时候，虽然在自己写的代码中没有发现多进程，其实在内部实现中也是多进程。

它们为什么需要被做成多进程的呢？

1、解决手机内存问题

虽然现在手机的运行内存是很大的，但是手机的APP是运行在独立的虚拟机中的，虚拟机会为每一个进程分配运行内存是有限的，一般只有32M、48M、64M，所以经常会发生一些内存不足的问题，就像加载一个大的图片，可能就直接OOM。

2、其他进程崩溃，避免影响主进程

打个比方，就像是微信的小程序，微信小程序的开发者们水平参差不齐，如果有一个小程序崩溃了，微信的主进程是不会崩溃的，这就已经说明，微信的主进程与微信的小程序不在同一个进程中。

 

Binder是什么？

1. Binder是一个实现了IBinder接口的类；

2. Binder是一种虚拟的物理设备，它的设备驱动是/dev/binder；

3. Binder是连接ServiceManager连接各种Manager和对应ManagerService的桥梁；

4. Binder是客户端和服务端进行通信的媒介，当bindService时，服务端会返回一个包含了服务端业务调用的Binder对象，通过这个Binder对象，客户端就可以获取服务端提供的服务（普通服务、基于AIDL服务）或数据。

在Android中，Binder主要存在Service中，包括AIDL和Messenger。

 

两进程之间如何进行通信？

从进程1的用户空间到进程2的用户空间，需要经过内核空间，数据从进程1的用户空间先通过系统调用到达内核空间，然后从内核空间通过系统调用到达进程2的用户空间，这就是数据的传输过程。

因为进程1和进程2是两个进程，所以他们的之间是隔离的，但是它们的内核空间它是一个整块，他可以去随意访问进程。

 

Socket如何进行跨进程通信？

1、首先，发送方的进程先通过系统调用copy_from_user()，来将数据从用户空间复制到内核缓存区中（这是第一次拷贝）。

2、然后，内核空间再通过系统调用copy_to_user()，将数据从内核缓存区中又拷贝到接收进程的用户空间中（这是第二次拷贝）。

 

Binder如何进行跨进程通信？

1、当发送方进程将数据发送到内核空间的时候，与传统IPC是一样的，都是通过了系统调用copy_from_user()。

2、在内核空间与接收方的用户空间之间，它是使用的映射来完成的。接收方进程和内核空间之间有一块区域，它们两个之间存在映射关系，就好比于，内核空间的那块空间是一块虚拟空间，用户空间也是一块虚拟空间，它们两个空间都映射在了同一块的物理空间，当数据传入到了内核空间，也就相当于存在于内核空间的那块物理空间，而这块物理空间又同时被用户空间这个虚拟空间所映射，所以也就相当于数据存在了用户空间。

内存它会存在于一个虚拟空间和物理空间上，它们之间是有一个地址映射的关系，可能用户空间映射在这，内核空间映射在那，另一个用户空间又映射在别处，它们之间是分开的，没有关联的。

所以想要在他们三者之间数据传递的话，只能像传统IPC那样去copy两次；而Binder，因为它在接受方进程与内核空间之间通过MMap（Memory Map内存映射）有一个映射，也就是内核空间的虚拟内存与接受方用户空间的虚拟内存映射同一块物理空间，

虚拟空间：这里所说的用户空间和内核空间，其实都是虚拟空间，既然是虚拟空间，它就需要映射到物理空间上，因为我们的数据都是保存在物理空间上的。

 

Binder既然内核空间于接收方内存空间使用映射，为什么不直接从发送方的用户空间直接映射到接受方的用户空间？

1、首先，如果就像问题所说，直接从用户空间映射到了用户空间，那其实就成了共享内存这个概念。为什么即使共享内存可以做到0拷贝，而Binder没有选择这个做法呢？

2、Binder是基于了C/S（Client/Server）架构的，使用起来非常简单；而共享内存因为两块虚拟内存共同映射在一块物理空间，多进程共享同一块内存区域，所以会有一些同步机制的问题，比如一些死锁、数据不同步等问题，所以共享内存使用起来较为复杂。这样一来，Binder考虑到易用性方面，在性能方面也做了一些取舍。

 

Binder与传统IPC之间的对比