android IPC机制

总结梳理顺序:IPC简介、android多进程模式、Serializable、Parcelable、binder、IPC方式、binde连接池。

1.IPC简介

进程间通讯。

2.android多进程模式

指定android:process开启多进程方式。(冒号:私有进程，点：全局进程，允许不同应用运行在此进程，当然此应用有相应的权限)

        ①.多进程运行机制：会为每个进程都分配一个独立的虚拟机，不同的虚拟机在内存分配上会有不同的地址空间，这就导致在不同的虚拟机中访问同一个类的对象会产生不同的副本。

        ②.产生的问题：

（1）静态成员和单例模式完全失效。(原因：同上)

（2）线程同步机制完全失效。(不同的对象所以同步锁失效)

（3）SharedPreferences的可靠性降低。(并发写会出现问题)

（4）Application会创建多个。(不同进程会有独立的虚拟机、Application以及内存空间)

3.IPC基础概念

序列化、Serializable、Parcelable、binder。

①.序列化：对象的状态信息转换为可以存储或传输的形式的过程。

②.Serializable：java提供的序列化方式。

    (1)实现：类继承Serializable接口，添加常量serialVersionUID,此类就可以进行序列化和反序列化操作了。

    (2)过程：通过反射，在流的过程中产生大量的临时对象，因此造成了大量的GC。

    (3)serialVersionUID是反序列化过程中需要匹配的值，所以需要给此赋值。

③.Parcelable：android提供的序列化方式。

    (1)实现：类继承Parcelable接口，并实现序列化、反序列化、内容描述的过程。过程较为复杂。

    (2)优点:效率高。

总结：Parcelable效率高，在内存序列化上推荐Parcelable；Serializable实现较为简单，在序列化到存储设备和网络传输中推荐使用Serializable。

④.binder:binder是Android的一个类，他实现了IBinder接口，从IPC角度来说，Binder是Android跨进程通讯的方式。

    （1）原理是基于binder的跨进程通讯方式：AIDL、Messenger、ContentProvider。

    （2）源码解析可得流程图：

    (3)当服务端因为某些原因异常终止了，导致binder连接断裂，这时候可以用linkToDeath方法和UnLinkToDeath方法监听binder是否连接异常。

4.android中的IPC方式

    (1)使用Bundle。

    (2)使用文件共享。

    (3)使用网络传输。

    (4)使用Messenger:本质是binder

        服务端流程:创建Handler并通过它创建Messenger对象，然后在Service的onBinder中返回这个messenger底层的 binder即可。

        客户端流程:首先客户端绑定服务端的Service，然后返回IBinder对象创建Messenger，通过Messenger可以向服务端发送消息，如果需要服务端向客户端发送消息可以通过replyTo这个参数将客户端的Messenger发送给服务端，这样服务端可以通过此Messenger发送消息给客户端。

     (5)使用AIDL:本质是binder

         注意事项:

         ①.传递的只支持方法。

         ②.客户端和服务端不在一个应用需要将AIDL文件客户端和服务端各有一份，并且AIDL的包结构服务端和客户端要保持一致，否则反序列化就无法完成，程序也不能正常运行。

         ③.AIDL的方法是在服务端的线程池中执行的，要注意多客户端并发读写操作。(可以用CopyOnWriteArrayList和ConcurrentHashMap支持并发读写)。还要注意客户端调用的方法会耗时，所以一般不要在主线程中调用。

         ④.给服务端添加观察者模式传统方式对象是不同的，所以不能用传统模式。虽然对象不同但是对象的binder是相同    的，所以可以用RemoteCallbackList这个方法。

         ⑤.Binder异常断开可以在DeathRecipient中重连，也可以在onServiceDisConnected中重新连接。

    (6)使用ContentProvider:本质是binder

最后是几种IPC方式的对比图：

RPC:远程过程调用。