Ipc即为跨进程间通信，既然涉及到进程间通信，必然是多进程；

Andorid中的多进程

Android中多进程分为一个应用中不同组件在不同进程中和需要进行跨进程或者是跨应用进行数据交换和获取两种情况。
将Android应用变为多进程应用只需要在其组件中指定android:process属性，还有种方法就是通过JNI在native层fork一个进程。
这里有一个关于多进程的tips.

• 指定的进程名以“:”开头：表明当前进程为私有进程，其他应用组件不能和它允许在一个进程，
• 而进程名不以”:”开头的进程属于全局进程，其他应用通过ShareUID方式可以和它跑在同一个进程中。
• Android系统为每个应用分配唯一的UID,UID相同才能共享数据。
• 两个应用通过ShareUID跑在同一个进程中是有要求的，需要这两个应用有相同的ShareUID并且签名相同才可以。如果它们跑在同一个进程中，那么除了能共享data目录、组件信息，还可以共享内存数据，或者说它们看起来就像是一个应用的两个部分。

多进程模式的运行机制

Android为每个应用分配一个独立的虚拟机，即每个进程分配独立的虚拟机，不同的虚拟机在不同的内存分配有不同的地址空间，因此会导致不同的虚拟机上访问同一个类的对象会产生不同的副本，因此在不同进程的四大组件通过内存进行数据共享都会失败。
因此在Android中使用多进程需要注意以下几点：

• 静态成员和单例失效
• 线程同步机制失效
• sp可靠性下降(SharedPreferences不支持两个进程同时去执行写操作，否则会导致一定几率的数据丢失，这时因为SharedPreferences底层是通过读写XML文件来实现的，并发写显然是可能出问题的，甚至并发读写都有可能发生问题,且在内存中会有缓存)
• Application会多次创建

Android中的序列化

• Serializable
  这种序列化方式是Java提供的，通过这种方式实现序列化是非常简单的，只需要实现Serializable接口，并指定一个serialVersionUID即可。
  通过反序列化可以得到和序列化前完全一样的对象，但是其实是两个不同的对象。

原则上序列化后的数据中的serialVersionUID只有和当前类的serialVersionUID相同时才能够正常的被反序列化。
serialVersionUID的详细工作机制：序列化的时候系统会把当前类的serialVersionUID写入序列化的文件中（也可能是其他的中介），当反序列化的时候系统会去检测文件中的serialVersionUID，看它是否和当前类的serialVersionUID一致，如果一致就说明序列化的类的版本和当前类的版本是相同的，这个时候可以成功反序列化，否则就说明当前类和序列化的类相比发生了某些变换.

• 静态成员变量属于类不属于对象，所以不会参与序列化过程
• 其次用transient关键字标记的成员变量不参与序列化过程
• 要重写writeObject、readObje可以改变序列化过程

• Parcelable
  系统已经为我们提供了许多实现了Parcelable接口的类，它们都是可以直接序列化的，比如Intent、Bundle、Bitmap等，同时List和Map也可以序列化，前提是它们里面的每个元素都是可序列化的。

方法	功能	标记位
createFromParcel(Parcel in)	从序列化的对象中创建原始对象
newArray[int size]	创建指定长度的原始对象数组
User(Parcel in)	从序列化的对象中创建原始对象
write ToParcel(Parcel out, int flags)	将当前对象写入序列化结构中，其中flags标识有两种值0或1（参见右侧标记位）。为1时标识当前对象需要作为返回值返回，不能立即释放资源，几乎所有情况都为0	PARCELABLE_WRITE_RETURN_VALUE
describeContents	返回当前对象的内容描述。如果含有文件描述符，返回1（参见右侧标记位），否则返回0，几乎所有的情况都返回0	CONTENTS_FILE_DESCRIPTOR

• 两种方式的区别
  Serializable是Java中的序列化接口，其使用起来简单但是开销很大，序列化和反序列化需要大量I/O操作。而Parceleble是Android中的序列化方式，因此更适合在Android平台上，缺点是麻烦，但是效率高，这是Android推荐的序列化方式，所以我们要首选Parcelable。Parcelable主要用在内存序列化上，通过Parcelable将对象序列化到存储设备中或者将对象序列化之后通过网络传输，但是过程稍显复杂，因此在这两种情况下建议大家使用Serializable。

Binder

继承IBinder,是一种跨进程通信方式，是ServiceManager连接各种Manager（ActivityManager,WindowManager等）和相应ManagerService的桥梁，从Android应用层来说，Binder是客户端和服务端进行通信的媒介，当bindService的时候，服务器会返回一个包含了服务器端业务调用的Binder对象，通过这个Binder对象，客户端就可以获取服务端提供的服务或者是数据，这里的服务包含了普通服务和基于AIDL的服务。

• asInterface(android.os.IBinder obj):用于将服务器端的Binder对象转化成客户端所需的AIDL接口类型的对象，这种转换过程是区分进程的，如果客户端和服务端是在同一进程中，那么这个方法返回的是服务端的Stub对象本身，否则返回的是系统封装的Stub.Proxy对象。
• asBinder:返回当前Binder对象
• onTransact：这个方法运行在服务端中的Binder线程池中，当客户端发起跨进程请求时，远程请求会通过系统底层封装后交由此方法来处理。
  这个方法的原型是public Boolean onTransact(int code, Parcelable data, Parcelable reply, int flags)
  服务端通过code可以知道客户端请求的目标方法，接着从data中取出所需的参数，然后执行目标方法，执行完毕之后，将结果写入到reply中。如果此方法返回false，说明客户端的请求失败，利用这个特性可以做权限验证(即验证是否有权限调用该服务)。
