Activity生命周期回顾

本文参考《Android 开发艺术探索》

以上图片来源google官方指南

关于Activity的总结，会本着结论先行的方式进行

一、典型情况下的Activity的生命周期

onCreate：Activity正在被创建，可以做一些初始化工作，比如setContentView去加载布局资源，初始化数据。

onStart：Activity正在被启动，即将开始，Activity已经可见，但是并没有出现再前台，还无法和用户交互。可以理解成此时Activity已经渲染了，但是用户感受还看不见。

onResume：Activity已经可见，并且出现在前台并开始活动。和onStart的区别，可以从是否处于前台的角度进行区别，onStart生命周期回调时，Activity仍然处于后台；onResume生命周期回调时，Activity恰好处于进入前台状态。

onPause：Activity正在停止，正常情况下，紧接着onStop方法会被调用。在特殊情况下，如果用户快速的再回到当前的Activity，那么onResume会被调用。在onPause的生命周期的回调方法中，可以做一些存储数据，停止动画等动作，但在onPause方法中，不能执行较耗时的操作，原因是会影响新的Activity的显示，onPause必须先执行完成新的Activity的onResume方法才会被调用。如果由于耗时影响了新的Activity的onResume方法的调用，用户感知到的是新的Activity的显示变得缓慢。

onStop：Activity即将停止，可以做一些稍微重量级的回收工作。正常情况下，onStop会紧接着onPause方法之后就会被调用，除了在onPause中介绍的，快速返回到当前的Activity，onPause方法可能不被调用。另外还有一个特殊的情况：如果当前的Activity设置了透明主题，那么当前的Activity是不会回调onPause方法的。

onDestroy：Activity即将销毁，这是Activity生命周期中的最后一个回调，在这里我们可以做一些回收工作和最终的资源释放工作。

onRestart：Activity重新启动，是用户行为所致，重新回到原Activity的时候，会走如下生命周期onRestart->onStart->onResume。

结构化总结,从整个生命周期来说

onCreate和onDestroy是配对的，分别标识着Activity的创建和销毁。

onStart和onStop是配对的，分别标识着Activity的可见和不可见，在Activity存活的生命周期中可能反复多次调用。

onResume和onPause是配对的，分别标识着在前台和不在前台，在Activity存活的生命周期中可能反复多次调用。

对于上面的生命周期，如果想要进行验证，给出几种建议方案：

1. 查看android developer的官方文档

2. 查看android sdk的Activity的源代码

3. 写个demo进行验证

经典生命周属于较为基础的部分，具体验证的内容，就不记录在这篇文章里了。

另外，基于android官方的最新文档和源码层面的分析，会对onPause进行更官方的分析。

二、异常情况下的生命周期分析

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

典型的案例，就是屏幕旋转的时候所造成的横竖屏切换，在默认情况下就会导致当前的Activity重新创建，当然我们也可以组织我们的系统重新创建Activity。

当系统配置被改变后，Activity会被销毁，其中onPause、onStop、onDestroy均会被调用，同时由于是异常逻辑触发销毁的，所以android系统的实现中会去调用onSaveInstanceState回调，作为对被销毁Activity的数据存储，同时由于异常关闭，系统会触发被销毁的（是由系统判断，这个可以不用去纠结）。那么针对于一个此种情形下Activity的生命周期过程如下：

销毁过程：[onSaveInstanceState]|->onPause->|[onSaveInstanceState]->onStop->onDestroy

在上述过程中，onSaveInstanceState的生命周期的回调方法，会在onStop生命周期回调方法之前被调用，onSaveInstanceState回调的时机和onPause回调的时机，没有明确的先后顺序关系，所以有可能在onPause之前也有可能在onPause之后，但一次销毁的过程，只会出现上述一种情况。

重新创建过程：onCreate->onStart->[onRestoreInstanceState]->onResume

在上述过程中，在之前销毁过程中被保存的Activity数据会保存在bundle中，在重新创建Activity的过程中，onCreate方法中，会接受到之前保存的bundle对象做为实际参数，同时onRestoreInstanceState的方法也会接受到被销毁过程中保存了的bundle对象。

问题：onRestoreInstanceState方法、onResume方法的调用时机的先后关系？

那么在bundle中具体保存了哪些数据呢，首先系统帮我们保存Activity的视图结构，另外视图结构中的一些其他信息的保存，要具体看andorid sdk中对这些组件实现时的处理，比如editText中会保存用户输入的数据，ListView的滚动位置等等，其他视图View能够保存的内容，可以查看具体的view组件的源码，每个view也都有onSaveInstanceState和onRestoreInstanceState的方法实现。

结论：

​ ①在资源相关的配置发生改变，导致Activity被杀死并重新创建的整个过程，android sdk的实现中，已经帮我们做了一些数据和视图的保存操作，同时在也能在重新创建的时候，能帮我做一些恢复操作。

​ ②另外，在我们实际的业务开发中，也会由于上述场景导致我们的数据丢失，所以我们可以自行实现在onSaveInstanceState方法中做业务数据保存和实现在onRestoreInstanceState方法 or onCreate方法中进行恢复业务数据的操作。

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

此种情况的生命周期过程和1是完全一样的。这里补充一下按照进程优先级的高低，Activity可以分为以下三种：

（1）前台Activity，正在和用户交互的Activity
（2）可见但非前台Activity，比如Activity中弹出了一个对话框，导致Activity仍然可见，但是无法和用户进行交互。
（3）后台Activity，已经暂停了的Activity，执行了onStop方法，优先级最低。

关于内存不足导致应用中的组件、甚至应用本身被杀死的情形，所涉及的知识体系是android low memory killer机制，在这篇文章中，就不再详述。