Android 浅谈 Activity （下）

Android 浅谈 Activity（中）

上节讲了数据传递和数据回传，这节讲一讲状态保存以及启动模式。

在使用Bundle传递数据时，要注意，Bundle的大小是有限制的 < 0.5MB，如果大于这个值
是会报TransactionTooLargeException异常的！！！

Activity 状态保存

每次我们写一个Activity 的时候，都要重写onCreate()方法，onCreate(Bundle saveInstanceState) 方法里面有一个Bundle，这个Bundle究竟是什么呢？其实这个是系统用于给我们保存状态用的，简而言之，如果你的App 长时间处于stopped 形态而且系统需要更多内存或者系统内存极为紧张时，系统就会回收你的 Activity，这种被强制回收或者意外终止的情况用户体验是非常不好的。你可以想象一下，如果你正在看一个帖子，里面有100行文字，你看到了第50行，然后接了个电话，出去吃饭了，回来想继续看的时候却发现当前停留的是第0行，而不是第50行，这种体验肯定很不好。

所以，系统提供了保存状态的回调以作补偿。Bundle 里面可以存储一下简单的数据、状态。

既然讲清楚了这些，那 onSaveInstanceState(Bundle outState) 和 onRestoreInstanceState(Bundle savedInstanceState) 这两个回调也就可以理解了。他们俩一个代表存，一个代表取。

而 onSaveInstanceState(Bundle outState) 什么时候调用呢？查阅了大量的资料，并经过测试发现，以下几种情形会被调用：

1.当点击 home 键回到主页或者长按 home 键选择其他应用程序时调用；
2.按下电源键锁屏的时候会调用；
3.启动一个新的 Activity 时调用；
4.横竖屏切换的时候，调用，这个很好理解，因为你横竖屏切换的时候，其实是销毁了当前 Activity 然后再创建。

而 onRestoreInstanceState() 一般都是在onStart() 和 onResume() 之间调用。

比如综合上述 onSaveInstanceState() 的存数据的时机也可以想象，并不一定只有在Activity 销毁时才会去存，但是无论是哪种情况，当再次返回应用或者再次返回Activity 时，肯定调用了onStart()和onResume()，所以我们也就能理解为什么onRestoreInstanceState() 在这两个生命周期之间调用了。

注意：取数据的时候并不一定只有*onRestoreInstanceState()*才能做得到，我们天天重写的*onCreate()*也能做得到。

onRestoreInstanceState() 和 onCreate() 的区别是：

onRestoreInstanceState() 一旦被调用，其参数 Bundle savedInstanceState 一定是有值的，我们不用额外第判断是否为空；
但是onCreate() 不行，onCreate() 如果是正常启动，其参数Bundle savedInstanceState肯定为null，所以我们必须要额外判断。
这两个方法，官方推荐采用 onRestoreInstanceState() 去恢复数据。

讲了一堆概念性的东西，国际惯例，上代码。

package com.mesmerize.activitystate;import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;public class MainActivity extends AppCompatActivity {@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);System.out.println("MainActivity.onCreate");if (savedInstanceState != null) {String test_result = savedInstanceState.getString("test_result");System.out.println("[MainActivity.onCreate] :: test_result = " + test_result);}}@Overrideprotected void onSaveInstanceState(Bundle outState) {super.onSaveInstanceState(outState);System.out.println("MainActivity.onSaveInstanceState");outState.putString("test_result","且随疾风前行,身后一许流星.");}@Overrideprotected void onRestoreInstanceState(Bundle savedInstanceState) {super.onRestoreInstanceState(savedInstanceState);String test_result = savedInstanceState.getString("test_result");System.out.println("[MainActivity.onRestoreInstanceState] :: test_result = " + test_result);}@Overrideprotected void onStart() {super.onStart();System.out.println("MainActivity.onStart");}@Overrideprotected void onPause() {super.onPause();System.out.println("MainActivity.onPause");}@Overrideprotected void onStop() {super.onStop();System.out.println("MainActivity.onStop");}@Overrideprotected void onDestroy() {super.onDestroy();System.out.println("MainActivity.onDestroy");}
}

代码很简单，就是给大家看看调用顺序，用于验证上述结论。
最简单的其实最有力道，工作后你就发现，理解了调用顺序，调换一下代码的执行顺序就能解决你2,300行代码解决不了的事情。

看现象，当我启动应用的时候：

09-22 09:30:21.607 1869-1869/com.mesmerize.activitystate I/System.out: MainActivity.onCreate
09-22 09:30:21.607 1869-1869/com.mesmerize.activitystate I/System.out: MainActivity.onStart

