Part 2

结合 官方文档 阅读《Android 开发艺术探索》时所做的学习笔记。本篇记录第二章：IPC 机制。

What? How? Why?

什么是 IPC？

所谓的 IPC 是指进程间通信（Interprocess communication 的缩写），我们知道 Linux 里可以通过管道、signal 等进行重定向、跨进程通信等，Android 中同样如此。一般情况下只要应用中使用了多个进程，那么就会涉及到进程间通信的问题。另外，由于每一个 Android 应用都是一个沙箱，独享一个进程，所以应用间数据共享同样也需要通过 IPC。

有哪些 IPC 的方式？

Android 中进程间通信的方式有很多，比如最常见的通过 Intent.putExtra 以及 Content Provider，通过文件共享（需要注意并发读/写问题），通过 Socket，以及最重要的一种 IPC 方式，通过 绑定服务，其中最重要的部分是 Binder，Messager 和 AIDL 底层实现也是通过 Binder。

为什么需要 IPC？

首先，当应用 A 启动的时候，Android 系统会为它单独指定一个进程，分配一个 User ID，于是它只能在这个进程里执行自己的代码，访问自己的数据空间。但是如果我们为应用 A 指定了多个进程，并且想要调用另一个进程中的代码，那么我们是无法直接访问另一个进程中的内存空间的，所以就需要某种方式或者说通过某个桥梁，建立起进程间的连接。这个方式可以称为 remote procedure calls (RPCs)，而借用的桥梁就是 Binder。

简单来说就是将方法调用以及数据，分解成操作系统能够读取的程度，然后把它从当前进程和地址空间中传送到目标进程和地址空间，重新组合起来之后再进行调用，最后将结果用同样的方式返回给请求发生的进程。

More details

IPC 基础概念

序列化

Serializable 接口

• 只要实现 Serializable 接口并提供 serialVersionUID，系统会为我们自动完成序列化的工作。
• 系统通过 servialVersionUID 来标记需要序列化的类，如果我们不提供，系统会为我们默认生成一个，而使用默认生成的 servialVersionUID 的时候，如果序列化类发生改变则 servialVersionUID 也会发生改变，此时反序列化就会失败报错。所以必须手动指定 servialVersionUID 值。
• 可以使用 transient 关键字标记不需要序列化的成员变量。

Parcelable 接口

• 通过 writeToParcel 完成序列化（一系列的 Parcel.writeXXX）。
• 通过 CREATOR 来标记如何创建序列化对象以及数组，并通过构造方法中的一系列 Parcel.readXXX 完成反序列化。
• 反序列化时，如果存在可序列化的属性，即使用 Pacel.readParcelable 时需要传递当前线程的类加载器，否则会报 ClassNotFound 的错误。
• 一般情况下，discribeContents 都应该返回 0，只有在存在文件描述符时才需要返回 1。

Binder

Binder 实现了 IBinder 接口，在跨进程通信中，它是客户端与服务端通信的媒介，当绑定服务时，服务端会返回一个 Binder 对象，而客户端正是通过这个 Binder 对象来获取服务端的数据以及进行远程方法调用。

一般的 Service 如果不涉及进程间通信，那么只要实现 IBinder 接口就可以了，所以我们以最基本的 AIDL 作为例子来解释 Binder 的工作原理。AIDL 实际上是 Android 为我们封装好的接口定义语言，它自动为我们生成 Binder 的实现代码。

具体而言，一个 Binder 的实现通常需要有以下部分：

• DESCRIPTOR，该 Binder 的唯一标识。
• 供客户端调用的方法，具体实现交给内部类 Stub。
• Stub 中的 asBinder() 方法，返回当前 IBinder 对象。
• Stub 中的 asInterface(IBinder obj) 方法，将 IBinder 转换为客户端实际需要的接口类型（即当前接口）的对象，如果是在同一进程中，则直接返回当前对象，否则就需要创建一个 Proxy 对象并返回，因为需要通过 transact() 方法进行跨进程传递数据、完成方法调用并返回结果。
• Stub 中的 onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) 方法，实际对客户端跨进程请求进行处理的地方，通过 code 确定请求方法，通过 data 获取参数，向 reply 中写入返回值，如果返回结果为 true 表示请求成功，false 表示无法识别请求 code，我们也可以通过此方法来做权限验证。另外，此方法运行在服务端的 Binder 线程池中。
• Proxy 类才是真正 IPC Binder 的实现类，由客户端发起调用。如果是在同一进程中，会直接调用 Stub 中的方法，而如果是跨进程，则需要使用到 Proxy类。具体过程如下：
  • 将输入对象、输出对象、返回值写入 Parcel data；
  • 然后发起远程调用，即执行 transact() 方法，当前线程会被挂起；
  • 然后再调用服务端的 onTransact() 方法，获取返回结果（如果有的话）后，再从返回值 reply 中读取结果并返回，客户端当前线程得以继续执行。

以上最关键的部分是最后的 Proxy 类以及 onTransact() 方法。

关于 AIDL 的具体使用方式请看下面的 AIDL 部分。

IPC 方式介绍

Bundle

Intent.putExtra(Bundle)，数据必须是可以序列化的，比如原始数据类型，实现 Parcelable 接口或者 Serializable 接口的对象，基本数据类型或者实现了 Parcelable 的 ArrayList/SparceArray 等。

文件共享

对数据格式没有要求，但是需要注意并发读写的问题。

