一、流程总结

onCreate （创建）-> onStart（可见，不可交互） -> onResume（可见可交互） -> onPause（可见，不可交互） -> onStop（不可见，不可交互） -> onDestroy（摧毁）

---

二、小知识点

（1）如果在activity跳转前需要缓存数据，则在onPause里做存储操作；

原因：因为在某些特殊情况下，onPause可能还没顺利走到onStop数据就被系统回收了，所以最好在onPause里做数据存储的操作。

（2）而如果要注销broadcast应该在onStop中进行；

原因：因为onPause容易被触发，所以最好在activity完全不可见且不可交互时，注销广播；

（3）假设当前Activity为A，如果这时用户打开一个新Activity B，那么B的onResume和A的onPause哪一个先执行呢？

答：在新的Activity启动之前，栈顶的Activity需要先onPause后，新的Activity才能启动。

Activity官方文档中对onPause的解释有这么一句话：不能在onPause中做重量级操作，因为必须onPause执行完成后，新的Activity才能Resume。我的认识是，在onPause和onStop中都不能进行耗时操作，尤其是onPause，这也意味着，我们应当在onStop中做操作，从而使得新的Acticity尽快显示出来并切换到前台。

---

三、异常情况下的生命周期

情况1：资源相关的系统配置发生改变导致Activity被杀死并重新创建

1.例如：Activity处于竖屏状态，突然旋转屏幕，由于系统配置发生了改变，在默认情况下，Activity就会被销毁并且重新创建。（生命周期的流程图如下）

上图中onSaveInstanceState方法是系统调用的，调用时机是在onStop之前，它和onPause没有时序关系，此方法只出现在Activity被异常终止的情况下。

当Activity被重建后，系统会调用onRestoreInstanceState，并把Activity销毁时onSaveInstanceState方法所保存的Bundle对象作为参数传递给onRestoreInstanceState和onCreate方法。所以我们可通过onRestoreInstanceState和onCreate方法判断Activity是否被重建，若被重建，则可以取出之前保存的数据并恢复，onRestoreInstanceState的调用时机在onCreate方法之后。

2.如何不让Activity在旋转屏幕时重新创建？

答：在目录清单文件中给configChanges属性添加orientation|screenSize，如下。

android:configChanges="orientation|screenSize"

当添加了这条属性后，系统在切换横竖屏时，就不会调用onSaveInstanceState和onRestoreInstanceState方法来储存盒恢复数据，取而代之的是系统调用了Activity的onConfigurationChanged方法。

PS：（1）configChanges常用的项目及意义有三个：

locale：设备的本地位置发生改变，一般指切换了系统语言。

orientation：这个是最常用的，屏幕方向发生了改变。

keyboardHidden：键盘的可访问发生了改变，比如用户调出了键盘。

（2）特别的一个：

screenSize：屏幕尺寸信息发生改变，旋转屏幕会导致屏幕尺寸发生变化。当编译选项中的minSdkVersion和targetSdkVersion有一个大于13时，为了防止旋转屏幕导致的Activity重启，则除了orientation，还要加上screenSize。

情况2：资源内存不足导致低优先级的Activity被杀死

1.Activity的优先级从高到低依次可分为以下三种：

（1）前台Activity——正在和用户交互的Activity。优先级最高。

（2）可见但非前台Activity——如在Activity中弹出一个对话框，导致Activity可见但位于后台无法和用户交互；即当执行onPause后，Activity的状态。

（3）后台Activity——已经被暂停的Activity，如执行了onStop。优先级最低。

当系统内存不足时，会按照上述Activity的优先级杀死目标Activity所在的进程，并在onSaveInstanceState和onRestoreInstanceState中储存和恢复数据。

2.另外，如果一个进程中没有四大组件在执行，那么这个进程很快就会被系统杀死。因此，后台工作不适合脱离四大组件而独自运行在后台中。比较好的解决方案是，将后台工作放入一个Service中，从而保证进程有一定的优先级，且不会轻易被系统杀死。