为了最直观有效，我只验证横竖屏切换的结果了，其他的结果，有兴趣可以自己验证，我就不在大篇幅的累述。
当我切换横屏时：

09-22 09:34:33.951 1869-1869/com.mesmerize.activitystate I/System.out: MainActivity.onPause
09-22 09:34:33.951 1869-1869/com.mesmerize.activitystate I/System.out: MainActivity.onSaveInstanceState
09-22 09:34:33.951 1869-1869/com.mesmerize.activitystate I/System.out: MainActivity.onStop
09-22 09:34:33.951 1869-1869/com.mesmerize.activitystate I/System.out: MainActivity.onDestroy
09-22 09:34:33.967 1869-1869/com.mesmerize.activitystate I/System.out: MainActivity.onCreate
09-22 09:34:33.967 1869-1869/com.mesmerize.activitystate I/System.out: [MainActivity.onCreate] :: test_result = 且随疾风前行,身后一许流星.
09-22 09:34:33.967 1869-1869/com.mesmerize.activitystate I/System.out: MainActivity.onStart
09-22 09:34:33.967 1869-1869/com.mesmerize.activitystate I/System.out: [MainActivity.onRestoreInstanceState] :: test_result = 且随疾风前行,身后一许流星.

可以看到，onPause() 之后onSaveInstanceState() 就执行了，在这里我存了一个 String 。而后Activity 重新创建，走了onCreate() 并判断saveInstanceState参数不为null，取出数据“且随疾风前行，身后一许流星。”然后走了onStart()和onRestoreInstanceState 并取出相同的数据“且随疾风前行，身后一许流星。”

以上演示了一个简单的存取字符串，其实它还能存更多更多类型的数据，比如Bundle、比如Byte、比如Char、比如Parcelable等等等等。

Activity 启动模式

为什么要有 LaunchMode

为什么 Activity 要有启动模式？
默认情况下，当我们多次启动同一个 Activity 的时候，系统就会创建多个实例并把它们一一放入任务栈中，当我们按返回键，会发现这些 Activity 会一一回退。任务栈是一种“后进先出”的栈结构，这个比较好理解，每按一下返回键就会有一个 Activity 出栈，直到栈空位置，当栈中无任何 Activity 的时候，系统就会回收这个任务栈。直到了 Activity 的默认启动模式以后，我们可能就会发现一个问题：多次启动同一个 Activity，系统重复创建多个实例，这样不是很傻吗？这样的确有点傻，Android 在设计的时候不可能不考虑到这个问题，所以它提供了启动模式来修改系统的默认行为。目前有四种启动模式：standard、singleTop、singleTask 和 singleInstance，下面先介绍各种启动模式的含义。

standard

   默认的启动模式，如果不指定 Activity 的启动模式，则使用这种方式启动 Activity。每次启动一个 Activity 都会重新创建一个新的实例，不管这个实例是否已经存在。被创建的实例的生命周期符合典型情况下 Activity 的生命周期，它的onCreate、onStart、onResume 都会被调用。这是一个典型的多实例实现，一个任务栈中可以有多个实例，每个实例也可以属于不同的任务栈。在这种模式下，谁启动了这个 Activity，那么这个 Activity 就运行在启动它的那个 Activity 所在的栈中。比如 Activity A 启动了 Activity B（B是标准模式），那么 B 就会进入到 A 所在的栈中。

singleTop

   栈顶复用模式。在这种模式下，如果新 Activity 已经位于任务栈的栈顶，那么此 Activity 不会被重新创建，同时它的 onNewIntent 方法会被回调。而此时这个 Activity 的onCreate、onStart、onResume 不会被系统调用，因为它并没有发生改变。如果新 Activity 的实例已存在但不是位于栈顶，那么新 Activity 仍然会重新创建。举例：比如目前栈内的情况为ABCD，其中ABCD为四个 Activity，A位于栈底，D位于栈顶，这个时候如果要再次启动D，如果D的启动模式为 singleTop，那么栈内的情况仍然为ABCD；如果D的启动模式为standard，那么由于D被重新创建，栈内的情况就变为ABCDD；而如果启动的是A，并且A的启动模式是 singleTop 的话，由于A不在栈顶，A会被重新创建，栈内的情况就变为ABCDA。

