（二十二） IPC机制通讯

IPC是Inter-Process Communication的缩写。

多进程简介

Android对单个应用的内存做了限制，早期版本可能是16M。

通过给四大组建指定Android：process属性，开启多线程模式，无其他方法。特殊情况通过jni在native层fork一个新的进程。

进程以“：”开头的是当前进程的私有进程，其他组件不能和他跑在同一进程，全称是“：”前加包名；而进程名不以“：”开头的进程属于全局进程，其他进程可以通过ShareUID的方式和他跑在同一个进程。

android为每一个应用（进程）都分配了一个独立的虚拟机，不同虚拟机在内存上有不同的地址，导致在不同虚拟机中访问同一个类的对象会产生多个副本。

多进程产生的问题：

1.静态变量和单例模式失效。

2.线程同步机制失效

3.SharedPreferences失效。

4.Application会创建多次。

多进程模式下，不同进程的组件确实会有独立的虚拟机、Application以及内存空间。

IPC基本概念

Serializable接口

实现这个接口，并设置SerializableUID，就可以实现序列化和反序列化。SerializableUID的作用是校验类的版本是否改变。当UID不同时，反序列化会失败。当类的结构发生改变时，即使UID一样，反序列化也会失败。

注:静态变量属于类，不参与序列化过程，被transient关键字标记的成员变量不参与序列化过程。

Parcelable接口

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

实现此接口中的方法，

describeContents（）方法，返回文件描述，有就返回1，无就返回0，一般是0.

writeToParcel()方法，实现序列化功能，一系列的write方法。

Creator()对象中的createFromParcel（）方法，从序列化后的对象中创建原对象。newArray（）方法，创建指定长度的原始对象数组。

两种方法的选择：Android推荐Parcelable方式，但在将对象序列化到存储设备和通过网络传输时，推荐使用Serializable接口方式。

Binder

实现了IBinder接口。

在系统生成的Binder类文件是一个继承了IInterface的接口，该接口中有一个Stub的Binder抽象类实现该接口，在Stub类里又有一些方法和内部代理类，各个方法的作用：

DESCRIPTION：Binder的唯一标识，一般是当前Binder的类名。

asInterface：将服务端的Binder对象转化为客户端所需的AIDL接口类型的对象，此处是分进程的，若客户端和服务端在同一进程，返回的是服务端的Stub对象本身，否则返回系统封装后的Stub.Proxy对象。

asBinder：返回当前的Binder对象。

onTransact：运行在服务端的Binder线程池中，当客户端发起请求，远程请求会通过底层封装后交由此方法处理。服务端通过code判断目标方法，目标方法执行完毕后向reply中写入返回值（若有）。此方法若返回false，客户端请求失败。

内部代理类Proxy中的方法

Proxy#getBook

创建该方法所需要的data、reply等Parcel对象，把该方法的参数信息写入data（若有），接着调用transact方法发起RPC请求，当前线程挂起，服务端的onTransact方法会被调用，直至服务端返回结果，从reply中取出返回的结果返回。

binder发生连接断裂时，用到两个方法linkToDeath、unlinkToDeath。声明一个DeathRecipient对象，在binderDied方法里移除断裂的服务，绑定新的服务。

Android中的IPC方式

1.使用Bundle，Bundle实现了Parcelable接口。

2.使用文件共享

3.使用Messager，底层实现是AIDL。使用Messager传递数据必须将数据放入Message中，Message和Messager都实现了Parcelable接口。

4.使用AIDL方式。在客户端和服务端定义aidl文件，使用bindService方法。

5.ContentProvider方式。底层实现也是Binder。可以配合sqlite数据库使用。

6.Socket方式。