什么是IPC?
IPC是Inter-Process Communication的缩写，含义为进程间通信或者跨进程之间进行数据交换的过程。说起进程间通信，首先我们要理解什么是进程，什么是线程，进程和线程是截然不同的两个概念。按照操作系统的描述，线程是CPU调度的最小单元，同时线程是一种有限的系统资源。而进程一般指一个执行单元，在PC和移动设备上指一个程序或者一个应用。一个进程可以包含多个进程，因此进程和线程的关系是被包含的关系。
多进程的使用场景：
例如：第一种情况是一个应用某些模块因为特殊的原因需要运行在单独的进程中，又或者为了加大一个应用可使用的内存所以需要通过多进程来获取多份内存空间。 Android对单个应用使用的最大内存做了限制，早期的一些版本可能是16MB,不同的设备有不同的大小。
另一种情况是当前应用需要向其他应用获取数据，由于是两个应用，所以必须采用跨进程的方式来获取所需的数据，甚至我们通过系统提供的ContentProvider去查询数据的时候，也是进程间的一种通信方式。只不过通信的细节被系统内部屏蔽了。
android多进程模式
正常情况下，在android中多进程是指一个应用中存在多个进程的情况，首先在android中使用多进程只有一种办法，那就是给4大组件（Activity,Service,Receiver,ContentProvider）在AndroidManifest.xml中指定android:process属性，除此之外没有其他办法。 也就是说，我们无法给一个线程或一个实体类单独指定其运行时所在的进程。 其实还有另一种非常规的多进程方法，那就是通过JNI在native层去fork出一个新的进程。待补充
下面代码展示如何在android中创建多进程：
上面的示例给SecondActivity和ThirdActivity指定了process属性。并且属性值不同。这意味着当前应用又增加了两个新进程。假设当前应用的包名为"com.ryg.chapter_2",当SecondActivity启动时，系统会为它创建一个单独的进程，进程名为"com.ryg.chapter_2:remote";当ThirdActivity启动的时候，也会为他创建一个单独的进程，进程名为"com.ryg.chapter_2.remote"。同时入口Mainactivity，没有为它指定process属性，那么他就运行在默认的进程中，默认的进程名是包名。 下图是运行效果：
可以看到进程列表中分别有com.ryg.chapter_2，com.ryg.chapter_2:remote，com.ryg.chapter_2.remote 3个不同的进程，而且进程id各不相同。这说明我们的应用成功的使用了多进程技术。
SecondActivity和ThirdActivity的android:process属性分别为":remote"和"com.ryg.chapter_2.remote"，那么这两种方式的区别是什么呢？
两方面：
1.":"的含义是指要在当前的进程名前面附加上当前的包名，这是一种简写的形式。对于SecondActivity它的包名应该是com.ryg.chapter_2:remote。 对应ThirdActivity的属性名为"com.ryg.chapter_2.remote，这是一种完整的命名方式，不会附加包名信息。
2.进程名以":"开头的进程属性当前应用的私有进程，其他应用的组件不可以和它跑在同一个进程中，而进程名不以":"开头的进程属于全局进程，其他应用通过ShareUID方式可以和他跑在同一个进程中。
知识点：
我们知道Android系统会为每个应用分配一个唯一的UID,具有相同的UID的应用才能共享数据，这里要说明的是，两个应用通过ShareUID跑在同一个进程中是有要求的，需要这两个应用有相同的ShareUID并且签名相同才可以。在这种情况下，它们可以互相访问对方的私有数据，比如data目录，组件信息等。不管它们是否跑在同一个进程中。当然如果它们跑在同一个进程中，那么除了能共享data目录，组件信息，还可以共享内存数据，或者说它们看起来就像是是跑在一个应用中的两个部分。
多线程模式的运行机制：
android中的多线程模式有很多的问题，例如：
我们新建一个类叫UserManager，这个类中有一个public的静态变量：
public class UserManager {
public static int sUserId = 1;
}
然后我们在MainActivity中给它赋值为2，打印出来。然后再启动SecondActivity，同样打印它的值。
可以看到，图中的打印结果和我们想象的完全不同。正常情况下SecondActivity中打印的sUserId 应该是2才对。 这就是一个多进程带来的问题。
出现这种情况的原因是SecondActivity运行在一个单独的进程中，我们知道android为每一个应用都分配了一个独立的虚拟机。或者说为每一个进程都分配了一个独立的虚拟机。不同的虚拟机在内存中有不同的地址空间，这就导致了在不同的虚拟机中访问同一个类的对象会产生多份的副本。例如我们的这个例子，在进程"com.ryg.chapter_2"和进程com.ryg.chapter_2:remote中都存在一个UserManager 类，并且这两个类是互不干扰的。在MainActivity中修改了sUserId 的类只是修改了com.ryg.chapter_2进程对应的内存的值。 这也就是解释了为什么SecondActivity类中sUserId 的值没有变化了。
所有运行在不同进程中的四大组件，只要他们之间需要通过内存来共享数据，都会分享失败，这也是多进程所带来的主要影响。正常情况下，四大组件中间不可能不通过一些中间层来共享数据，那么简单地指定指定进程名来开启的多进程都会无法正确运行。当然，特殊情况下，某些组件直接不需要共享数据，这个时候可以通过直接指定进程名来共享数据。但是这种业务场景不常见，几乎所有的情况都需要共享数据。
一般来说，使用多进程会造成如下几方面的影响：
1.静态成员变量和单例模式完全失效
2.线程同步机制完全失效
3.SharePreferences的可靠性下降
4.Application会多次创建
分析
- 第一方面之前已经进行过了分析，不同的进程对应着不同的虚拟机也就对应着不同的地址空间。所以静态成员变量和单例都不是全局唯一的了。
- 第2个问题本质上和第一个问题是类似的，既然都不是一块内存了，那么不管是锁对象还是锁全局类都无法保证线程同步，因为不同进程锁的不是同一对象。
- 第3个问题是因为SharePreferences不支持两个进程同时去执行写操作，否则会导致一定几率的数据丢失，这是因为SharePreference底层是通过读/写XML文件实现的，并发写显然可能出现问题，甚至并发读都有可能出现问题。
- 第4个问题当一个组件跑在一个新的进程中时，由于系统要在创建新的进程同时分配独立的虚拟机，所以这个过程其实就是启动一个应用的过程。因此，相当于系统又把这个应用重新启动了一遍。既然都重新启动了，那么自然就创建了新的Application。这个问题其实可以这么理解，运行在同一个进程中的额组件属于同一个虚拟机和同一个Application的。同理运行在不同进程中的组件是属于两个不同的虚拟机和Application.
下面实例测试一下：
首先在Application的onCreate方法中打印出当前进程的名字，然后连续启动三个同一个应用内属于不同进程的Activity，按照期望，Application的onCreate应用执行三次并打印出三次进程名不同的log，代码如下：
public class MyApplication extends Application {
private static final String TAG = "MyApplication";
@Override
public void onCreate() {
super.onCreate();
String processName = MyUtils.getProcessName(getApplicationContext(),
Process.myPid());
Log.d(TAG, "application start, process name:" + processName);
}
}
运行后的log为：
通过log可以看出，Application执行了三次onCreate，并且每次的进程名称和进程id都不一样，它们的进程名和我们为Activity指定的android:process属性一致。 这也就证明在多进程模式中，不同的进程的组件的确会拥有独立的虚拟机，application以及内存空间。这会给实际的开发带来很多的困恼，是尤其需要注意的。
我们可以这样理解一个应用中的多进程，它就相当于两个不同的应用采用了ShareUID的模式，这样能够更加直接的理解多进程模式的本质。