【趣读官方文档】1.管家的抉择 （Android进程生命周期）

前言：

为了形象，本文会做一些比喻，对应关系如下：

管家 ：                 Android 系统 ；

老爷 ：                 用户 ；

家庭经济情况 ： 内存；

进程 ：      仆人。

进程生命周期 ，又名 你丑你先死

Android家里养着许多仆人，正常情况下管家希望仆人都健健康康的活着，多给老爷挣点工分，博老爷欢心。

然而天不遂人愿，老爷骄奢无度，看见漂亮的仆人就往家里招，到处留情。日复一日，终于有一天，管家在开会时宣布：咱家存折里没钱了，养不下你们这么多人，你们每个都很优秀，哪个都是老爷的心头肉，可是没办法啊，为了保证大多数人活下去，你们中间有些人要先我们一步而去了嘤嘤嘤%>_<%。

听到这个消息，大家一片哗然，个个都觉得自己为老爷做出了贡献，命不该绝。

“肃静！”管家发话，“我跟老爷已经商量过了，所有人都会按照给老爷做的贡献多少分类，主要分下面四类，都仔细听着，我会按照重要性从高到低的顺序念出来！”

1. 前台Activity所在的进程 --- 当前用户可以看到、并且可以交互：

最重要的肯定最得老爷疼爱的大老婆，老爷天天见你、玩你，怎么舍得失去你呢。要是非问我你什么时候会被终结？放心吧，那得到最后的最后实在是没办法了才终结。通常这时候家里穷的基本一干二净了，下面那么几类人都奉献完了，为了保证老爷能有吃的，才会忍痛割爱。不过这种情况一般很少，您就放心吧。

2. 可视Activity所在的进程 --- 能看到，但是不能交互，比如说在Activity A 中点击按钮弹出一个对话框，这时Activity A 在对话框的阴影后面，虽然能看到，但是不能和用户交互：

能干的奴婢，因为很“能干”，虽然现在老爷不翻你牌，稍后他肯定耐不住寂寞会去找你玩的，你地位只比上面那位低一点，除非家里穷的实在没办法了，为了让大老婆活只能把你饿死这种情况，一般不会让你受委屈的，好好干。

3. 后台Activity所在的进程 --- 已经切换到后面的Activity、被暂停：

年老朱黄的仆人，虽然你曾经照顾过少爷，现在老了看不见了，也没什么用，没那么重要了。当家里没钱时，就会“被奉献”出自己占的地方给大老婆或者其他能干的仆人。突然有天老爷回心转意了，要见老仆人，怎么办？赶紧吃个大还丹重新调用onCreate(Bundle)，如果“被奉献”前调用过神技“onSaveInstanceState(Bundle)”，把记忆存储起来，复活时的她就跟之前的她一样，没有丝毫变化，没有丝毫怨言。

"我就知道你会回来的"--- from background activity

4. 空进程 --- 里面没有运行Activity、Service或者BroadcastReceiver等应用组件：

新来的仆人，没给老爷做出过贡献，当遇到紧急情况时最先“被奉献”。

总结：

看到了吧，了解这些"潜规则"后，要想让你的程序在年老（进入Background）时过个安稳年，就得把你在Activity结束后还要进行的操作 放到Service或者BroadcastReceiver里，那样系统才知道你的操作很重要，为你保驾护航。

正如之前在Activity生命周期里说的那样，到底要关闭哪个进程很大程度上决定于 用户 是否跟这个进程有交互。

有些时候我们可能在一个Activity里会开启一个持续的操作，我们希望这个操作能够不被Activity生命周期影响。

比如说一个运行用户拍照后上传图片到网站的程序，可能一次上传很多图片，用户希望在退出程序后它能一直上传。

为了实现这个需求，我们需要在该Activity中开启一个Service来后台上传，当上传操作是运行是一个Service中时，系统就会意识到它的重要性（起码比那些“年老朱黄的仆”人还重要），不管开启操作的activity是否paused、stopped、finished，都会保证上传操作的正常运行。

官方文档：

Process Lifecycle

The Android system attempts to keep application process around for as long as possible, but eventually will need to remove old processes when memory runs low. As described in Activity Lifecycle, the decision about which process to remove is intimately tied to the state of the user's interaction with it. In general, there are four states a process can be in based on the activities running in it, listed here in order of importance. The system will kill less important processes (the last ones) before it resorts to killing more important processes (the first ones).

1. The foreground activity (the activity at the top of the screen that the user is currently interacting with) is considered the most important. Its process will only be killed as a last resort, if it uses more memory than is available on the device. Generally at this point the device has reached a memory paging state, so this is required in order to keep the user interface responsive.

2. A visible activity (an activity that is visible to the user but not in the foreground, such as one sitting behind a foreground dialog) is considered extremely important and will not be killed unless that is required to keep the foreground activity running.

3. A background activity (an activity that is not visible to the user and has been paused) is no longer critical, so the system may safely kill its process to reclaim memory for other foreground or visible processes. If its process needs to be killed, when the user navigates back to the activity (making it visible on the screen again), its onCreate(Bundle) method will be called with the savedInstanceState it had previously supplied inonSaveInstanceState(Bundle) so that it can restart itself in the same state as the user last left it.

4. An empty process is one hosting no activities or other application components (such as Service or BroadcastReceiver classes). These are killed very quickly by the system as memory becomes low. For this reason, any background operation you do outside of an activity must be executed in the context of an activity BroadcastReceiver or Service to ensure that the system knows it needs to keep your process around.

Sometimes an Activity may need to do a long-running operation that exists independently of the activity lifecycle itself. An example may be a camera application that allows you to upload a picture to a web site. The upload may take a long time, and the application should allow the user to leave the application while it is executing. To accomplish this, your Activity should start a Service in which the upload takes place. This allows the system to properly prioritize your process (considering it to be more important than other non-visible applications) for the duration of the upload, independent of whether the original activity is paused, stopped, or finished.