activity生命周期（二）

• activity的生命周期分两种情况，一种的正常情况下的生命周期，一种是异常情况下的生命周期，而异常情况通常是指activity被系统回收或者系统配置发生改变而导致activity被销毁重建，比如屏幕的翻转。

正常情况下的生命周期

activity的生命周期

一个activity有四种状态，7个方法。四种状态是运行、暂停、停止、不存在状态，7个方法是：

• onCreate()：表示activity正在创建，此时系统内存中有activity的实例，这是生命周期中的第一个方法，在这个方法中我们可以做一些初始化，比如使用setContentView()去加载界面布局资源，初始化activity所需要的数据。
• onRestart()：表示activity重新启动，当activity停止后但并没有销毁时再次启动时，也就是当activity由不可见状态变为可见状态时，就会调用这个方法。
• onStart()：表示activity正在被启动，这时候的activity就可见了，但是却不能操作，不能与用户进行交互。
• onResume()：表示activity已经可见并且可以在前台和用户进行交互了，这与上面的onStart()方法的相同之处就是都可见，不同之处就是onStart()中activity是不在前台的，不能与用户进行交互，而在onResume()中，activity是在前台的，可以与用户进行交互。
• onPause()：表示暂停activity，一般在正常的情况下，紧接着会调用onStop()方法，这时activity又变为可见但不能交互的情况了，与onResume()是相对应的。
• onStop()：表示停止activity，这时activity会变为不可见的状态，但是activity的实例还在系统内存中的，在这个方法中，我们可以做一些轻量级的回收工作，不能做一些耗时的事情。
• onDestroy()：表示activity正在被销毁，这时activity即不可见并且系统内存中也没有了activity的实例了，这时activity生命周期中的最后一个回调，在这里，我们可以做一些自愿的额释放和回收工作。

activity的启动原理：启动一个activity的请求会由Instrumentation来处理，然后它通过Binder向AMS（ActivityManagerService）发送请求，AMS内部维护着一个ActivityStack并负责栈内的Activity的状态同步，AMS通过ActivityThread去同步activity的状态从而完成生命周期方法的调用。

异常情况下的生命周期

activity除了正常情况下的生命周期，还有异常情况的下的生命周期，其生命周期与正常生命周期有些许的不一样。从以下两种情况分析异常情况下的生命周期：

资源相关的系统配置发生改变导致activity被杀死并重建

比如在横竖屏切换的时候，由于资源要重新配置，在默认的情况下，activity会被销毁并且重建。

当系统配置发生改变后，activity会被摧毁，其中会调用onPause、onStop、onDestroy方法，同时，由于activity是异常终止的，系统会调用onSaveInstanceState来保存当前activity的状态，这个方法在onStop之前调用，既可以在onPause之前调用。也可以在onPause之后调用，这个方法只出现在activity异常终止的情况下，当activity又重新创建后，系统又会调用onRestoreInstanceState,并且将onSaveInstanceState保存的Bundle对象作为参数传递给onRestoreInstanceState方法和onCreate()方法，通过后面这两个方法可以判断activity是否被重建了，如果是重新建立的，那么Bundle对象就不为空，如果是新建的activity，那么Bundle对象就为null，重建的onRestoreInstanceState方法调用在onStart方法之后。在activity正常销毁的时候是不会调用onSaveInstanceState方法的，只有在activity异常终止并重建的时候才调用onSaveInstanceState和onRestoreInstanceState来存储和恢复数据。

• 如果当系统的资源配置发生改变时，不想重建activity，可以在AndroidMenifest.xml文件中给activity声明属性：

android:configchanges="orientation"

保存和恢复View层次结构，系统的工作流程

• activity异常终止时，系统调用onSaveInstanceState方法去保存数据
• 然后activity委托window去保存数据
• 接着window再委托它上面的顶级容器去保存数据，（顶级容器是一个ViewGroup）
• 顶级容器再通知子元素去保存数据

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

activity的优先级由高到低可以分为3种：

1. 前台activity——优先级最高
2. 可见但非前台activity——优先级次高
3. 后台activity（不可见）——执行了onStop方法，优先级最低

当内存不足时，系统会按照优先级的高低去杀死目标activity所在的进程，如果一个进程中没有四大组件在执行，那么这样的进程很容易被杀死，一般比较好的方法是将后台工作放在四大组件中的Service中从而保证了进程有了一定的优先级，就不会轻易被系统给杀死了。