2.1 Android IPC简介
IPC是inter(间)-process(进程)-Communication(通信)的缩写，含义为进程间通信或者跨进程通信，是指两个进程之间进行数据交换的过程。说起进程间通信，我们首先要理解什么是进程，什么是线程，进程和线程是截然不同的概念。按照操作系统中的描述，线程是CPU调度的最小单元，同时线程是一种有限的系统资源。而进程一般指一个执行单元，在PC和移动设备上指一个程序或者一个应用。一个进程可以包含多个线程，因此进程和线程是包含与被包含的关系。最简单的情况下，一个进程中可以只有一个线程，即主线程，在Android里面主线程也叫UI线程，在UI线程里才能操作界面元素。很多时候，一个进程中需要执行大量耗时的任务，如果这些任务放在主线程中去执行就会造成界面无法响应，严重影响用户体验，这种情况在PC系统和移动系统中都存在，在Android中有一个特殊的名字叫做ANR(Application Not Responding)，即应用无响应。解决这个问题就需要用到线程，把一些耗时的任务放在线程中即可。
IPC不是Android中所独有的，任何一个操作系统都需要有相应的IPC机制，比如Window上可以通过剪贴板、管道和邮槽等来进行进程间通信；Linux上可以通过命名管道、共享内存、信号量等来进行进程间通信。可以看到不同的操作系统平台有着不同的进程间通信方式，对于Android来说，它是一种基于Linux内核的移动操作系统，它的进程间通信方式并不能完全继承自Linux，相反，它有自己的进程间通信方式。在Android中最有特色的进程间通信方式就是Binder了，通过Binder可以轻松地实现进程间通信。除了Binder，Android还支持Socket，通过Socket也可以实现任意两个终端之间的通信，当然同一个设备上的两个进程通过Socket通信自然也是可以的。
说到IPC的使用场景就必须提到多进程，只有面对多进程这种场景下，才需要考虑进程间通信。多进程的情况分为两种。第一种情况是一个应用因为某些原因自身需要采用多进程模式来实现，至于原因，可能有很多，比如有些模块由于特殊原因需要运行在单独的线程中，又或者为了加大一个应用可使用的内存所以需要通过多进程来获取多份内存空间。Android对单个应用所使用的最大内存做了限制，早期的一些版本可能是16MB，不同设备有不同的大小。另一种情况是当前应用需要向其他应用获取数据，由于是两个应用，所以必须采用跨进程的方式来获取所需的数据，甚至我们通过系统提供的ContentProvider去查询数据的时候，其实也是一种进程间通信，只不过通信细节被系统内部屏蔽了，我们无法感知而已。
2.2 Android 中的多进程模式
在正式介绍进程间通信之前，我们必须先要理解Android中的多进程模式。通过给四大组件指定android:process属性，我们可以轻易地开启多进程模式。有时候我们通过多进程得到的好处甚至都不足以弥补使用多进程所带来的代码层面的负面影响。
2.2.1 开启多进程模式
正常情况下，在Android中多进程是指一个应用中存在多个进程的情况，因此这里不讨论两个应用之间的多进程情况。首先，在Android中使用多进程只有一种方法，那就是给四大组件(Activity,Service,Reciver,ContentProvider)在AndroidMenifest中指定android:process属性，除此之外没有其他方法，也就是说我们无法给一个线程或者一个实体类指定其运行时所在的进程。其实还有另一种非常规的多进程方法，那就是通过JNI在native层去fork一个新的进程，但是这种方法属于特殊情况，也不是常用的创建多进程的方式，因此我们暂时不考虑这种方式。
<activity
android:name=".MainActivity"
android:configChanges="orientation|screenSize"
android:launchMode="standard">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
<activity
android:name=".SecondActivity"
android:configChanges="screenLayout"
android:process=":remote"/>
<activity
android:name=".ThirdActivity"
android:configChanges="screenLayout"
android:process="com.example.wumeng.study3.remote"/>
上面的示例分别为SecondActivity和ThirdActivity指定了process属性，并且它们的属性值不同，这意味着当前应用又增加了两个新进程。假设当前应用的包名为com.example.wumeng.study3,当SecondActivity启动时，系统会为它创建一个单独的进程，进程名为com.example.wumeng.study3:remote。当ThirdActivity启动时，系统也会为它创建一个单独的进程，进程名为com.example.wumeng.study3.remote,同时入口Activity是MainActivity，没有为它指定process属性，那么它运行在默认进程中，默认进程的进程名是包名。
查看线程:
com.example.wumeng.study3
com.example.wumeng.study3.remote
com.example.wumeng.study3:remote
SecondActivity和ThirdActivity的android:process属性分别为:remote和com.example.wumeng.study3.remote，那么这两种方式有区别吗？其实是有区别的，区别有两方面：首先:的含义是指要在当前的进程名前面附加上当前的包名，这是一种简写的方法，对于SecondActivity来说，它完整的进程名为com.example.wumeng.study3:remote，而对于ThirdActivity中的声明方式，它是一种完整的命名方式，不会附加包名信息；其次，进程名以:开头的进程属于当前应用的私有进程，其他应用的组件不可以和它跑在同一个进程中。而进程名不以:开头的进程属于全局进程，其他应用通过ShareUID方式可以和它跑在同一个进程中。
我们知道Android系统会为每个应用分配一个唯一的UID，具有相同UID的应用才能共享数据。这里要说明的是，两个应用通过ShareUID跑在同一个进程中是有要求的，需要这两个应用有相同的ShareUID并且签名相同才可以。在这种情况下，它们可以互相访问对方的私有数据，比如data目录、组件信息等，不管它们是否跑在同一个进程中。当然如果它们跑在同一个进程中，那么除了能共享data目录。组件信息，还可以共享内存数据，或者说它们看起来就像是一个应用的两个部分。
2.2.2 多进程模式的运行机制
如果用一句话来形容多进程，那就是"当应用开启了多进程以后，各种奇怪的现象都出现了"。下面先举个例子，其中SecondActivity通过指定android:process属性从而使其运行在一个独立的进程中，这里做了一些改动，我们新建了一个类，叫做UserManager，这个类中有一个public的静态成员变量。
public class UserManager {
public static int sUserId = 1;
}
然后在MainActivity的onCreate中我们把这个sUserId 重新赋值为2，打印出这个静态变量的值后再启动SecondActivity，在SecondActivity中我们再打印一下sUserId 的值，按照正常的逻辑，静态变量是可以在所有的地方共享的，并且一处有修改处处都会同步。
05-24 09:07:26.170 2199-2199/com.example.wumeng.study3 D/WM1: 2
05-24 09:07:27.020 2216-2216/com.example.wumeng.study3:remote D/WM2: 1
从上面的日志可以发现，多进程绝非只是仅仅指定一个android:process属性那么简单。
上述问题出现的原因是SecondActivity运行在一个单独的进程中，我们知道Android为每一个应用分配了一个独立的虚拟机，或者说为每个进程都分配一个独立的虚拟机，不同的虚拟机在内存分配上有不同的地址空间，这就导致在不同的虚拟机中访问同一个类的对象会产生多份副本。拿我们这个例子来说，在进程com.example.wumeng.study3和com.example.wumeng.study3:remote中都存在一个UserManager 类，并且这两个类是互不干扰的，在一个进程中修改sUserId的值，只会影响当前进程，对其他进程不会造成任何影响，这样我们就可以理解为什么MainActivity中修改了sUserId的值，但是在SecondActivity中sUserId的值却没有发生改变这个现象。
所有运行在不同进程中的四大组件，只要它们之间需要通过内存来共享数据，都会共享失败，这也是多进程所带来的主要影响。正常情况下，四大组件中间不可能不通过一些中间层来共享数据，那么通过简单地指定进程名来开启多进程都会无法正确运行。当然，特殊情况下，某些组件之间不需要共享数据，这个时候可以直接指定android:process属性来开启多进程，但是这种情景是不常见的，几乎所有情况都需要共享数据。
一般来说，使用多进程会造成如下几方面的问题：
- 静态成员和单例模式完全失效
- 线程同步机制完全失效
-
SharedPreferences的可靠性下降 -
Application会多次创建
第一个问题在上面已经进行了分析。第二个问题本质上和第一个问题是类似的，既然都不是一块内存了，那么不管是锁对象还是锁全局类都无法保证线程同步，因为不同进程锁的不是同一个对象。第三个问题是因为SharedPreferences不支持两个进程同时去执行写操作，否则会导致一定几率的数据丢失，这是因为SharedPreferences底层是通过读写XML文件来实现的，并发写显然是可能出问题的，甚至并发读写都有可能出问题。第四个问题也是显而易见的，当一个组件跑在一个新的进程中的时候，由于系统要在创建新的进程同时分配独立的虚拟机，所以这个过程其实就是启动一个应用的过程。因此，相当于系统又把这个应用重新启动了一遍，既然重新启动了，那么自然会创建新的Application。这个问题其实可以这么理解，运行在同一个进程中的组件是属于同一个虚拟机和同一个Application的，同理，运行在不同进程中的组件是属于两个不同的虚拟机和Application的。
在多进程模式中，不同进程的组件的确会拥有独立的虚拟机、Application以及内存空间，这会给实际的开发带来很多困恼，是尤其需要注意的。或者我们也可以这么理解同一个应用间的多进程:它就相当于两个不同的应用采用了SharedUID的模式，这样能够更加直接地理解多进程模式的本质。
实现跨进程通信的方式很多，比如通过Intent来传递数据，共享文件和SharedPreferences，基于Binder的Messenger和AIDL以及Socket等，但是为了更好地理解各种IPC方式，我们需要先熟悉一些基础概念，比如序列化相关的Serializable和Parcelable接口，以及Binder的概念，熟悉完这些基础概念以后，再去理解各种IPC方式就比较简单了。
