Activity的生命周期和启动模式

Android activity生命周期

1、Activity异常生命周期

1.1、Activity被异常销毁并重建

会调用onSaveInstanceState方法，该方法在onStop之前调用，activity还会走正常生命流程被销毁，onSaveInstanceState会将所保存的bundle对象作为参数同时传给onRestoreInstanceState和onCreate方法。onRestoreInstanceState会onStart之后调用。

在onSaveInstanceState和onRestoreInstanceState方法中，系统自动为我们做了一定的恢复工作。当Activity在异常情况下需要重新创建时，系统会默认为我们保存当前Activity的视图结构，并且在Activity重启后为我们恢复这些数据，比如文本框中用户输入的数据、ListView滚动的位置等，这些View相关的状态系统都能够默认为我们恢复。具体针对某一个特定的View系统能为我们恢复哪些数据，我们可以查看View的源码。和Activity一样，每个View都有onSaveInstanceState和onRestoreInstanceState。

关于view的保存：
Activity会调用onSaveInstanceState去保存数据，然后Activity会委托Window去保存数据，接着Window再委托它上面的顶级容器去保存数据。顶层容器是一个ViewGroup，一般来说它很可能是DecorView。最后顶层容器再去一一通知它的子元素来保存数据，这样整个数据保存过程就完成了。

2.1、资源不足导致低优先级的activity被杀死

Activity按照优先级从高到低，可以分为如下三种：（1）前台Activity——正在和用户交互的Activity，优先级最高。（2）可见但非前台Activity——比如Activity中弹出了一个对话框，导致Activity可见但是位于后台无法和用户直接交互。（3）后台Activity——已经被暂停的Activity，比如执行了onStop，优先级最低。
当系统内存不足时，系统就会按照上述优先级去杀死目标Activity所在的进程

1.2、Activity的启动模式

• standard 当我们用ApplicationContext去启动standard模式的Activity的时候会报错，这是因为standard模式的Activity默认会进入启动它的Activity所属的任务栈中，但是由于非Activity类型的Context（如ApplicationContext）并没有所谓的任务栈，所以这就有问题了。
• singleTop 栈顶复用
• singleTask 单实例模式。当一个具有singleTask模式的Activity请求启动后，比如Activity A，系统首先会寻找是否存在A想要的任务栈，如果不存在，就重新创建一个任务栈，然后创建A的实例后把A放到栈中。如果存在A所需的任务栈，这时要看A是否在栈中有实例存在，如果有实例存在，那么系统就会把A调到栈顶并调用它的onNewIntent方法，如果实例不存在，就创建A的实例并把A压入栈中
• singleInstance:单实例模式。 这是一种加强的singleTask模式，它除了具有singleTask模式的所有特性外，还加强了一点，那就是具有此种模式的Activity只能单独地位于一个任务栈中，换句话说，比如Activity A是singleInstance模式，当A启动后，系统会为它创建一个新的任务栈，然后A独自在这个新的任务栈中，由于栈内复用的特性，后续的请求均不会创建新的Activity，除非这个独特的任务栈被系统销毁了。
  
  

1.3、Activity所在的任务栈

TaskAffinity，可以翻译为任务相关性。这个参数标识了一个Activity所需要的任务栈的名字，默认情况下，所有Activity所需的任务栈的名字为应用的包名。

skAffinity属性主要和singleTask启动模式或者allowTaskReparenting属性配对使用，在其他情况下没有意义。

当TaskAffinity和singleTask启动模式配对使用的时候，它是具有该模式的Activity的目前任务栈的名字，待启动的Activity会运行在名字和TaskAffinity相同的任务栈中。

当TaskAffinity和allowTaskReparenting结合的时候，这种情况比较复杂，会产生特殊的效果。当一个应用A启动了应用B的某个Activity后，如果这个Activity的allowTaskReparenting属性为true的话，那么当应用B被启动后，此Activity会直接从应用A的任务栈转移到应用B的任务栈中。

1.4、Activity的Flags

• FLAG_ACTIVITY_NEW_TASK 这个标记位的作用是为Activity指定“singleTask”启动模式，其效果和在XML中指定该启动模式相同
• FLAG_ACTIVITY_SINGLE_TOP 这个标记位的作用是为Activity指定“singleTop”启动模式，其效果和在XML中指定该启动模式相同。
• FLAG_ACTIVITY_CLEAR_TOP 具有此标记位的Activity，当它启动时，在同一个任务栈中所有位于它上面的Activity都要出栈。这个模式一般需要和FLAG_ACTIVITY_NEW_TASK配合使用，在这种情况下，被启动Activity的实例如果已经存在，那么系统就会调用它的onNewIntent。如果被启动的Activity采用standard模式启动，那么它连同它之上的Activity都要出栈，系统会创建新的Activity实例并放入栈顶。
• FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS 具有这个标记的Activity不会出现在历史Activity的列表中，当某些情况下我们不希望用户通过历史列表回到我们的Activity的时候这个标记比较有用。

1.5、intentfilter的匹配规则

启动Activity分为两种，显式调用和隐式调用。二者的区别这里就不多说了，显式调用需要明确地指定被启动对象的组件信息，包括包名和类名，而隐式调用则不需要明确指定组件信息。

intentfilter中存在的过滤信息有action、category、data，只有一个Intent同时匹配action类别、category类别、data类别才算完全匹配。一个Activity中可以有多个intent-filter，一个Intent只要能匹配任何一组intent-filter即可成功启动对应的Activity

• 一个过滤规则中可以有多个action，那么只要Intent中的action能够和过滤规则中的任何一个action相同即可匹配成功。
• category 是一个字符串。Intent中如果出现了category，不管有几个category，对于每个category来说，它必须是过滤规则中已经定义了的category。Intent中可以没有category，如果没有category的话，按照上面的描述，这个Intent仍然可以匹配成功。
• data的匹配规则和action类似，如果过滤规则中定义了data，那么Intent中必须也要定义可匹配的data。data由两部分组成，mimeType和URI。data由两部分组成，mimeType和URI。mimeType指媒体类型，比如image/jpeg、audio/mpeg4-generic和video/*等。URI的默认值为content和file。也就是说，虽然没有指定URI，但是Intent中的URI部分的schema必须为content或者file才能匹配，这点是需要尤其注意的。