activity状态保存讲解四

Activity/View onSaveInstanceState和onRestoreInstanceState触发的时机/必要条件

1：先看Application Fundamentals上的一段话：

  Android calls onSaveInstanceState() before the activity becomes vulnerable to being destroyed by the system, but does not bother calling it when the instance is actually being destroyed by a user action (such as pressing the BACK key)

 从这句话可以知道，当某个activity变得“容易”被系统销毁时，该activity的onSaveInstanceState就会被执行，除非该activity是被用户主动销毁的，例如当用户按BACK键的时候。

注意上面的双引号，何为“容易”？言下之意就是该activity还没有被销毁，而仅仅是一种可能性。这种可能性有哪些？通过重写一个activity的所有生命周期的onXXX方法，包括onSaveInstanceState和onRestoreInstanceState方法，我们可以清楚地知道当某个activity（假定为activity A）显示在当前task的最上层时，其onSaveInstanceState方法会在什么时候被执行，有这么几种情况：

1、当用户按下HOME键时。

这是显而易见的，系统不知道你按下HOME后要运行多少其他的程序，自然也不知道activity A是否会被销毁，故系统会调用onSaveInstanceState，让用户有机会保存某些非永久性的数据。以下几种情况的分析都遵循该原则
2、长按HOME键，选择运行其他的程序时。
3、按下电源按键（关闭屏幕显示）时。
4、从activity A中启动一个新的activity时。
5、屏幕方向切换时，例如从竖屏切换到横屏时。

在屏幕切换之前，系统会销毁activity A，在屏幕切换之后系统又会自动地创建activity A，所以onSaveInstanceState一定会被执行

总而言之，onSaveInstanceState的调用遵循一个重要原则，即当系统“未经你许可”时销毁了你的activity，则onSaveInstanceState会被系统调用，这是系统的责任，因为它必须要提供一个机会让你保存你的数据（当然你不保存那就随便你了）。
至于onRestoreInstanceState方法，需要注意的是，onSaveInstanceState方法和onRestoreInstanceState方法“不一定”是成对的被调用的，onRestoreInstanceState被调用的前提是，activity A“确实”被系统销毁了，而如果仅仅是停留在有这种可能性的情况下，则该方法不会被调用，例如，当正在显示activity A的时候，用户按下HOME键回到主界面，然后用户紧接着又返回到activity A，这种情况下activity A一般不会因为内存的原因被系统销毁，故activity A的onRestoreInstanceState方法不会被执行

另外，onRestoreInstanceState的bundle参数也会传递到onCreate方法中，你也可以选择在onCreate方法中做数据还原.

 

2：view自己也有相应的onSaveInstanceState和onRestoreInstanceState，它的出发时机于此不同。

    The default implementation takes care of most of the UI per-instance state for you by calling onSaveInstanceState() on each view in the hierarchy that has an id, and by saving the id of the currently focused view (all of which is restored by the default implementation of onRestoreInstanceState(Bundle)). If you override this method to save additional information not captured by each individual view, you will likely want to call through to the default implementation, otherwise be prepared to save all of the state of each view yourself. If called, this method will occur before onStop(). There are no guarantees about whether it will occur before or after onPause().

    默认的实现负责了大部分UI实例状态(的保存)，采用的方式是调用UI层上每个拥有id的view的onSaveInstanceState() ，并且保存当前获得焦点的view的id(所有保存的状态信息都会在默认的onRestoreInstanceState(Bundle)实现中恢复)。如果你覆写这个方法来保存额外的没有被各个view保存的信息，你可能想要在默认实现过程中调用或者自己保存每个视图的所有状态。如果被调用，这个方法会在onStop()前被触发，但系统并不保证是否在onPause()之前或者之后触发。

有如下两个必要条件：

1.设定有指定的id:   

android:id="@+id/gallary"

2.设定saveEnabled:
       android:saveEnabled="true"

在“acitvity的生命周期”一节中提到了当暂停和停止时，activity的状态是被保留在内存中的，当resume时，它会立即开始执行。

左图表示acitvity未销毁，只是被停止再开始的过程，右图表示acvitiry所在的进程被关了，那么acitvity就销毁了，然后又被重新创建的过程。

      当用户在开启一个新activity时，当前的activity可能在内存中处于停止状态也可能由于新activity需要更多内存而被系统杀掉了，但不论怎样，当用户在新activity上按返回键时，他希望看到的是原先的activity的界面。原先的activity如果是被重新创建，那么它要恢复到用户最后看到它的样子。那么我们怎么做呢？其实也不难，跟据上一节所述，在onPause()或onStop()或onDestyroy()中保存必要的数据就行了。但是现在google又冒出一个新的东西：onSaveInstanceState()，观其名可知其意：它是专门用来保存实例状态的，这个“实例”不是指的activity对象，而是它所在的进程，因为activity的销毁是因为它所在的进程被杀而造成的。onSaveInstanceState()是在系统感觉需要杀死activity时调用的，它被传入一个参数：Bundle，这个Bundle可以被认为是个map,字典之类的东西，用”键－值”来保存数据。

现在又叫人蛋疼了：不是可以在onPause()中保存数据吗？为什么又搞出这样一个家伙来？它们之间是省木关系呢？原来onSaveInstanceState()的主要目的是保存activity的状态有关的数据，当系统在杀死activity时，如果它希望activity下次出现的样子跟现在完全一样，那么它就调用这个onSaveInstanceState()，否则就不调用。所以要明白这一点：onSaveInstanceState()并不是永远都会调用。比如，当用户在一个activity上按返回时，就不会调用，因为用户此时明确知道这个activity是要被销毁的，并不期望下次它的样子跟现在一样（当然开发者可以使它保持临死时的表情，你非要这样做，系统也没办法），所以就不用调用onSaveInstanceState()。现在应该明白了：在onPause()，onStop()以及onDestroy()中需要保存的是那些需要永久化是数据，而不是保存用于恢复状态的数据，状态数据有专门的方法：onSaveInstanceState()。

数据保存在一个Bundle中，Bundle被系统永久化。当再调用activity的onCreate()时，原先保存的bundle就被传入，以恢复上一次临死时的模样，如果上次死时没有保存Bundle，则为null。

      还没完呢，如果你没有实现自己的onSaveInstanceState()，但是activity上控件的样子可能依然能被保存并恢复。原来activity类已实现了onSaveInstanceState()，在onSaveInstanceState()的默认实现中，会调用所有控件的相关方法，把控件们的状态都保存下来，比如EditText中输入的文字，CheckBox是否被选中等等。然而不是所有的控件都能被保存，这取决于你是否在layout文件中为控件赋了一个名字(Android:id)。有名的就存，无名的不管。

      既然有现成的可用，那么我们到底还要不要自己实现onSaveInstanceState()?这得看情况了，如果你自己的派生类中有变量影响到UI，或你程序的行为，当然就要把这个变量也保存了，那么就需要自己实现，否则就不需要，但大多数情况肯定需要自己实现一下下了。对了，别忘了在你的实现中调用父类的onSaveInstanceState()。

注：由于onSaveInstanceState()并不是每次销毁时都会调用，所以不要在其中保存那些需要永久化的数据，执行保存那些数据的最好地方是：onPause()中。

测试你程序的状态恢复能力的最好方法是：旋转屏幕，每当屏幕的方向改变时，当前的activity就会被系统销毁，然后重新创建（应该是进程被关闭！――不会吧？效率不高哦）