Android IPC机制

一，概念

1. IPC全称Inter-Process Communication，意思是进程间通信或者跨进程通信，是指两个进程之间进行数据交换的过程。
2. 什么是线程？线程是CPU调度的最小单元，同时线程是一种有限的系统资源。
3. 什么是进程？一般指一个执行单元，在PC和移动设备上指一个程序或者一个应用。注：安卓其实一个应用也可以实现多进程
4. 一个进程可以包含多个线程，一个进程也可以只有一个线程，即主线程。在安卓中，主线程又被成为UI线程。一般来说在UI线程中才能操作界面元素。耗时操作不能在UI线程执行，要放到子线程中去执行，否则会导致ANR（Application Not Responding），即应用无响应。
5. 多进程的两种情况：
   5.1 第一种情况是一个应用因为某些原因自身需要采用多进程模式来实现，至于原因，可能有很多，比如有些模块由于特殊原因需要运行在单独的进程中，又或者为了加大一个应用可使用的内存所以需要通过多进程来获取多份内存空间。注：安卓对单个应用所能使用的最大内存做了限制，早期是16M，根据机型限制又有不同
   5.2 另一种情况是当前应用需要向其他应用获取数据，由于是两个应用，所以必须采用跨进程的方式来获取所需的数据，甚至我们通过系统提供的ContentProvider去查询数据的时候，其实也是一种进程间通信，只不过通信细节被系统内部屏蔽了，我们无法感知而已。

二，如何安卓中的多进程模式以及会出现的问题

1. 开启多进程：在安卓中给四大组件开启多进程只有一个办法，在清单文件中对应的四大组件标签内加上android:process属性。例如：

<activity
    android:name="com.ryg.chapter_2.SecondActivity"
    android:configChanges="screenLayout"
    android:label="@string/app_name"
    android:process=":remote" />
<activity
    android:name="com.ryg.chapter_2.ThirdActivity"
    android:configChanges="screenLayout"
    android:label="@string/app_name"
    android:process="com.ryg.chapter_2.remote" />

上面指定进程的一点区别，SecondActivity的process属性值是:开头的，那么进程的名称会自动拼接上包名，即SecondActivity所在的进程名称是com.ryg.chapter_2:remote，而ThirdActivity的进程名称则是它process属性值。注意：其次，进程名以“:”开头的进程属于当前应用的私有进程，其他应用的组件不可以和它跑在同一个进程中，而进程名不以“:”开头的进程属于全局进程，其他应用通过ShareUID方式可以和它跑在同一个进程中。
注：Android系统会为每个应用分配一个唯一的UID，具有相同UID的应用才能共享数据。两个应用通过ShareUID跑在同一个进程中是有要求的，需要这两个应用有相同的ShareUID并且签名相同才可以。在这种情况下，不管它们是否跑在同一个进程中，它们可以互相访问对方的私有数据，比如data目录、组件信息等。当然如果它们跑在同一个进程中（感觉其实就是单进程了，或者说是一个应用了），那么除了能共享data目录、组件信息，还可以共享内存数据，或者说它们看起来就像是一个应用的两个部分。

2. 多进程由于不会共享内存，私有数据等原因，一般来说会造成以下问题：
   （1）静态成员和单例模式完全失效。原因：Android为每一个应用分配了一个独立的虚拟机，或者说为每个进程都分配一个独立的虚拟机，不同的虚拟机在内存分配上有不同的地址空间，这就导致在不同的虚拟机中访问同一个类的对象会产生多份副本。即在这个进程中修改了某个静态变量的值在另一个进程中是不受影响的。
   （2）线程同步机制完全失效。原因：和第一个问题是类似的，既然都不是一块内存了，那么不管是锁对象还是锁全局类都无法保证线程同步，因为不同进程锁的不是同一个对象。
   （3）SharedPreferences的可靠性下降。原因：因为SharedPreferences不支持两个进程同时去执行写操作，否则会导致一定几率的数据丢失，这是因为SharedPreferences底层是通过读/写XML文件来实现的，并发写显然是可能出问题的，甚至并发读/写都有可能出问题。
   （4）Application会多次创建。原因：当一个组件跑在一个新的进程中的时候，由于系统要在创建新的进程同时分配独立的虚拟机，所以这个过程其实就是启动一个应用的过程。因此，相当于系统又把这个应用重新启动了一遍，既然重新启动了，那么自然会创建新的Application。

