Activity

不过，如果系统是为了回收内存而销毁activity，则这个 Activity 对象就会被销毁，这样系统就无法简单地resume一下就能还原完整状态的activity。 如果用户要返回到这个activity的话，系统必须重新创建这个Activity 对象。可是用户并不知道系统是先销毁activity再重新创建了它的，所以，他很可能希望activity完全保持原样。 这种情况下，你可以保证activity状态的相关重要信息都由另一个回调方法保存下来了，此方法让你能保存activity状态的相关信息： onSaveInstanceState()。

在activity变得很容易被销毁之前，系统会调用 onSaveInstanceState()方法。 调用时系统会传入一个Bundle对象， 你可以利用 putString() 之类的方法，以键值对的方式来把activity状态信息保存到该Bundle对象中。 然后，如果系统杀掉了你的application进程并且用户又返回到你的activity，系统就会重建activity并将这个 Bundle 传入onCreate() 和onRestoreInstanceState() 中，你就可以从 Bundle 中解析出已保存信息并恢复activity状态。如果没有储存状态信息，那么传入的 Bundle 将为null（当activity第一次被创建时就是如此

 activity状态完整地返回给用户的两种方式：被销毁destroyed后再被重建，而且必须恢复了之前保存的状态；或是被停止stopped后再被恢复resumed，状态都完整保留着。

注意： activity被销毁之前，并不能确保每次都会调用 onSaveInstanceState() ，因为存在那些不必保存状态的情况（比如用户使用BACK键离开了你的activity，因为用户明显是关了这个activity）。 如果系统要调用 onSaveInstanceState() 方法，那么它通常会在 onStop() 方法之前并且可能是在 onPause() 之前调用。

不过，即使你没有实现 onSaveInstanceState() 方法，有些activity状态还是会通过 Activity 类缺省实现的onSaveInstanceState() 方法保存下来。特别的是，缺省为layout中的每个 View 实现了调用相应的onSaveInstanceState() 方法，这允许每一个view提供自己需被保存的信息。 几乎Android框架下所有的widget都会在适当的时候实现该方法，这样，任何UI上可见的变化都会自动保存下来，并在activity重建后自动恢复。 例如，EditText widget会保存所有用户已经输入的文本， CheckBoxwidget 也会保存是否被选中。你所要做的工作仅仅是为每一个你想要保存其状态的widget提供一个唯一的ID（就是 android:id 属性）。如果这个widget没有ID的话，系统是无法保存它们的状态的。

通过把android:saveEnabled 设置为"false",或者调用 setSaveEnabled() 方法，你也可以显式地阻止layout中的某个view保存状态。 通常不应该禁用保存，不过假如你需要恢复activity UI的各个不同的状态，也许可以这么做。

尽管缺省实现的 onSaveInstanceState() 方法会保存activity UI的有用信息，你仍然需要覆盖它来存入更多的信息。 例如，你可能需要保存在activity生命周期中改变的成员变量值（可能是关于UI恢复的值，但是默认情况下，存放这些UI状态的成员变量值是不会被恢复的）。

因为默认实现的 onSaveInstanceState() 方法已经帮你保存了一些UI的状态，所以如果你重写此方法是为了保存更多的状态信息，那么在执行自己的代码之前应该确保先调用一次父类的 onSaveInstanceState() 方法。同理，如果重写 onRestoreInstanceState() 的话，也应该调用一次父类的该方法，这样缺省的代码就能正常恢复view的状态了。

注意：因为 onSaveInstanceState() 并不保证每次都会被调用，所以你应该只用它来记录activity的一些临时状态信息（UI的状态）——千万不要用它来保存那些需要长久保存的数据。 替代方案是，你应该在用户离开activity的时候利用 onPause() 来保存永久性数据（比如那些需要存入数据库里的数据）。

一个检测应用程序状态恢复能力的好方法就是旋转设备，使得屏幕方向发生改变。 当屏幕的方向改变时，因为要换用符合实际屏幕参数的资源，系统会销毁并重建这个activity。 正因如此，你的activity能够在被重建时完整地恢复状态是非常重要的，因为用户会在使用应用程序时会频繁地旋转屏幕。

配置改动后的处理

设备的某些配置可能会在运行时发生变化（比如屏幕方向、键盘可用性以及语言）。 当发生这些变化时，Android会重建这个运行中的activity（系统会调用 onDestroy() ，然后再马上调用 onCreate() ）。这种设计有助于应用程序适用新的参数配置，通过把你预置的可替换资源（比如对应各种屏幕方向和尺寸的layout）自动重新装载进入应用程序的方式来实现。

如果你采取了适当的设计，让activity能够正确地处理这些因为屏幕方向而引起的重启，并能如上所述地恢复activity状态， 那么你的应用程序将对生命周期中其它的意外事件更具适应能力。

处理这类重启的最佳方式，就是利用 onSaveInstanceState() 和onRestoreInstanceState() （或者 onCreate() ）进行状态的保存和恢复，如上节所述。

多activity的合作

当activity启动另一个activity时，它俩生命周期的状态都会发生转换。 第一个activity paused并stopped（尽管它也可能不会被stopped，如果它仍然后台可见的话），而另一个activity是被created。 如果这两个activity共用了保存在磁盘或其它地方的数据，那么请明白：在第二个activity被created之前，第一个activity还没有完全被stopped，这点非常重要。 或多或少，第二个activity的启动进程与第一个activity的关闭进程在时间上会发生重叠。

生命周期回调方法的顺序是很明确的，特别是两个activity位于同一个进程中、一个启动另一个的时候。 下面就是Aactivity A启动Activity B时的操作顺序：

1. Activity A的 onPause()方法，如果活动后台不可见的话，onStop()方法同样运行，否则不运行。
2. Activity B的 onCreate() ，onStart() 和onResume() 方法依次运行。（Activity B现在获得用户焦点。）

以上预设的生命周期回调方法顺序使你能够对一个activity启动另一个activity时的转换信息进行管理。 例如，如果第一个activity停止时你须写入数据库以便后续的activity可以读取数据，那么你应该在 onPause() 方法而不是 onStop() 方法里写入数据库。