欢迎进入Android多进程时代

欢迎进入Android多进程时代

现在一个Dalvik再也不够用了

链接:Going multiprocess on Android

禁锢在内存牢笼之中

之所以Andoird成为一个优秀的移动操作系统，是因为它有很多不错的特性。但是这个系统有时候却让人爱不起来，尤其是对于程序员来说。

从内存限制角度来说，IOS可以给应用提供近乎无限的内存(200MB算不上多大的内存分配)。但是Android系统对应用可支配的内存有很大的限制。运行在一些新设备上的程序可能分配到24MB/32MB/48MB 不等的内存空间，这些程序在老设备上分配到的空间可能只有杯水车薪的16MB。

你的应用只会在分配的内存里运行。那么一定要有效率的载入类，线程，服务,UI资源以及应用要呈现的内容。如果一个图片浏览器程序要显示很多的图片，或者一个音乐播放器要在后台播放:这都要消耗很多内存。

为了理解为什么Android会做这些限制，以及它提供了怎样的方式来解决这些问题。我们要知道迷雾后面的一些真相。

Android processes: explained!

理解Android进程

你应该已经知道Android是基于Linux系统的。准确的说，每个应用都运行在它自己的进行中(有一个唯一的PID编号):这种模式允许应用在一个隔绝的环境中运行，这样这个程序就不会被其他的实例/进程 所干扰。当你要启动一个实例，Android就会创建一个进程，生成一个主线程，然后开始运行主Activity。

你可能不知道，其实你可以指定应用的某部分运行在不同的进程上，而非运行在初始启动进程上。添加下面这个属性就可以了

android:process

这个进程属性能用在activities,services,content providers and broadcast receivers,还可以指定某个组件在什么进程上运行。

在这个例子中，我指定MusicService必须在music进程上运行。

<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>

这有什么好处？

在之前的介绍中，我提到每一个Android应用都有一个内存预算来执行操作，并且不能超过这个预算。更加准确的说，这个限制是强加在每一个进程单位上的。换句话来说，每个实例的进程都有一个专用的内存分配空间!(更不用说其终止时也有更酷的不同规则)

我们来看看这种进步是好事还是坏事[剧透:两方面都有]

多进程有什么好处

像我之前说的，一个独立的进程可以充分的利用自己的内存预算，这让主进程可以有更多的空间分配给它的资源

除此以外，系统对于运行着不同组件的进程处理方式是不同的。如果系统的可用内存很少，并不是所有的进程都会被杀死。假设有这么个应用场景:你的音乐播放器在后台运行，并且音乐正在播放;突然，系统要释放一些内存。因为这个播放音乐的服务是在其他的进程上运行的，系统有很大的可能会先杀死主要进程(运行应用UI的进程)，保留音乐播放服务所在的进程。

最后一点，这样的处理方式的用户体验非常好。因为应用的每一个进程都会显示在应用管理器的内存使用页上，它们还可能显示在”缓存”部分(这说明它们是不活跃的)。

多进程有什么不好

不过也有不好的地方。你得知道多进程并不适合懒人用。

首先，进程就是被设计为独立的(一个安全特点)。这说明每个进程都自己自己的Dalvik 虚拟机实例。至少在传统意义上来讲，你不能在这些进程之间分享数据。举个例子，在在每个进程中，静态字段都有自己的值，而不是你一厢情愿的认为只有个唯一值。并且这延伸到应用程序的每一个状态。

难道两个独立进程之间就不能有任何的内部通信可能吗？当然不是，内部通信是有可能的。并且有很多的方式来实现。Intents可以跨进程通信，Handlers和Messengers也能。你还可以用AIDL和Binder来通信，这种方式在你声明两个绑定的服务时候很常用(不过还有更多的方式通信)。

我需要多进程吗?

这得看情况，根据实际情况来判断。如果你的用户越来越频繁的遇到内存溢出的错误，他们一直抱怨你的应用经常提示内存不够，那么你得考虑使用更多的进程了。

音乐播放器是一个运用额外进程的最常见场景，这个额外的进程起到了很大的作用。不过多进程的好处不仅仅于此。举个例子，你的应用是一个云存储服务的客户端:在单独的进程里建一个异步的服务组件是很合理的。这是因为即使系统把UI进程杀死以后，服务还可以保持运行，来获得最新的文件。

如果你确实需要多进程，我建议你先做一个最基本的应用 DEMO:只有在看清楚多进程的好处和其复杂的本质以后，你才能决定是否真的需要它。如果你用到了多进程，怎样处理它们才能让应用不崩溃。

最后的话

我知道在多进程这个话题上说的不过是皮毛而已，但是我想给你的是一些实际应用建议，而不是介绍操作系统层面的理论和进程的机制。

最后，如果你想了解更多关于多进程的事情，那你一定要留下评论让我知道。同时，文档是最好的朋友。