SharedPreferences 是个特例，它会在内存中保存一份拷贝，使用 apply() 时进行异步提交（先保存到内存然后异步提交保存到文件），而使用 commit() 时会阻塞并返回结果，它是单进程模式下的单例，所以多进程明显就变得非常不可靠。

Messager

轻量级的 IPC，底层使用的是 AIDL。

• 服务端创建一个 Service 处理连接请求，创建一个 Handler 对象，对客户端传递过来的信息进行接收处理（通过 what 获取类型，通过 arg1/arg2/Bundle 获取数据，通过 replyTo 获取客户端传递过来的 Messager），再用它创建 Messager 对象（new Messager(Handler)），在 onBind 中返回 Messager 的 IBinder。
• 客户端同样需要创建 Messager，只要通过 ServiceConnection 与服务端建立连接，然后获取到 Server 端的 IBinder，然后从消息池（Message.obtain()）中获取 Message，并传递数据 Messager.send(Message)，传递数据同样可以通过 [arg1, arg2, what, Bundle, replyTo 以及 object]，其中使用 replyTo 传递需要服务端返回的 Messager。
• Message 支持的数据类型中，object 比较特殊，它在单进程中比较实用，但是跨进程限制就比较大了，只能传递系统中实现了 Parcelable 接口的对象，比如 Rect、Point 等。

AIDL

Messager 适合跨进程传递消息，如果有大量请求或者需要跨进程方法调用，那么可能就需要使用到 AIDL 了。

• 服务端：我们需要创建一个 Service 监听客户端的连接请求，然后在 .aidl 文件中声明需要暴露给客户端的接口，再在 Service 中实现这个接口。
• 客户端：绑定 Service，然后将 IBinder 转换为定义好的 AIDL 接口类型然后调用获取结果。

具体步骤如下：

1. 创建 .aidl 接口

与创建普通 Java 接口类似，只不过只支持下面一些数据类型：

• 基本数据类型
• String 和 CharSequence
• 实现了 Parcelable 接口的对象
• List（具体实际使用的是 ArrayList）和 Map（具体实际使用的是 HashMap），其中的元素必须全都支持 AIDL
• AIDL 接口，使用时必须显式导入

另外，使用 AIDL 传递 Parcelable 对象时，还需要我们为该 Parcelable 对象创建一个 .aidl 文件，如下：

package your.package.name

parcelable YourParcelableClass;

再之，AIDL 接口方法的参数必须标明方向 in out inout，in 表示输入型参数，out 表示输出型参数，inout 两者皆可，基本数据类型默认为 in。不同参数类型的 Binder 在再编码（marshall，不知道如何翻译，将数据序列化、传输、接收、解序列化的过程）时所需的步骤不同，标明类型后，Binder 可以跳过某些步骤从而达到节省开销的目的。具体解释见：“In/out/inout” in a AIDL interface parameter value?

创建好 AIDL 接口后，gradle sync 后 IDE 会为我们生成对应的 Java 文件。

2. 实现 AIDL 接口（其实是接口中的 Stub 类，即 Binder 真正的实现类）

在服务端 Service 中，我们需要实现接口中的 Stub 类，然后在 onBind() 方法中返回供客户端调用。需要注意的是：

• 来自客户端的调用，不一定是执行在主线程的，而且有可能多个客户端与服务端同时建立连接，所以需要注意线程安全的问题。
• 默认情况下，远程调用是同步执行的，所以如果客户端在主线程发生 RPC，需要考虑调用是否耗时，否则会造成 ANR，最好在子线程调用。
• 客户端不会接收到服务端抛出的异常。

3. 客户端的实现

客户端通过 bindService() 与服务端建立连接后，通过 onServiceConnected() 回调中获取 binder 实例，然后再通过 YourAIDLInterface.Stub.asInterface() 将 binder 实例类型转换为所需要的 AIDL 接口（如果客户端位于不同的应用中，则必须也要保留一份 .aidl 文件，以便生成 AIDL 接口）。

需要注意的是，如果我们使用了回调的话，会遇到无法解注册的问题，本质是因为回调接口在从客户端传递到服务端的时候，已经不是同一个对象了，想要成功解注册我们需要使用 RemoteCallbackList，它是线程安全的（原理：通过遍历所有 Binder 对象--我们的 listener 也是 Binder 对象--然后找到对应的 listener 再删除）。

另外还要注意 Binder 意外死亡（DeathRecipient 或 onServiceDisconnected()，前者在 Binder 线程池中被调用，后者在 UI 线程中调用）以及权限验证（onBind() 或 onTrasact() 中做处理）的问题。具体请查看例子：Chapter_2/aidl

ContentProvider

参考文档

Socket

分为 TCP 套接字（Java 中对应的实现使用 ServerSocket）和 UDP 套接字（Java 中对应的实现使用 DatagramSocket），具体例子见：Chapter_2/socket

Binder 连接池

Binder 连接池的主要作用是将每个业务模块的 Binder 请求统一转发到远程 Service 中去执行，从而避免重复创建 Service，节省系统资源。

工作机制：每个模块创建并实现自己的 AIDL 接口，然后向服务端提供自己的唯一标识和对应的 Binder 对象，服务端只是需要一个 Service，然后提供一个 queryBinder 接口，根据业务模块的标识来返回相应的 Binder 对象，然后再由客户端发起远程方法调用。

具体例子见：Chapter_2/binderpool

优缺点对比