#### 2.2.2 多进程模式的运行机制 如果用一句话来形容多进程，那笔者只能这样说：“**当应用开启了多进程以后，各种奇怪的现象都出现了**”。为什么这么说呢？这是有原因的。大部分人都认为开启多进程是很简单的事情，只需要给四大组件指定android:process属性即可。比如说在实际的产品开发中，可能会有多进程的需求，需要把某些组件放在单独的进程中去运行，很多人都会觉得这不很简单吗？然后迅速地给那些组件指定了android:process属性，然后编译运行，发现“正常地运行起来了”。这里笔者想说的是，那是真的正常地运行起来了吗？ 现在先不置可否，下面先给举个例子，然后引入本节的话题。还是本章刚开始说的那个例子，其中SecondActivity通过指定android:process属性从而使其运行在一个独立的进程中，这里做了一些改动，我们新建了一个类，叫做UserManager，这个类中有一个public的静态成员变量，如下所示。 public class UserManager { public static int sUserId = 1; } **MainActivity.java** ``` package com.ryg.chapter_2; public class MainActivity extends Activity { private static final String TAG = "MainActivity"; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); UserManager.sUserId = 2; } @Override protected void onResume() { Log.d(TAG, "UserManage.sUserId=" + UserManager.sUserId); persistToFile(); super.onStart(); } } ``` **SecondActivity.java** ``` package com.ryg.chapter_2; public class SecondActivity extends Activity { private static final String TAG = "SecondActivity"; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_second); Log.d(TAG, "onCreate"); } @Override protected void onResume() { super.onResume(); Log.d(TAG, "UserManage.sUserId=" + UserManager.sUserId); } } ``` 然后在MainActivity的onCreate中我们把这个sUserId重新赋值为2，打印出这个静态变量的值后再启动SecondActivity，在SecondActivity中我们再打印一下sUserId的值。**按照正常的逻辑，静态变量是可以在所有的地方共享的，并且一处有修改处处都会同步**，图2-3是运行时所打印的日志，我们看一下结果如何。 :-:  图2-3 系统日志 看了图2-3中的日志，发现结果和我们想的完全不一致，正常情况下SecondActivity中打印的sUserId的值应该是2才对，但是从日志上看它竟然还是1，可是我们的确已经在MainActivity中把sUserId重新赋值为2了。看到这里，大家应该明白了**这就是多进程所带来的问题，多进程绝非只是仅仅指定一个android:process属性那么简单**。 上述问题出现的原因是**SecondActivity运行在一个单独的进程中**，我们知道**Android为每一个应用分配了一个独立的虚拟机，或者说为每个进程都分配一个独立的虚拟机，不同的虚拟机在内存分配上有不同的地址空间，这就导致在不同的虚拟机中访问同一个类的对象会产生多份副本**。 拿我们这个例子来说，**在进程`com.ryg.chapter_2`和进程`com.ryg. chapter_2:remote`中都存在一个UserManager类，并且这两个类是互不干扰的，在一个进程中修改sUserId的值只会影响当前进程，对其他进程不会造成任何影响**，这样我们就可以理解为什么在MainActivity中修改了sUserId的值，但是在SecondActivity中sUserId的值却没有发生改变这个现象。 **所有运行在不同进程中的四大组件，只要它们之间需要通过内存来共享数据，都会共享失败，这也是多进程所带来的主要影响。正常情况下，四大组件中间不可能不通过一些中间层来共享数据，那么通过简单地指定进程名来开启多进程都会无法正确运行。当然，特殊情况下，某些组件之间不需要共享数据，这个时候可以直接指定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 = MyUtils.getProcessName(getApplicationContext(), Process.myPid()); Log.d(TAG, "application start, process name:" + processName); } } 运行后看一下log，如图2-4所示。**通过log可以看出，Application执行了三次onCreate，并且每次的进程名称和进程id都不一样，它们的进程名和我们为Activity指定的android:process属性一致**。这也就证实了**在多进程模式中，不同进程的组件的确会拥有独立的虚拟机、Application以及内存空间**，这会给实际的开发带来很多困扰，是尤其需要注意的。或者我们也可以这么理解**同一个应用间的多进程：它就相当于两个不同的应用采用了SharedUID的模式，这样能够更加直接地理解多进程模式的本质**。 :-:  图2-4 系统日志 本节我们分析了多进程所带来的问题，但是我们不能因为多进程有很多问题就不去正视它。**为了解决这个问题，系统提供了很多跨进程通信方法，虽然说不能直接地共享内存，但是通过跨进程通信我们还是可以实现数据交互**。 **实现跨进程通信的方式很多，比如通过Intent来传递数据，共享文件和SharedPreferences，基于Binder的Messenger和AIDL以及Socket等**，但是为了更好地理解各种IPC方式，我们需要先熟悉一些基础概念，比如序列化相关的Serializable和Parcelable接口，以及Binder的概念，熟悉完这些基础概念以后，再去理解各种IPC方式就比较简单了。