activity生命周期和启动模式

生命周期和启动模式

1.生命周期

1.1典型情况下的生命周期

正常情况下，activity会经历如下生命周期

1.1.1.onCreate：

表示acivity正在被创建，这是生命周期的第一个方法，在这个方法里可以做一些初始化工作

1.1.2.onRestart：

表示activity正在被重新启动，一般情况下，当当前activity从不可见变成可见时，onRestart方法会被调用，这种情形一般是用户行为所导致，比如用户按下home键切换到桌面或者用户打开了一个新的activity，这是当前activity就会被暂停，也就是onPause和onStop方法被执行了，接着用户又回到这个activity，这个方法就会被调用

1.1.3.onStart：

表示activity正在被启动，即将开始，这时activity已经可见了，但是还没有出现在前台，还没法与用户交互。

1.1.4.onResume：

表示activity已经可见，并出现在前台开始活动，与onStart对比，两者都表示activity已经可见，但是onStart的时候activity还在后台，onResume的时候activity才显示到前台

1.1.5.onPause：

表示activity正在停止，正常情况下onStop会紧接着被调用，特殊情况下，如果这个时候快速的回到当前activity，那么onResume会被调用，这种情况是极端情况，很难复现。此时可以做一些存储数据停止动画等工作，但不能太耗时，因为如果太耗时会影响新activity的显示，onPause必须执行完成，新activity的onResume才能开始执行

1.1.6.onStop：

表示activity即将停止，可以做一些稍微耗时的操作，但不能太耗时

1.1.7.onDestroy

表示activity即将销毁，可以做回收工作和资源释放

1.1.8 activity声明周期的切换过程（图）：

1.针对一个特定的activity，第一次启动回调如下：onCreate->onStart->onResume
2.当用户打开新的activity或者切换到桌面的时候回调如下：onPause->onStop
这里有一种特殊情况，如果新的activity采用了透明主题，那么不会回调onStop方法
3.当用户再次回到原activity的时候，回调如下onRestart->onStart->onResume
4.当用户按back键回退时，回调如下onPause->onStop->onDestroy
5.从整个生命周期来说,onCreate和onDestroy是配对的，标志着activity的创建和销毁，并且只能调用一次，从activity是否可见来说，onStart和onStop是配对的，从activity是否在前台来说，onResume和onPause是配对的

1.2异常情况下的生命周期

1.2.1系统配置发生改变导致activity被杀死并重新创建

系统配置发生改变之后，activity会被销毁，其onPause，onStop，onDestroy，均会被调用，同时会调用onSaveInstanceState来保存当前acitivity的状态，这个方法在onStop之前被调用，与onPause没有时序，有可能在onPause前也有可能在onPause之后，当activity被重新创建之后，会onRestoreInstanceState会被回调，并把activity销毁时onSaveInstanceState方法保存的Bundle对象当做参数传递给onRestoreInstanceState和onCreate方法，onRestoreInstanceState的调用时机在onStart之后

onSaveInstanceState和onRestorInstanceState，在activity需要重建的时候，系统会默认为我们保存activity的视图，并在重启后恢复这些数据，如文本框输入的数据，list的滚动位置等，至于具体哪些内容会被恢复，看具体的view，每个view都有这两个方法

关于保存view的层次结构，系统的工作流程是：首先activity被意外终止时，activity会调用onSaveInstanceState去保存数据，然后acitivity会委托window去保存数据，接着window再委托上一层顶级容器DecorView，然后顶层容器再一一通知它的子元素来保存数据，这样这个数据就保存完整了，（委托思想，view的绘制过程，事件分发都是这种委托思想来实现的）

重建后，onCreate和onRestoreInstaceState都可以接收，不同在于，只要onRestoreInstaceState被调用，bundle肯定不为空，

1.2.2内存不足导致activity被杀死

优先级：
1.前台activity：正在和用户交互的
2.可见但非前台acitivyt：activity弹出对话框，可见但不能与用户交互
3.后台acitivity：已经被暂停，如调用了onStop
内部不足，按照优先级来回收，并通过onSaveInstanceState和onRestoreInstanceState来保存和恢复数据。

2.启动模式

2.1activity的LaunchMode

2.1.1standard

标准模式，每次启动一个activity都会创建一个新的实例，这种模式下，谁启动了这个Activity，Activity就运行在它的Activity所在的栈中，比如ActivityA启动了ActivityB，那么B会进入A所在的栈中，这就是为什么用ApplicationContext去启动Activity会报错，因为非Activity的Context没有任务栈，所以会出问题，解决的方法是在启动activity的时候指定FLAG_ACTIVITY_NEW_TASK这样启动的时候就会为他创建一个新的任务栈

2.1.2singleTop：栈顶复用

如果新Activity位于栈顶，那么此Activity不会被重新创建，同时它的onNewIntent方法会被回调，通过此方法的参数可以获取当前请求的信息。注意：onCreate和onStart不会被系统调用，因为并没有发生改变，如果新activity实例存在但是没有位于栈顶，新acitivity依然会被创建。

2.1.3singleTask：栈内复用模式

只要activity在栈中存在，那么启动该activity就不会重新创建实例，也会回调onNewIntent。
流程：当一个具有singleTask模式的activity请求启动后，比如ActivityA，系统会寻找是否存在A想要的任务栈，如果不存在就创建该任务栈，然后创建A的实例放入栈中，如果存在A所需的任务栈，这时就看任务栈中是否存在A的实例，如果实例存在，那么系统就把A放到栈顶，并回调onNewIntent方法，同时由于sigleTask具有cleartop的效果，A上面的被清空，如果实例不存在，就创建A实例然后压栈

2.1.4singleInstance 单实例模式

加强的singleTask，除了singleTask模式的特性之外，还有一点，就是此种模式的activity只能单独的位于一个栈中
加入Activity A是singleInstance的模式，当A启动，系统为它创建一个新的任务栈，然后A单独存在这个任务栈中，由于栈内复用的特性，后续的请求均不会创建新的Activity，除非这个独特的任务栈被系统销毁了

2.2activity的Flags

3.IntentFileter的匹配规则

4：activity的启动流程分析

5：android资源加载机制

6：任务栈的系统工作原理