第二章 IPC机制

2.1 Android IPC简介

IPC是Inter-Process Communication的缩写，含义为进程间通信或者跨进程通信，是指两个进程间进行数据交换的过程。Android中进程间通信方式Binder和Socket通信。

2.2 Android中的多进程模式

在Android中使用多进程只有一种方法，那就是给四大组件（Activity，Service，ContentProvider，BroadcastReceiver）在AndroidManifest中指定android:process属性。默认情况下，进程的进程名是包名，以":"开头的进程属于当前应用的私有进程，而进程名不以":"开头的进程属于私有进程，其它应用通过ShareUID方式可以和它跑到同一个进程中。

2.3 IPC基础概念介绍

2.3.1 Serializable

是Java所提供的一个序列化接口，它就是一个空接口，为对象提供序列化和反序列化操作。ObjectOutputStream和ObjectInputStream可轻松实现序列化和反序列化。序列化和反序列化的serialVersionUID的值要相同。静态成员属于类不属于对象，所以不会参与序列化过程；其次用transient关键字标记的成员变量不参与序列化过程。

2.3.2 Parcelable接口

也是一个接口，一个对象就可以实现序列化并通过Intent和Binder传递了。

二者区别：Serializable是Java中的序列化接口，使用起来简单但是开销大，序列化和反序列化需要大量的IO操作，而Parcelable是Android中的序列化方式，因此更适合用在Android平台上，它的缺点是使用起来稍微麻烦点，但是它的效率高，这是Android推荐的序列化方式，因此我们要首选Parcelable。Parcelable主要用在内存序列化上。

2.3.3 Binder

AIDL接口生成类分析
继承IInterface：所有在Binder中传输的接口都需要继承IInterface接口。声明aidl文件中的方法，同时声明整形的id分别标识这方法，这个标记用户客户端锁清秋的是哪个方法。声明一个内部类Stub，继承Binder并实现aidl接口类。当客户端和服务端位于同一个进程时，方法调用不会走跨进程的transact过程，而两者位于不同进程时，方法调用需要走transact过程，这个逻辑由Stub的内部代理Proxy来完成。
DESCRIPTOR：用于表示当前类名
asInterface：用于将服务端的Binder对象转换成客户端所需的AIDL接口类型的对象。如果是同一进程，返回的就是Stub本身，否则就是系统封装后的Stub.Proxy对象。
asBinder：用于返回当前Binder对象。
onTransact：这个方法运行在服务端的Binder线程池中，当客户端发起跨进程请求时，远程请求会通过系统底层封装后交由此方法来处理。当此方法返回true，则代表请求成功，否则失败，所以可以用此方法来进行权限验证。
接口方法：运行在客户端，当客户端调用远程方法时，首先创建该方法的输入性Parcel对象和输出型Parcel和返回值，接着调用transact发起RPC请求，同时当前线程挂起；然后服务端onTransact方法会被调用，直到RPC过程返回后，当前线程继续执行。
当客户端与服务端的链接断开的时候，客户端一般情况是不知道的，这时候通过Binder设置linkToDeath和unLinkToDeath来获取链接状态。方法是声明并在客户端绑定远程服务的时候设置死亡代理。如下：
private IBinder.DeathRecipient mDeatchRecipient = new IBinder.DeathRecipient() {
@Override
public void binderDied() {
if(mBookManager==null){
return ;
}
mBookManager.asBinder().unLinkToDeatch(mDeatchRecipient,0);
mBookManager = null;
//重新绑定远程服务
}
};
mService = IMessageBoxManager.Stub.asInterface(binder);
binder.linkToDeath(mDeatchRecipient,0);

2.4 Android中的IPC方式

1.使用Bundle
2.使用文件共享
3.使用Messenger
4.使用AIDL

服务端：

服务端首先要创建一个Service用来监听客户端的链接请求，然后创建一个AIDL文件，将暴露给客户端的接口在这个AIDL文件中声明，最后在Service中实现这个AIDL。

客户端：

客户端所要做的事情就稍微简单一些，首先需要绑定服务端的Service，绑定成功后，将服务端返回的Binder对象转换成AIDL接口所属类型，接着就可以调用AIDL中的方法了。

2.5 Binder连接池

每个业务模块创建自己的AIDL接口并实现此接口，这个时候不同的业务模块之间是不能耦合的，所有实现细节我们要单独开来，然后向服务端自己提供的唯一标志和其对应的Binder对象。对于服务端来说，只需要一个Service就可以了，服务端提供了一个queryBinder接口，这个接口能够根据业务模块的特征来返回相应的Binder对象给它们，不同的业务模块拿到所需的Binder对象后就可以进行远程方法的调用了。由此可见，Binder连接池的主要作用就是将每个业务模块的Binder请求统一转发到远程Service中执行，从而避免重复创建Service的过程。

2.6 选择合适的IPC方式

Bundle 简单易用 只能传输Bundle支持的数据类型 四大组件的进程间通信
AIDL 简单易用 功能强大，支持一对多并发通信，支持实时通信。 使用稍微复杂，需要处理好线程同步。 一对多通信且有RPC需求
Messenger 功能一般，支持一对多串行通信，支持实时通信。 不能很好处理高并发情形，不支持RPC，数据通过Messenger进行传输，因此只能传输Bundle支持的数据类型。 低并发的一对多即时通信，无RPC需求，或者无需返回结果的RPC需求
ContentProvider。 在数据源访问功能强大，支持一对多并发数据共享，可通过Call方法展开其它操作。 可以理解为受约束的AIDL，主要支持数据的CRUD操作 一对多的进程间数据共享
Socket 功能强大，可以通过网络传输字节流，支持一对多并发实时通信。实现细节稍微繁琐，不支持直接RPC。 网络数据交换