android activity详解三：保存activity的状态

在“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就会被系统销毁，然后重新创建（应该是进程被关闭！――不会吧？效率不高哦）。

补充：移动开发 , Android ,

上一个：android activity详解四：保存activity的状态的更多事项
下一个：android Fragments详解四:管理fragment