使用FragmentTransaction的commit方法经常遇见下面的crash
java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState
at android.support.v4.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1341)
at android.support.v4.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:1352)
at android.support.v4.app.BackStackRecord.commitInternal(BackStackRecord.java:595)
at android.support.v4.app.BackStackRecord.commit(BackStackRecord.java:574)
下面解释一下为什么会抛出这个exception，然后提出几条避免这个exception的有效的建议：
为什么会产生这个exception
exception产生的原因是调用onSaveInstanceState()，Activity的state保存之后，又尝试去提交一个FragmentTransaction,从而造成Activity状态丢失（Activity state loss）的现象，
那么先看一下onSaveInstanceState()这个方法做了什么，在Android系统中，应用程序几乎不能控制自己的命运，Android系统有权在任何时候杀死APP来释放内存，并且位于后台的Activity可能在没有提示的情况被杀死，为了保证这些不稳定的表现对用户不可见，在Activity遭到破坏之前，Activity可以通过调用onSaveInstanceState()来保存自己的状态，之后保存的状态恢复，用户感觉就像无缝的切换了Activity，就像Activity没有被系统杀掉一样。
当系统调用onSaveInstanceState()时，会传给Activity一个Bundle用来保存当前Activity的状态，Activity记录下它的Dialog，Fragment和View的状态，当该方法返回时，系统将Bundle对象包装在Binder接口中，并将其A安全的存贮在System Server进程中，当系统稍后决定重建Activity时，这个Bundle将会被传回应用，来恢复Activity旧的状态。
Exception产生的原因，是因为在onSaveInstanceState()调用时，这个Bundle对象仅仅代表Activity的一个snapshot，这意味着在onSaveInstanceState()之后调用FragmentTransaction#commit()这个事务将不会被记住，因为他在状态保存的时候并没有被记录为Activity状态的一部分，从用户的角度来看，这个事务看起来像是丢失了，导致UI状态丢失，为了保证用户体验，当发生状态丢失时，Android会抛出IllegalStateException
什么时候抛出这个Exception
这个异常的抛出时机在Android 3.0之前和Android 3.0 之后的有一些差别，在Android 3.0前后Activity的生命周期有了很大的变化，在3.0之前，Activity在onPause()之后便认为是可以杀死的，因此onSaveInstanceState()在onPause()之前立即被调用，然而在Android3.0之后，Activity只有在onStop()之后才被认为是可以杀死的，这意味着onSaveInstanceState()在onStop()之前被调用，而不是onPause() 见下表格：
| Android 3.0之前 | Android 3.0之前 | |
|---|---|---|
Activities can be killed before onPause()? |
NO | NO |
Activities can be killed before onStop()? |
YES | NO |
onSaveInstanceState(Bundle) 在什么函数前被调用 |
onPause() |
onStop() |
由于Android 3.0生命周期发生了一些变化，Support Library需要根据不同的版本产生不同的行为
例如：
| Android 3.0之前 | Android 3.0之前 | |
|---|---|---|
commit() before onPause()
|
OK | OK |
commit() between onPause() and onStop()
|
STATE LOSS | OK |
commit() after onStop()
|
EXCEPTION | EXCEPTION |
在Android 3.0以及之后的设备上，每次在onSaveInstanceState()后面调用commit()都会抛出异常，但是，每次发生这种情况时都会抛出异常，这对3.0以下的设备上的限制太多了，为了更好的与旧版本平台进行交互，因此他们做出妥协，在较旧的设备上必须忍受onPause()和onStop()之间可能意外丢失的状态，见下表
| Android 3.0之前 | Android 3.0之前 | |
|---|---|---|
commit() before onPause()
|
OK | OK |
commit() between onPause() and onStop()
|
STATE LOSS | OK |
commit() after onStop()
|
EXCEPTION | EXCEPTION |
如何避免这个Exception
当在程序中使用FragmentTransactions时，下面是一些建议
- 注意在Activity的生命周期方法中提交事务，在第一次调用
onCreate()时或者为了响应用户事件提交事务不会有什么问题，如果是在onCreate()之外的方法中提交事务则在FragmentActivity＃onResumeFragments()或Activity＃onPostResume()中执行。这两种方法保证在Activity恢复到原来的状态之后被调用，从而避免了状态一起丢失的可能性。 - 避免在异步回调方法中执行事务，AsyncTask、Loader等，在异步回调方法中，不能确定当前Activity生命周期的状态，容易发生异常，如果应用程序需要在异步回调方法中执行事务，那么可以使用
commitAllowingStateLoss() - 使用
commitAllowingStateLoss()是作为最后的兜底方法，调用commit()和commitAllowingStateLoss()之间的唯一区别是，如果发生状态丢失，后者不会抛出异常。 通常不建议使用这种方法，因为这意味着有可能发生状态损失。除非无法避免状态丢失的可能性，否则不应使commitAllowingStateLoss()
网友评论