Fragment Transactions & Activity State Loss

Fragment Transactions & Activity State Loss

来自Importnew

下面的堆栈跟踪和异常代码，自从Honeycomb的初始发行版本就一直使得StackOverflow很迷惑。

[code]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)

这篇博客将会解释，这个异常在什么时候和为什么会发生。而且，提供几种方法使得这种异常不会出现在你的应用中。

Why was the Exception thrown?

这种异常的出现是由于，你在activity的状态保存之后，尝试去提交一个FragmentTransaction。这种现象被称为活动状态丢失（Activity State Loss）。然而，在我们了解这种异常的真正含义的详情之前，让我们先看看当onSaveInstanceState函数被调用的时候到底发生了什么。正如我在最近的关于Binders
& Death Recipients的博客里面讨论的，Android的应用在Android运行环境里很难决定自己的命运。Android系统可以在任何时候通过结束一个进程来释放内存，而且background activities可能在没有任何警告的情况下被清理。为了确保这种不确定的行为对于用户是透明的，在Activity可以销毁之前，通过调用onSaveInstanceState方法，架构给于了每个Activity一个保存自身状态的机会。在重新加载已保存的状态时，对于foreground和background
Activities的切换，给予了用户无缝切换的体验。用户不用去关心这个Activity是否被系统销毁了。

在框架调用onSaveInstanceState方法时，给这个方法传递了一个Bundle对象，Activity可以通过这个对象来存储它的状态，而且Activity把它的dialogs，fragments以及views的状态都保存在这个对象里面。当这个函数返回时，系统打包这个Bundle对象通过一个Binder接口传递给系统服务处理，然后它会被安全的存储下来。当系统决定重新创建这个Activity的时候，它会给这个应用传回一个相同的Bundle对象，通过这个对象可以重新装载Activity销毁时的状态。

那为什么会抛出这个异常呢？这个问题源于这些Bundle对象代表一个Activity在调用onSaveInstanceState方法的瞬间的一个快照的一个事实，仅此而已。这意味着，当你在onSaveInstanceState方法调用之后调用FragmentTransaction的commit方法，这个transaction将不会被记住，因为它没有在第一时间记录为这个Activity的状态的一部分。从用户的角度来看，这个transaction将会丢失，导致UI状态可能丢失。为了保证用户的体验，Android不惜一切代价避免状态的丢失，因此无论它什么时候发生，都将简单的抛出一个IllegalStateException异常。

When is the exception thrown?

如果之前你遇到过这个异常，也许你已经注意到异常抛出的时间在不同的版本平台上是有细微的差别的。比如，你也许发现老版本的机器抛出异常的频率更低，或者你的应用使用support library比使用官方的框架类的时候更容易抛出异常。这个细微的区别已经导致一些人在猜测support library是有bug的，不能相信的。然而，这样的猜想是完全不正确的。

这些细微的区别存在的原因是源于Honeycomb上对于Activity生命周期所做的巨大改变。在Honeycomb之前，activity直到他们被暂停才考虑被销毁，这意味着在onPause方法之前onSaveInstanceState方法被立即调用。然而，从Honeycomb开始，考虑销毁Activity只能是在他们停止之后，这意味着onSaveInstanceState方法现在是在onStop方法之前调用，以此代替在onPause方法之前调用。这些不同点总结如下表：

	pre-Honeycomb	post-Honeycomb
Activities can be killed before onPause()?	NO	NO
Activities can be killed before onStop()?	YES	NO
onSaveInstanceState(Bundle) is guaranteed to be called before...	onPause()	onStop()

作为Activity生命周期已做的细微改变的结果，support library有时候需要根据平台的版本来改变它的行为。比如，在Honeycomb及以上的设备中，每当一个commit方法在onSaveInstanceState方法之后调用时，都会抛出一个异常来提醒开发者状态丢失发生了。然而，在Honeycomb之前的设备上，每次它发生时并抛出异常将更受限制，他们的onSaveInstanceState方法在Activity的生命周期中更早调用，而作为结果更容易发生状态丢失。Android团队被迫做了一个折中的办法：为了更好的与老版本平台交互，老的设备不得不接受偶然状态丢失可能发生在onPause方法和onStop方法之间。support
library在不同平台的行为总结如下表：

	pre-Honeycomb	post-Honeycomb
commit() before onPause()	OK	OK
commit() between onPause() and onStop()	STATE LOSS	OK
commit() after onStop()	EXCEPTION	EXCEPTION

How to avoid the exception?

一旦你了解了到底发生了什么，避免发生Activity状态丢失将会很简单。如果你读了这篇博客，那么很幸运你更好的了解了support library是怎么工作的，以及在你的应用中避免状态丢失为什么如此的重要。假如你查看这个博客是为了查找快速解决的办法，那么，当你在你的应用中使用FragmentTransactions的时候，这里有些建议你应该记在心里：

当你在Activity生命周期函数里面提交transactions的时候要小心点。大部分的应用仅仅在onCreate方法被调用的开始时间提交transactions，或者在相应用户输入的时候，因此将不可能碰到任何问题。然而，当你的transactions在其他的Activity生命周期函数提交，如onActivityResult(), onStart(), and onResume()，事情将会变得微妙。例如，你不应该在FragmentActivity的onResume方法中提交transactions，因为有些时候这个函数可以在activity的状态恢复前被调用（可以查看相关文档了解更多信息）。如果你的应用要求在除onCreate函数之外的其他Activity生命周期函数中提交transaction，你可以在FragmentActivity的onResumeFragments函数或者Activity的onPostResume函数中提交。这两个函数确保在Activity恢复到原始状态之后才会被调用，从而避免了状态丢失的可能性。（给一个如何可以做到这点的例子，看看我对this
StackOverflow question的回答，来想想如何提交FragmentTransactions作为Activity的onActivityResult方法被调用的响应）。

避免在异步回调函数中提交transactions。包括常用的方法，比如AsyncTask的onPostExecute方法和LoaderManager.LoaderCallbacks的onLoadFinished方法。在这些方法中执行transactions的问题是，当他们被调用的时候，他们完全没有Activity生命周期的当前状态。例如，考虑下面的事件序列：

一个activity执行一个AsyncTask。

用户按下“Home”键，导致activity的onSaveInstanceState和onStop方法被调用。

AsyncTask完成并且onPostExecute方法被调用，而它没有意识到activity已经结束了。

在onPostExecute函数中提交的FragmentTransaction，导致抛出一个异常。 一般，避免这种类型异常的最好办法就是不要在异步回调函数中提交transactions。Google工程师似乎同意这个信条。根据Android Developers group上的这篇文章,Android团队认为UI主要的改变，源于从异步回调函数提交FragmentTransactions引起不好的用户体验。如果你的应用需要在这些回调函数中执行transaction而没有简单的方法可以确保这个回调函数不好在onSaveInstanceState之后调用。你可能需要诉诸于使用commitAllowingStateLoss方法，并且处理可能发生的状态丢失。(可以看看StackOverflow上的另外两篇文章，here和here)。

作为最后的办法使用commitAllowingStateLoss函数。commit函数和commitAllowingStateLoss函数的唯一区别就是当发生状态丢失的时候，后者不会抛出一个异常。通常你不应该使用这个函数，因为它意味可能发生状态丢失。当然，更好的解决方案是commit函数确保在activity的状态保存之前调用，这样会有一个好的用户体验。除非状态丢失的可能无可避免，要不然commitAllowingStateLoss函数不应该被使用。

文章引用于Fragment
Transactions & Activity State Loss