singleTask

   栈内复用模式。这是一种单实例模式，在这种情况下，只要 Activity 在一个栈中存在，那么多次启动此 Activity 都不会重新创建实例，和singleTop一样，系统也会回调其 onNewIntent。具体一点，当一个具有 singleTask 模式的 Activity 请求启动后。比如 Activity A，系统首先会寻找是否存在 A 想要的任务栈，如果不存在，就重新创建一个任务栈，然后创建 A 的实例并把 A 放到栈中。如果存在 A 所需的任务栈，这时要看 A 是否在栈中有实例存在，如果有实力存在，那么系统就会把 A 调到栈顶并调用它的 onNewIntent 方法，如果实例不存在，就创建 A 的实例并把 A 压入栈中。举例：比如目前任务栈 S1 中的情况为 ABC，这个时候 Activity D以 singleTask 模式请求启动，其所需要的任务栈为 S2，由于 S2 和 D 的实例均不存在，所以系统会先创建任务栈 S2 ，然后再创建 D 的实例并将其入栈到 S2。另外一种情况，假设 D 所需的任务栈为 S1，那么由于 S1 已经存在，所以系统会直接创建 D 的实例并将其入栈到 S1。如果 D 所需的任务栈为 S1，并且当前任务栈 S1 的情况为 ADBC，根据栈内复用原则，此时 D 不会重新创建，系统会把 D 切换到栈顶并调用其 onNewIntent，同时由于 singleTask 默认具有 clearTop 的效果，会导致栈内所有在 D 上面的 Activity 全部出栈，于是最终 S1 中的情况为 AD。

singleInstance

   单实例模式。这是一种加强的 singleTask 模式，它除了具有 singleTask 模式的所有特性外，还加强了一点，那就是具有此种模式的 Activity 只能单独地位于一个任务栈中，换句话说，比如 Activity A 是singleInstance 模式，当 A 启动后，系统会为它创建一个新的任务栈，然后 A 独自在这个新的任务栈中，由于栈内复用的特性，后续的请求均不会创建新的 Activity ，除非这个独特的任务栈被系统销毁了。

上面介绍了几种启动模式，有一种情况要指出。

比如目前有 2 个任务栈，一个前台一个后台，前台任务栈的情况为 AB，而后台任务栈的情况为 CD，这里假设 CD 的启动模式均为 singleTask。现在请求启动D，那么整个后台任务栈都会被切换到前台，这个时候整个后退列表就变成了 ABCD。当用户按后退键的时候，列表中的 Activity 会一一出栈，按照 D->C->B->A 的情况一一出栈。
而如果不是请求启动 D 而是启动 C ，那么情况就不一样了，整个后退列表就变成了 ABC ，后退的时候会按照 C->B->A 的顺序退出。

给 Activity 指定启动模式有两种方法，第一种是通过 AndroidMainifest 给 Activity 指定启动模式，如下所示：

<activity
    android:name="全类名"android:launchMode="singleTask"/>

另一种情况是通过在 Intent 中设置标志位来为 Activity 指定启动模式，比如：

Intent intent = new Intent(this,目标Activity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);

这两种方式都可以为 Activity 指定启动模式，但是二者还是有区别的。首先，优先级不同，第二种方式的优先级要高于第一种，当两种同时存在时，以第二种方式为准；

Activity 的 Flags 有很多，作用也很多，有的标记为可以设定 Activity 的启动模式，比如 FLAG_ACTIVITY_NEW_TASK 和 FLAG_ACTIVITY_SINGLE_TOP 等；还有的标记位可以影响 Activity 的运行状态，比如FLAG_ACTIVITY_CLEAR_TOP 和 FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS 等。

FLAG_ACTIVITY_NEW_TASK

   这个标记位的作用是为 Activity 指定“singleTask”启动模式，其效果和在 XML 中指定该启动模式相同。

FLAG_ACTIVITY_SINGLE_TOP

   这个标记位的作用是为 Activity 指定“singleTop”启动模式，其效果和在 XML 中指定该启动模式相同。

FLAG_ACTIVITY_CLEAR_TOP

   具有此标记位的 Activity，当它启动时，在同一个任务栈中所有位于它上面的 Activity 都要出栈。这个标记位一般会和 singleTask 启动模式一起出现，在这种情况下，被启动 Activity 的实例如果已经存在，那么系统就会调用它的 onNewIntent。如果被启动的 Activity 采用 standard 模式启动，那么它连同它之上的 Activity 都要出栈，系统会创建新的 Activity 实例并放入栈顶。

FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS

   具有此标记的 Activity 不会出现在历史 Activity 的列表中，当某些情况下我们不希望用户通过历史列表回到我们的 Activity 的时候这个标记比较有用。它等同于在 XML 中指定 Activity 的属性 android:excludeFromRecents="true"。

FLAG_ACTIVITY_NO_HISTORY

   使用这种模式启动 Activity，当该 Activity 启动其他 Activity 后，该 Activity 就消失了，不会保留在 Activity 栈中，例如 A-B，B中以这种模式启动 C，C 再启动 D，则当前 Activity 栈为 ABD。