Android 系统的目的是让用户增强控制权并且让他们简便地使用应用程序。例如,一个 app 的用户可能会旋转屏幕,回复一条通知信息,或者切换到另一个任务,而用户应该能够在这类操作后继续流畅地使用这个 app。
为了提供这种用户体验,你应该知道怎么管理组件的生命周期。组件可以是一个 Activity,一个 Fragment,一个 Service,或者 Application 本身,甚至是在默默运行的进程。组件有生命周期,生命周期会在多种状态中变换。当状态发生变化时,系统会通过一个生命周期回调方法通知你。
为了更好解释生命周期是怎么运作的,我们定义了根据现有组件进行分类的一系列用户场景。
第一部分: Activities — 单一 activity 的生命周期 (就是本文)
第二部分: 多个 activities — 跳转和返回栈(back stack)
第三部分: Fragments — activity 和 fragment 的生命周期
它们的图表也提供了 PDF格式备忘录,以方便查阅。
除非特别说明,接下来的这些场景展示了这些组件的默认行为。
如果你发现有错误或者遗漏了什么重要的东西,请在下方评论。
触发原因:
Activity.finish()
方法被调用这个最简单的场景说明了一个单一 activity 的应用被用户开启,结束,和重启时发生了什么:
场景 1:应用被终止并且重启
状态处理
触发原因:
场景 2:用户切换出去
在这个场景中系统会 stop 这个 activity,但不会马上结束它。
状态处理
当你的 activity 进入 Stopped 状态,系统会使用 onSaveInstanceState 去保存应用的状态以防系统一段时间后终止这个应用的进程 (请看下面)。
假设应用的进程没有被终止,这个应用的实例会常驻在内存,保存所有状态。当这个 activity 回到前台工作时,它会恢复这些状态。你不需要重新初始化这些之前已生成的组件。
触发原因:
场景 3:屏幕旋转或其他配置变化
状态处理
像屏幕旋转或窗口大小改变,这种配置变化应该能够让用户在变化后继续无缝使用。
onCreate
和 onRestoreInstanceState
中的 Bundle 对象是相同的。触发原因:
场景 4:应用被系统暂停
这个场景不适用于以下情况: