世界如此之大,做一个什么样的自己完全取决于你的选择
通过给四大组件指定android:process属性,我们可以轻易地开启多进程模式,这看起来很简单,但是实际使用过程中却暗藏杀机,有时候我们通过多进程得到的好处甚至都不足以弥补使用多进程所带来的代码层面的负面影响。
开启多进程模式
首先,在Android中使用多进程只有一种方法,那就是通过给四大组件(Activity、Service、Receiver、ContentProvider)在AndroidMenifest.xml中指定android:process属性,除此之外没有其他办法,也就是说我们无法给一个进程或一个实体类指定其运行时所在的进程。其实还有另一种非常规的多进程方法,那就是通过JNI在native层去fork一个新的进程。
code示例:
|
|
上面的示例分别为SecondActivity和ThirdActivity指定了process属性,并且它们的属性值不同,这意味着当前应用又增加了两个新进程。假设当前应用的包名为“com.zaenlove.androiddemo2”,当SecondActivity启动时,系统会为它创建一个单独的进程,进程名为“com.zaenlove.androiddemo2:remote”;当ThirdActivity启动时,系统会为它创建一个单独的进程,进程名为“com.zanelove.remote”。同时入口Activity是MainActivity,没有为它指定process属性,那么它运行在默认进程中,默认进程的进程名是包名。
下面我们看一下运行效果,进程列表中存在3个进程,进程id分别为2577、2655、2683:
是不是很简单,这只是开始,实际使用中多进程是有很多问题需要处理的。
除了在Eclipse的DDMS视图中查看进程信息,还可以用shell来查看,命令为:adb shell ps或者adb shell ps| grep com.zaenlove.androiddemo2。其中com.zaenlove.androiddemo2是包名。
值得注意的是,SecondActivity和ThirdActivity的android:process属性分别为“:remote”和“com.zanelove.remote”,那么这两种方式有何区别?区别有两方面:
首先,“:”的含义是指要在当前的进程名前面附加上当前的包名,这只是一种简写的方法,对于SecondActivity来说,它完整的进程名为com.zaenlove.androiddemo2:remote,而对于ThirdActivity中的声明方式,它是一种完整的命名方式,不会附加包名信息;其次,进程名以“:”开头的进程属于当前应用的私有进程,其他应用的组件不可以和它跑在同一个进程中,而进程名不以“:”开头的进程属于全局进程,其他应用通过ShareUID方式可以和它跑在同一个进程中。
Android系统会为每个应用分配一个唯一的UID,具有相同的UID的应用才能共享数据。这里要说明的是,两个应用通过ShareUID跑在同一个进程中是有要求的,需要这两个应用有相同的ShareUID并且签名相同才可以。在这种情况下,它们可以互相访问对方的私有数据,比如data目录、组件信息等,不管它们是否跑在同一个进程中。而如果是同一个进程中,那么除了能共享data目录、组件信息,还可以共享内存数据,或者说它们看起来就像是一个应用的两个部分。
多进程模式的运行机制
大部分人都认为开启多进程是很简单的事情,只需要给四大组件指定android:process属性即可。实则暗藏杀机,下面举个例子,其中SecondActivity通过指定android:process属性从而使其运行在一个独立的进程中,这里做一些改动,新建一个类(UserManager):
|
|
然后在MainActivity的onCreate中把sUserId重新赋值为2,打印出这个静态变量的值后再启动SecondActivity,在SecondActivity中我们再打印一下是sUserId的值。按照正常的逻辑,静态变量是可以在所有的地方共享的,并且一处修改处处都会同步,我们看一下运行的结果:
此时此刻,我的内心是崩溃的!这结果和我想象的完全不一样,看到这里,大家应该明白了这就是多进程所带来的问题,多进程绝非只是仅仅指定一个android:process属性那么简单!
上述问题出现的原因是SecondActivity运行在一个单独的进程中,我们知道Android为每一个应用分配了一个独立的虚拟机,或者说为每个进程都分配了一个独立的虚拟机,不同的虚拟机在内存分配上有不同的地址空间,这就导致在不同的虚拟机中访问同一个类的对象会产生多份副本。回到刚刚的例子当中,在进程com.zaenlove.androiddemo2和进程com.zaenlove.androiddemo2:remote中都存在一个UserManger类,并且这两个类是互不干扰的,在一个进程中修改sUserId的值只会影响当前进程,对其他进程不会造成任何影响,这样我们就可以理解为什么MainActivity中修改了sUserId的值,但是在SecondActivity中sUserId的值却没有发送改变这个现象了。
所有运行在不同进程中的四大组件,只要它们之间需要通过内存来共享数据,都会共享失败,这也是多进程所带来的主要影响。
一般来说,使用多进程会造成如下几个方面的问题:
- 静态成员和单例模式完全失效。
- 线程同步机制完全失效。
- SharedPreferences的可靠性下降。
- Application会多次创建。
分析以上问题:
第一个问题已经在上面分析完了,这里就不再累述!
第二个问题和第一个问题一样,既然都不在同一块内存了,那么不管是锁对象还是锁全局类都无法保证线程同步,因为不同的进程,锁的不是同一个对象。
第三个问题是因为SharedPreferences不支持两个进程同时去执行写操作,否则会导致一定几率的数据丢失,因为SharedPreferences底层是通过读/写XML文件来实现的,并发写显然是可能出问题的,甚至并发读/写都有可能出问题。
第四个问题是当一个组件跑在一个新的进程中的时候,由于系统要在创建新的进程同时分配独立的虚拟机,所以这个过程其实就是启动了一个应用的过程。因此,相当于系统又把这个应用重新启动了一遍,那么自然就会重新创建新的Application。我们也可以这样理解,运行在同一个进程中的组件是属于同一个虚拟机和同一个Application的,同理,运行在不同进程的组件是属于两个不同的虚拟机和Application的。
下面我们来做一个测试,首先在Application的onCreate方法中打印出当前进程的名字,然后连续启动三个同一个应用内但属于不同进程的Activity,按照期望,Application的onCreate应该执行三次并打印出三次进程名不同的log,代码如下所示:
|
|
记得在清单文件中的Application标签中添加:android:name=”.MyApplication”
可以看出,Application执行了三次onCreate,并且每次的进程名称和进程id都不一样,它们的进程名和我们为Activity指定的android:process属性一致。这也就证实了在多进程模式中,不同进程的组件的确会拥有独立的虚拟机、Application以及内存空间,因此在实际开发中我们要特别注意。
以上我们分析了多进程所带来的问题,为了解决问题,系统提供了很多跨进程通信方法,虽然说不能直接共享内存,但是通过跨进程通信我们还是可以实现数据交互。实现跨进程通信的方式有很多,比如通过Intent来传递数据,共享文件和SharedPreferences,基于Binder的Messenger和AIDL以及Socket等。