0x00 适用场景
1 单进程所分配的内存不够,需要更多的内存。在早期android系统只为一个单进程的应用分配了16M的可用内存,随着手机的硬件的提升和android系统的改进,虽然可分配内存越来越多,但仍旧可以通过开启多进程来获取更多的内存来处理自己App的业务
2 独立运行的组件,比如音乐播放器,音乐的后台播放可以放到一个新的进程中,即使负责显示UI的那个进程被回收,音乐也能正常在后台播放等等。
0x01 使用方法
在 activities、services、content providers和broadcast receivers中有一个属性:
android:process
例如我们创建一个后台播放音乐的Service,并在新进程中运行:
<manifest ...>
<application
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:theme="@style/Theme.Main" >
<activity
android:name=".MusicActivity"
/>
<service
android:name=".MusicService"
android:process=":music"
/>
</application>
</manifest>
如果被设置的进程名是以“:”开头的,则这个新的进程对于这个应用来说是私有的,当它被需要或者这个服务需要在新进程中运行的时候,这个新进程将会被创建。如果这个进程的名字前面没有加‘’:“,而是以小写字符开头的,则这个服务将运行在一个以这个名字命名的全局的进程中,当然前提是它有相应的权限。这将允许在不同应用中的各种组件可以共享一个进程,从而减少资源的占用。
0x02 弊端
1 Application 会执行多次:
继承Application的类会执行多遍, 现在很多的开发者都习惯在Application 的子类里去做应用的初始化和数据存储的操作,如果我们开启多个进程而让Application 的子类的各个回调方法都执行多次这显然是不合理的,所以我们就应该区分进程,如果是应用的进程则做应用的操作,其他的进程(在这里是一个服务)就做其他的操作。解决办法可以是根据进程名称执行不同的操作。
2 静态成员和单例模式失效:
进程是被设计成独立的(如安全特性),这意味着每一个进程将有自己的Dalvik VM实例, 分配了不同的地址空间,修改静态成员只会在自己的进程中有效,同样单例模式也是只有自己的进程中是单例,多个进程中就不能称之为单例了,因为很可能多个进程都会存在这个所谓的单例。
3 SharedPreferences变得不可靠:
SharedPreferences并不支持并发的读取,多个进程可能存在并发的情况,这样SharedPreferences的读和写都变得不可靠。