android activity詳解三：儲存activity的狀態

文章目錄

• 儲存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就會被系統銷毀，然後重新建立（應該是進程被關閉！――不會吧？效率不高哦）。