Activty是开发中最常用到的组件之一，从接触Android开始，几乎每天都在和它的生命周期打交道，利用它的生命周期去处理一些需求。关于Actvity生命周期的知识点非常多，本篇文章总结了一些重点，偏理论，但是恰恰是理论指导了我们平时实践时的方向，不容忽视。
Android典型情况下的生命周期分析
-
onCreate():Activity正在被创建，做一些初始化工作。比如setContentView加载页面布局资源，初始化Activity所需要的数据。
-
onRestart(): Activity正在重新启动，由不可见变为可见状态。
-
onStart():正在被启动，Activity已经可见，但是未出现在前台，无法与用户交互。
-
onResume():Activity已经可见，出现在前台并且开始活动。
-
onPause():正在停止，可以做一些存储数据，停止动画等操作，注意不能太耗时，会影响新的Activity显示。onPause必须先执行完，新的Activity的onResume才会执行。
-
onStop():Activity即将停止，做稍微重量级的回收工作，不能太耗时。
-
onDestroy():即将被销毁，做一些回收工作和最终的资源释放。
生命周期图如下所示（图为网上搜索找来的）
-
从整个生命周期看，onCreate和onDestroy配对，分别标识着Activity创建和销毁，并且只可能有一次调用。
-
从Activity是否可见来看，onStart和onStop配对，可调用多次。
-
从Activity是否在前台来看，onResume和onPause配对，可调用多次。
异常情况下的生命周期分析
情况1. 资源相关的系统配置发生改变导致Activity被杀死并重新创建。过程如下图
onSaveInstanceState和OnRestoreInstanceState方法中，系统自动为我们做了一些恢复工作。默认保存Activity的视图结构，并在Activity重启后恢复这些数据，如文本输入框中用户输入的数据、ListView滚动的位置等。我们可以通过查看View的源码，查看某个特定的View系统能为我们恢复哪些数据，感兴趣的可以自行去查看。保存和恢复View层结构，系统的工作流程如下图。
首先Actvity被意外终止时，Activity会调用onSaveInstanceState去保存数据，然后Activity会委托Window去保存数据，window委托ViewGroup(一般来说是顶层容器DecorView)，最后顶层容器再委托子元素，然后整个过程就完成了。
Acticity在被销毁以后调用onSaveInstanceState来保存数据，重新创建以后在onCreate和onRestoreInstanceState中都能正确的恢复数据，onRestoreInstanceState一旦被调用，参数Bundle saveInstanceState一定是有值的，不需要做判空处理。但是onCreate中是需要判断的，所以推荐使用onRestoreInstanceState。
当Activity正常销毁的时候，是不会调用onSaveInstanceState,因为被销毁的Activity不可能再次被显示。
Activity在异常终止的时候才会调用onSaveInstanceState和onRestoreInstance来存储和恢复数据，其它情况不会触发这个过程。
情况2. 资源内存不足导致低优先级Activity被杀死
这种情况不好模拟，但是其数据存储和恢复过程和情况1完全一致 以下优先级由高到低
- 前台Activity:正在和用户交互的Activity，优先级最高。
- 可见但非前台Activity：比如Actvity中弹出了一个对话框，导致Activity可见但是位于后台，无法和用户直接交互。
- 后台Activity：已经被暂停的Activity，比如执行了onStop,优先级最低。
一些后台的工作不适合脱离四大组件而独立运行在后台中，这样进程很容易被杀死。比较好的方法就是将后台工作放入Service中从而保证进程有一定的优先级，这样就不会被系统轻易的杀死。
当系统配置发生改变后，Actvity会被重新创建，那么有没有办法不重新创建呢？是有的，如果不想系统重新创建Activity,可以给Activty指定configChanges属性,这又是另一个大的知识点，本篇文章不作扩展。
Actvity在典型和异常情况下的生命周期分析重点部分就是以上的相关内容了，欢迎大家指正补充。
