在内存不足的时候, Android 是会主动清理门户的,那它又是如何判断哪个 process 是可以清掉的呢?文档中也提到了它的重要性排序:
1. 最容易被清掉的是 empty process ,空进程是指那些没有 Activity 与之绑定,也没有任何应用程序组件(如 Services 或者 IntentReceiver )与之绑定的进程,也就是说在这个 process 中没有任何 activity 或者 service 之类的东西,它们仅仅是作为一个 cache ,在启动新的 Activity 时可以提高速度。它们是会被优先清掉的。因此建议,我们的后台操作,最好是作成 Service 的形式,也就是说应该在 Activity 中启动一个 Service 去执行这些操作。
2. 接下来就是 background activity 了,也就是被 stop 掉了那些 activity 所处的 process ,那些不可见的 Activity 被清掉的确是安全的,系统维持着一个 LRU 列表,多个处于 background 的 activity 都在这里面,系统可以根据 LRU 列表判断哪些 activity 是可以被清掉的,以及其中哪一个应该是最先被清掉。不过,文档中提到在这个已被清掉的 Activity 又被重新创建的时候,它的 onCreate 会被调用,参数就是 onFreeze 时的那个 Bundle 。不过这里有一点不明白的是,难道这个 Activity 被 killed 时, Android 会帮它保留着这个 Bundle 吗?
3. 然后就轮到 service process 了,这是一个与 Service 绑定的进程,由 startService 方法启动。虽然它们不为用户所见,但一般是在处理一些长时间的操作(例如 MP3 的播放),系统会保护它,除非真的没有内存可用了。
4. 接着又轮到那些 visible activity 了,或者说 visible process 。前面也谈到这个情况,被 Paused 的 Activity 也是有可能会被系统清掉,不过相对来说,它已经是处于一个比较安全的位置了。
5. 最安全应该就是那个 foreground activity 了,不到迫不得已它是不会被清掉的。这种 process 不仅包括 resume 之后的 activity ,也包括那些 onReceiveIntent 之后的 IntentReceiver 实例。
在 Android Application 的生命周期的讨论中,文档也提到了一些需要注意的事项:因为 Android 应用程序的生存期并不是由应用本身直接控制的,而是由 Android 系统平台进行管理的,所以,对于我们开发者而言,需要了解不同的组件 Activity 、 Service 和 IntentReceiver 的生命,切记的是:如果组件的选择不当,很有可能系统会杀掉一个正在进行重要工作的进程。