1、Android IPC简介
本章主要讲解Android的IPC机制，首先介绍Android中的多进程概念以及多进程开发模式中常见的注意事项，接着介绍Android中的序列化机制和Binder，然后详细的介绍Bundle,文件共享，AIDL，Messenger,ContentProvider和Socket等进程间通讯的方式。为了更好的使用AIDL进行进程间通讯，本章引入了Binder连接池的概念，最后，本章讲解各种进程间通信方式的优缺点和使用场景。通过本章，可以让读者对Android中的IPC机制和多线程开发模式有深入的理解。
IPC是Inter-Process Communication的缩写，含义是进程间通信或者跨进程通信，是指两个进程间进行数据交互的一个过程。说起进程间通信，我们首先要理解什么是进程，什么是线程，进程和线程是截然不同的概念。按照操作系统中的描述，线程是CPU调度的最小单元，同时线程是一种有限的系统资源。而进程一般指一个执行单元，在PC和移动设备上指一个程序或者一个应用。一个进程可以包含多个线程，因此进程和线程是包含与被包含的关系。最简单的情况下，一个进程中可以只有一个线程，即主线程，在Android里面主线程也叫UI线程，在UI线程里才能操作界面元素。很多时候，一个进程中需要执行大量耗时的任务，如果这些任务放在主线程中去执行就会造成界面无法响应，严重影响用户体验，这种情况在PC系统和移动系统中都存在，在Android中有一个特殊的名字叫做ANR(Application Not Responding)，即应用无响应。解决这个问题就需要用到线程，把一些耗时的任务放在线程中即可。
IPC不是Andrord中所独有的，任何一个操作系统都需要有相应的IPC机制，比如Windows上可以通过剪贴板、管道和邮槽等来进行进程间通信，、Linux上可以通过命名管道，共享内容、信号量等来进行进程间通信。可以看到不同的操作系统系统有着不同的进程通信方式，对于Android来说，它是一种基于Linux内核的操作系统，他的进程间通信方式并不能完全继承自Linux，相反，它有自己的进程间通信方式。在Android中最
有特色的进程间通信方式就是Binder了，通过Binder可以轻松地实现进程间通信。除了有特色的Binder,Android还支持Socket，通过Socket也可以实现任意两个终端之间的通信，当然同一个设备上的两个进程通过Socket通信自然也是可以的。
说到IPC的使用场景就必须提到多进程，只有面对多进程这种场景下，才需要考虑进程间通信。这个是很好理解的，如果只有一个进程在运行，又何谈多进程呢？多进程的情况分为两种。第一种情况是一个应用因为某些原因自身需要采用多进程模式来实现，至于原因，可能有很多，比如有些模块由于特殊原因需要运行在单独的进程中，又或者为了加大一个应用可使用的内存所以需要通过多进程来获取多份内存空间。Android对单个应用所
使用的最大内存做了限制，早期的一些版本可能是16MB，不同设备有不同的大小。另一种情况是当前应用需要向其他应用获取数据，由于是两个应用，所以必须采用跨讲程的方式来获取所需的数据，甚至我们通过系统提供的ContentProvider去查询数据的时候，其实也是一种进程间通信，只不过通信细节被系统内部屏蔽了，我们无法感知而已，后续的章节我们会详细的介绍ContentProvider的底层实现，这里就先不做介绍了，总之，不管我们处于何种原因，我们采用了多进程的设计方法，那么应用中就必须妥善地处理进程间通信的各种问题了。
2、Android中的多进程模式
在正式介绍进程间通信之前，我们必须先去理解Android中的多进程模式，通过给四大组件指定android:process属性，我们可以轻易的开启多进程模式。这看起来很简单，但是实际使用过程中却暗藏杀机，多进程远远没有我们想的那么简单，有时候我们可以通过多进程得到的好处甚至都不足以弥补使用多进程所带来的代码层面的负面影响，下面会详细分析这些问题。
开启多进程模式
正常情况下，在Android中多进程是指一个应用中存在多个进程的情况，因此这里不讨论两个应用之间的情况，首先在Android中使用多进程只有一种方法，那就是给四大组件指定android:process,除此之外，没有其他办法，也就是说我们无法给一个线程或者实体类指定其运行时所在的进程。其实还有一种非常规的多进程方法，那就是通过JNI在native层去fork一个新的进程，但是这种方法属于特殊情况，也不是常用的创建多进程的方式，因此我们暂时不考虑这种方式，下面是一个实例，描述了如何在Android中创建多进程：
<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" />//方式1
<activity
android:name=".ThirdActivity"
android:configChanges="screenLayout"
android:process="com.example.chapter_2.remote" />//方式2
上面的示例分别为SecondActivity和ThirdActivity指定了process属性，并且他们的属性值不同，这意味着当前应用又增加了两个新进程。假设当前应用的包名为"com.example.chapter_2"，当SecondActivity启动时，系统会为它创建一个单独的进程，进程名为com.example.chapter_2:remote；当ThridActivity启动的时候，系统也会为他创建一个单独的进程，进程名com.example.chapter_2.remote。同时，入口Activity是MainActivity，没有为它指定process属性，那么它运行在默认进程中，默认的进程名称是包名。当我们运行的时候就可以看到，进程列表末尾存在三个进程，这说明我们成功的开启了多进程，是不是很简单呢？这只是一个开始，实际上多进程是有很多问题需要处理的
3、多进程模式的运行机制
如果用一句话来形容多进程，那笔者只能这样说：“当应用开启了多进程以后，各种奇怪的现象都出现了”，为什么这么说呢？这是有原因的。大部分人都认为开启多进程是很简单的事情，只需要给四大组件指定android:process属性即可。比如说在实际的产品开发中，可能会有多进程的需求，需要把某些组件放在单独的进程中去运行，很多人都会觉得这不很简单吗？然后迅速地给那些组件指定了android:process属性，然后编译运行，发现“正常地运行起来了”。这里笔者想说的是，那是真的正常地运行起来了吗?现在先不置可否，下面先给举个例子，然后引入本节的话题。还是本章刚开始说的那个例子，其中SecondActvity通过指定android:process属性从而使其运行在一个独立的进程中，这里做了一些改动，我们新建了一个类，叫做UserManager，这个类中有一个public的静态成员变量，如下所示。
public class UserManager {
public static int sUserId = 1;
}
然后在MainActivity 的 onCreate中我们把这个sUserId 重新赋值为2，打印出这个静态变量的值后再启动SecondActivity，在SecondActivity中我们再打印一下sUserId 的值。按照正常的逻辑，静态变量是可以在所有的地方共享的，并且一处有修改处处都会同步，下面是运行时所打印的日志，我们看一下结果如何
发现结果和我们想的完全不一致，正常情况下SecondActivily打印的sUserId 的值应该是2才对，但是从日志上看它竟然还是1，可是我们的确已经在MainActivitv中把sUserId 重新赋值为2了。看到这里，大家应该明白了这就是多进程所带来的问题，多进程绝非只是仅仅指定一个android：process属性那么简单。
一般来说，使用多进程会造成如下几方面的问题：
- （1）静态成员和单例模式完全失效。
- （2）线程同步机制完全失效。
- （3）SharedPreferences的可靠性下降。
- （4）Application会多次创建。
第1个问题在上面已经进行了分析。第2个问题本质上和第一个问题是类似的，既然都不是一块内存了，那么不管是锁对象还是锁全局类都无法保证线程同步，因为不同进程锁都不是同一个对象。第3个问题是因为SharedPreferences不支持两个进程同时去执行写操作，否则会导致一定几率的数据丢失，这是因为SharedPreferences底层是通过读/写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 = getProcessName();
Log.d(TAG, "process name :" + processName);
}
private String getProcessName() {
int pid = android.os.Process.myPid();
ActivityManager mActivityManager = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE);
for (ActivityManager.RunningAppProcessInfo appProcess : mActivityManager
.getRunningAppProcesses()) {
if (appProcess.pid == pid) {
return appProcess.processName;
}
}
return null;
}
}