三，IPC基础概念介绍

主要包含三方面内容：Serializable接口、Parcelable接口以及Binder。Serializable和Parcelable接口可以完成对象的序列化过程，当我们需要通过Intent和Binder传输数据时就需要使用Parcelable或者Serializable。

1. Serializable接口：在Java中一个Java类实现这个接口就可以完成序列化和反序列化的操作。这是一个空接口，即你不需要任何实现。实现接口后，序列化与反序列化代码如下：

//序列化过程
User user = new User(0,"jake",true);
ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("cache.txt"));
out.writeObject(user);
out.close();
//反序列化过程
ObjectInputStream in = new ObjectInputStream(new FileInputStream("cache.txt"));
User newUser = (User) in.readObject();
in.close();

实现Serializable接口进行序列化和反序列化的操作你可能需要指定serialVersionUID，它是一个Long类型的静态常量。指定有什么作用？序列化的时候系统会把当前类的serialVersionUID写入序列化的文件中（也可能是其他中介），当反序列化的时候系统会去检测文件中的serialVersionUID，看它是否和当前类的serialVersionUID一致，如果一致就说明序列化的类的版本和当前类的版本是相同的，这个时候可以成功反序列化；否则就说明当前类和序列化的类相比发生了某些变换，这时候就无法正常反序列化，会报错。推荐手动加上这个值，可以极大避免反序列化失败而导致应用崩溃。如果不指定，IDE一般会根据当前类生成Hash值赋给serialVersionUID。如果类的结构发生变动等等原因造成类的Hash值发生改变，就增大了反序列化失败的风险。注：静态变量属于类，不属于对象，所以静态变量不会参与序列化反序列化过程；其次用transient关键字标记的成员变量不参与序列化过程。

2. Parcelable接口：这是Android推出的适合安卓的序列化方式，使用起来对于Serializable更麻烦一点。实现了这个接口的类就可以通过Intent和Binder来进行传递了。AndroidStudio已经可以自动重写实现了这个接口的类所需要实现的方法，已经省事很多了。注：系统已经为我们提供了许多实现了Parcelable接口的类，它们都是可以直接序列化的，比如Intent、Bundle、Bitmap等，同时List和Map也可以序列化，前提是它们里面的每个元素都是可序列化的
3. Binder：它是Android中的一个类，它实现了IBinder接口。从IPC角度来说，Binder是Android中的一种跨进程通信方式。Android开发中，Binder主要用在Service中，包括AIDL和Messenger，其中普通Service中的Binder不涉及进程间通信，这里Messenger的底层是AIDL。文字太多，不好表达，直接上示例项目地址：点我前往示例项目
   Binder工作机制
   注：我们完全可以不提供AIDL文件即可实现Binder，之所以提供AIDL文件，是为了方便系统为我们生成代码。AIDL文件的本质是系统为我们提供了一种快速实现Binder的工具。
   Binder的两个很重要的方法linkToDeath和unlinkToDeath。Binder运行在服务端进程，如果服务端进程由于某种原因异常终止，这个时候我们到服务端的Binder连接断裂（称之为Binder死亡），会导致我们的远程调用失败。更为关键的是，如果我们不知道Binder连接已经断裂，那么客户端的功能就会受到影响。为了解决这个问题，Binder中提供了两个配对的方法linkToDeath和unlinkToDeath，通过linkToDeath我们可以给Binder设置一个死亡代理，当Binder死亡时，我们就会收到通知，这个时候我们就可以重新发起连接请求从而恢复连接。