除了在DDMS中可以查看进程，我们还可以通过shell命令来查看

不知道读者有没有注意到，SecondActivity和ThirdActivity的进程名分别为“：remote”和包名.remote，那么这两种方式有区别吗？其实是有区别的，区别在两面，首先”：“的含义，是指在当前的进程名前附加上包名，这是一种简写的方法，对于SecondActivity来说，他完整的进程名为com.liuguilin.multiprocesssample：remote，而对于ThirdActivity中的申明方式，它是一种完整的命名方式，不会附加包名信息；其次，进程以”：“开头的属于当前应用的私有进程，其他应用的组件不可以和它跑在同一个进程中，而进程名不以”：“开头的进程属于全局进程，其他应用通过ShareUID方式可以和它跑在同一进程中。

我们知道Android系统会为每个应用分配一个唯一的UID，具有相同UID的应用才能共享数据。这里要说明的是，两个应用通过ShareUID跑在同一个进程由是有要求的，需要这两个应用有相同的ShareUID并且签名相同才可以。在这种情况下，它们可以互相访问对方的私有数据，比如data目录、组件信息等，不管它们是否跑在同一个进程中。当然它们跑在同一个进程中，那么除了能共享data目录、组件信息，还可以共享内存数据，或者说它们看起来就像是一个应用的两个部分。

如果用一句话来形容多进程，那笔者只能这样说：“当应用开启了多进程以后，各种奇怪的现象都出现了”，为什么这么说呢？这是有原因的。大部分人都认为开启多进程是很简单的事情，只需要给四大组件指定android:process属性即可。比如说在实际的产品开发中，可能会有多进程的需求，需要把某些组件放在单独的进程中去运行，很多人都会觉得这不很简单吗？然后迅速地给那些组件指定了android:process属性，然后编译运行，发现“正常地运行起来了”。这里笔者想说的是，那是真的正常地运行起来了吗?现在先不置可否，下面先给举个例子，然后引入本节的话题。还是本章刚开始说的那个例子，其中SecondActvity通过指定android:process属性从而使其运行在一个独立的进程中，这里做了一些改动，我们新建了一个类，叫做UserManager，这个类中有一个public的静态成员变量，如下所示。