Android IPC机制

Android IPC

Binder机制好文章

1、Android 多进程模式

1.1、开启多进程模式

在Android中使用多进程只有一种方法，那就是给四大组件（Activity、Service、Receiver、ContentProvider）在AndroidMenifest中指定android:process属性，多进程可会造成一下几个方面的问题：
（1）静态成员和单例模式完全失效。
（2）线程同步机制完全失效。
（3）SharedPreferences的可靠性下降。
（4）Application会多次创建。

2、IPC 基础概念介绍

2.1、序列化

• Serializable接口。原则上序列化后的数据中的serialVersionUID只有和当前类的serialVersionUID相同才能够正常地被反序列化。如果不手动指定serialVersionUID的值，反序列化时当前类有所改变，比如增加或者删除了某些成员变量，那么系统就会重新计算当前类的hash值并把它赋值给serialVersionUID，这个时候当前类的serialVersionUID就和序列化的数据中的serialVersionUID不一致，于是反序列化失败，程序就会出现crash。
• Parcelable接口。

Serializable是Java中的序列化接口，其使用起来简单但是开销很大，序列化和反序列化过程需要大量I/O操作。而Parcelable是Android中的序列化方式，因此更适合用在Android平台上，它的缺点就是使用起来稍微麻烦点，但是它的效率很高，这是Android推荐的序列化方式，因此我们要首选Parcelable。

3、Binder概述

3.1、为什么要使用binder

Android 系统是基于 Linux 内核的，Linux 已经提供了管道、消息队列、共享内存和 Socket 等 IPC 机制。那为什么 Android 还要提供 Binder 来实现 IPC 呢？主要是基于性能、稳定性和安全性几方面的原因。

• 性能。Socket 作为一款通用接口，其传输效率低，开销大，主要用在跨网络的进程间通信和本机上进程间的低速通信。 消息队列和管道采用存储-转发方式，即数据先从发送方缓存区拷贝到内核开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区，至少有两次拷贝过程。 共享内存虽然无需拷贝，但控制复杂，难以使用。
  Binder 只需要一次数据拷贝，性能上仅次于共享内存。
  

• 稳定性，bingder基于C/S架构，架构清晰，职责明确。

• 安全性

4、Linux下传统的进程间通信原理

4.1、基本概念介绍

• 进程隔离：进程与进程之间内存不用想，两个进程间通讯要通过IPC

• 进程空间划分:(用户空间/内核空间)。为了保护用户进程不能直接操作内核，保证内核的安全，操作系统从逻辑上将虚拟空间划分为用户空间（User Space）和内核空间（Kernel Space）。针对 Linux 操作系统而言，将最高的 1GB 字节供内核使用，称为内核空间；较低的 3GB 字节供各进程使用，称为用户空间。
  

• 系统调用：用户态和内核态：系统调用是用户空间访问内核空间的唯一方式，保证了所有的资源访问都是在内核的控制下进行的，避免了用户程序对系统资源的越权访问，提升了系统安全性和稳定性。 当一个任务（进程）执行系统调用而陷入内核代码中执行时，称进程处于内核运行态（内核态）。此时处理器处于特权级最高的（0级）内核代码中执行。当进程处于内核态时，执行的内核代码会使用当前进程的内核栈。每个进程都有自己的内核栈。

当进程在执行用户自己的代码的时候，我们称其处于用户运行态（用户态）。此时处理器在特权级最低的（3级）用户代码中运行。

4.2、Linux下的传统IPC通信原理

传统IPC问题：

• 性能低下，一次数据传递需要经历：内存缓存区 --> 内核缓存区 --> 内存缓存区，需要 2 次数据拷贝；
• 接收数据的缓存区由数据接收进程提供，但是接收进程并不知道需要多大的空间来存放将要传递过来的数据，因此只能开辟尽可能大的内存空间或者先调用 API 接收消息头来获取消息体的大小，这两种做法不是浪费空间就是浪费时间。

5、Binder跨进程通信原理

5.1、动态内核加载模块&&内存映射

一次完整的 Binder IPC 通信过程通常是这样：

• Binder驱动在内核空间创建一个数据接收缓存区
• 接着在内核空间开辟一块缓存区，建立内核缓存区与数据接收缓存区的映射关系，以及数据接收缓存区到用户空间地址的映射关系。
• 发送方通过系统调用copyfromuser将数据copy到内核中的内核缓存区，由于内核缓存区和接收进程的用户空间存在内存映射，所以相当于把数据发送到了接收进程的用户空间，这样便完成了一次进程间的通通信。

6、Binder 通信模型

6.1、Client/Server/ServiceManager/驱动

其中 Client、Server、Service Manager 运行在用户空间，Binder 驱动运行在内核空间。其中 Service Manager 和 Binder 驱动由系统提供，而 Client、Server 由应用程序来实现。

6.2、Binder通信过程

• 一个进程使用 BINDERSETCONTEXT_MGR 命令通过 Binder 驱动将自己注册成为 ServiceManager；
• Server 通过驱动向 ServiceManager 中注册 Binder（Server 中的 Binder 实体），表明可以对外提供服务。驱动为这个 Binder 创建位于内核中的实体节点以及 ServiceManager 对实体的引用，将名字以及新建的引用打包传给 ServiceManager，ServiceManger 将其填入查找表。
• Client 通过名字，在 Binder 驱动的帮助下从 ServiceManager 中获取到对 Binder 实体的引用，通过这个引用就能实现和 Server 进程的通信。

6.3、Binder通信中的代理模式

7、AIDL源码分析