• Proxy [Method]：代理类中的接口方法，这些方法运行在客户端，当客户端远程调用此方法时，它的内部实现是：首先创建该方法所需要的参数，然后把方法的参数信息写入到_data中，接着调用transact方法来发起RPC请求，同时当前线程挂起；然后服务端的onTransact方法会被调用，直到RPC过程返回后，当前线程继续执行，并从_reply中取出RPC过程的返回结果，最后返回_reply中的数据。

首先，当客户端发起远程请求时，由于当前线程会被挂起直至服务端进程返回数据，所以如果一个远程方法是很耗时的，那么不能在UI线程发起此远程请求；其次，由于服务端的Binder方法运行在Binder的线程池中，所以不管Binder是否耗时都应该采用同步的方式去实现，因为它已经运行在一个线程中了。

Binder两种重要的方法

• linkToDeath
• unlinkToDeath
  Binder运行在服务端，如果由于某种服务端异常终止了的话会导致客户端的远程调用失败、所以Binder提供了两个配对的方法linkToDeath和unlinkToDeath，通过linkToDeath方法可以给Binder设置一个死亡代理，当Binder死亡的时候客户端就会收到通知，然后就可以重新发起连接从而恢复连接了。

如何给Binder设置死亡代理

1、声明一个DeathRecipient对象、DeathRecipient是一个接口，其内部只有一个方法bindDied，实现这个方法就可以在Binder死亡的时候收到通知了。

private IBinder.DeathRecipient mDeathRecipient = new IBinder.DeathRecipient() {
    @Override
    public void binderDied() {
        if (mRemoteBookManager == null) return;
        mRemoteBookManager.asBinder().unlinkToDeath(mDeathRecipient, 0);
        mRemoteBookManager = null;
        // TODO:这里重新绑定远程Service
    }
};

2、在客户端绑定远程服务成功之后，给binder设置死亡代理

mRemoteBookManager.asBinder().linkToDeath(mDeathRecipient, 0);

Android的IPC方式

• 使用Bundle

Bundle实现了Parcelable接口，Activity、Service和Receiver都支持在Intent中传递Bundle数据

• 使用文件共享

这种方式简单，适合在对数据同步要求不高的进程之间进行通信，并且要妥善处理并发读写的问题，SharedPreferences是一个特例，虽然它也是文件的一种，但是由于系统对它的读写有一定的缓存策略，即在内存中会有一份SharedPreferences文件的缓存，因此在多进程模式下、系统对它的读写就变的不可靠，当面对高并发读写访问的时候，有很大几率会丢失，因此，不建议在进程间通信中使用SharedPreferences。

• 使用Messenger
  Messenger是一种轻量级的IPC方案，它的底层实现就是AIDL。Messenger是以串行的方式处理请求的，即服务端只能一个个处理，不存在并发执行的情形。
• 使用AIDL
  大致流程：首先建一个Service和一个AIDL接口，接着创建一个类继承自AIDL接口中的Stub类中的抽象方法，在Service的onBind方法中返回这个类的对象，然后客户端就可以绑定服务端Service，建立连接后就可以访问远程服务端的方法了。
  1.AIDL支持的数据类型：基本数据类型、String和CharSequence、ArrayList、HashMap、Parcelable以及AIDL；
  2.某些类即使和AIDL文件在同一个包中也要显式import进来；
  3.AIDL中除了基本数据类，其他类型的参数都要标上方向：in、out或者inout；
  4.AIDL接口中支持方法，不支持声明静态变量；
  5.为了方便AIDL的开发，建议把所有和AIDL相关的类和文件全部放入同一个包中，这样做的好处是，当客户端是另一个应用的时候，可以直接把整个包复制到客户端工程中。
  6.RemoteCallbackList是系统专门提供的用于删除跨进程Listener的接口。RemoteCallbackList是一个泛型，支持管理任意的AIDL接口，因为所有的AIDL接口都继承自IInterface接口。
• 使用ContentProvider
  1.ContentProvider主要以表格的形式来组织数据，并且可以包含多个表；
  2.ContentProvider还支持文件数据，比如图片、视频等，系统提供的MediaStore就是文件类型的ContentProvider；
  3.ContentProvider对底层的数据存储方式没有任何要求，可以是SQLite、文件，甚至是内存中的一个对象都行；
  4.要观察ContentProvider中的数据变化情况，可以通过ContentResolver的registerContentObserver方法来注册观察者；

使用Socket

套接字，分为流式套接字和用户数据报套接字两种，分别对应于网络的传输控制层中TCP和UDP协议。

• TCP协议是面向连接的协议，提供稳定的双向通信功能，TCP连接的建立需要经过”三次握手”才能完成，为了提供稳定的数据传输功能，其本身提供了超时重传功能，因此具有很高的稳定性
• UDP是无连接的，提供不稳定的单向通信功能，当然UDP也可以实现双向通信功能，在性能上，UDP具有更好的效率，其缺点是不保证数据能够正确传输，尤其是在网络拥塞的情况下。

Binder连接池

• 当项目规模很大的时候，创建很多个Service是不对的做法，因为service是系统资源，太多的service会使得应用看起来很重，所以最好是将所有的AIDL放在同一个Service中去管理。整个工作机制是：每个业务模块创建自己的AIDL接口并实现此接口，这个时候不同业务模块之间是不能有耦合的，所有实现细节我们要单独开来，然后向服务端提供自己的唯一标识和其对应的Binder对象；对于服务端来说，只需要一个Service，服务端提供一个queryBinder接口，这个接口能够根据业务模块的特征来返回相应的Binder对象给它们，不同的业务模块拿到所需的Binder对象后就可以进行远程方法调用了。
  Binder连接池的主要作用就是将每个业务模块的Binder请求统一转发到远程Service去执行，从而避免了重复创建Service的过程。
• 建议在AIDL开发工作中引入BinderPool机制。