Fragment提交transaction导致state loss异常
来源:互联网 发布:算法具有哪些重要特性 编辑:程序博客网 时间:2024/04/19 16:33
下面自从Honeycomb发布后,下面栈跟踪信息和异常信息已经困扰了StackOverFlow很久了。
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)
这篇文章会解释这个异常什么时候会抛出以及原因,并且会以一些建议收尾。这些建议会帮助你不会因为这个异常导致程序崩溃。
这个异常为什么会抛出?
这个异常什么时候会抛出?
如果你之前已经碰到过这个异常,你可能会注意到异常抛出的时机因为不同的Android版本而不一致。比如,如可能会发现老版本的设备上,这个异常抛出比较不频繁,或者当你的程序中使用support library而不是官方框架中的类时更容易触发这个异常。这些轻微的一致让很多人都以为support library有bug,不值得信任。然而,这些假设都不是正确的。这些轻微的不一致是因为在Honeycomb版本中的Activity生命周期有了重要的变化。Honeycomb之前的版本,activity被认为在pause之前都不会被杀掉,这意味着onSaveInstanceState()会在onPause()之前被调用。从HoneyComb开始,Activity被认为只会在stopped只会被杀掉,意味着onSaveInstanceState()现在会在onStop()之前被调用而不是在onPause()之前。这些变化在下表中总结:
Honeycomb之前 Honeycomb之后
由于Activity生命周期的轻微变化,support library有时候需要根据系统版本选择他的行为。比如,在Honeycomb及以上设备,每次在onSaveInstanceState()之后调用commit()都会抛出一个异常,以便警告开发者已经发生了状态丢失。然而,在每次这种情况抛出异常在Honeycomb之前的设备上就显得太具有限制性了,它们的onSaveInstanceState()调用发生在Activity生命周期中更早的一段时期,并且更容易导致意外的状态丢失。Android团队被迫做出妥协:为了更好地跟老版本兼容,旧设备可能必须要忍受在onPause()和onStop()之间意外的状态丢失。Support library在不同两个版本的行为如下表总结:
怎么避免这个异常?
一旦你懂得了真正发生了什么,避免Activity状态丢失就简单多了。如果你已经在读这篇文章之间就已经解决过这个问题了,希望你能对support library有一个更深的了解,并且知道为什么避免状态丢失对你的程序这么重要。为了方便你通过这篇文章寻找快速的解决方案,这里有一些建议希望你记得在使用FragmentTransactions的时候使用:在Activity生命周期方法中commit transation的时候一定要小心。很多应用程序只会在onCreate()或者为了响应用户输入的时候调用一次,所以他们不会遇到任何问题。然而,当你的transation开始冒险在其他的生命周期(比如onActivityResult(),onStart(),onResume() )中commit的时候,事情就可能变得棘手了。比如,你不应该在FragmentActivity#onResume() 方法中commit transation,为了避免有些时候这个方法在Activity的状态恢复之前被调用( 查看文档,了解更多)。如果你的应用程序需要在处理onCreate()之外的生命周期方法中commit transation,在FragmentActivity#onResume() 或者Activity#onPostResume()中调用。这两个方法会被保证在Activity恢复它的状态之后调用,因此会避免可能的状态丢失。(一个关于如何去做的例子,可以查看我在StackOverFlow上的回答。这个回答设计怎么正确地响应Activity#onActivityResult()方法,然后commit FragmentTransactions)
避免是异步调用方法中执行transactions 。这个包括经常被使用的方法比如AsyncTask#onPostExecute() 和LoaderManager.LoaderCallbacks#onLoadFinished() 。在这些方法中执行transactions会有问题,因为他们当这些方法被回调的时候,他们不知道Activity当前的生命周期。比如,考虑下面的事件序列:
- 一个Activity执行一个AsyncTask
- 用户按下Home键,导致这个Activity的onSaveInstanceState()和onStop() 方法被回调。
- AsyncTask完成然后onPostExecute()被调用,而不知道Activity已经处于stopped状态。
- 在onPostExectute()方法中的FragmentTransaction被committed,导致一个异常被抛出。
- 只使用commitAllowingStateLoss()作为最后的解决方案。commit()和commitAllowingStateLoss()唯一的区别是后者在状态丢失的时候不会抛出异常。通常你不会想使用这个方法因为它意味着状态丢失可能发生。更好的解决方案当然是修改你的程序以便commit()被保证在activity的状态被保存前调用,因为这样可能会让用户体验更好。除非状态丢失是不可避免的,否则commitAllowingStateLoss()就不应该被使用。
- Fragment提交transaction导致state loss异常
- Fragment提交transaction导致state loss异常
- Fragment提交transaction导致state loss异常
- Fragment提交transaction导致state loss异常
- Fragment提交transaction导致state loss异常
- Fragment提交transaction导致state loss异常
- Fragment提交transaction导致state loss异常
- Fragment提交transaction导致state loss异常
- Fragment提交transaction导致state loss异常
- Fragment Transaction 和 状态丢失 state loss
- Fragment Transactions & Activity State Loss
- Fragment Transactions & Activity State Loss
- Fragment Transactions & Activity State Loss
- Fragment Transactions & Activity State Loss
- Fragment Transactions & Activity State Loss
- Fragment Transactions & Activity State Loss
- Fragment Transactions & Activity State Loss
- Fragment Transactions & Activity State Loss
- ASP.NET读取目录及文件
- c++重载、覆盖和隐藏
- openwrt中添加自定义驱动模块和APP
- Sqlite查找记录并逐条取出
- 通过WDK获取网卡原生MAC地址和当前MAC地址。
- Fragment提交transaction导致state loss异常
- 社説 20150417 G7外相会合 海洋秩序維持へ連携を強めよ
- 读者写者问题的C++实现(使用boost)
- 教你将word文档如何转成PDF文件
- 三层架构实战篇—系统登录实例
- 常用光照预处理算法总结
- 第25章 DBA使用的客户端程序
- Unable to execute dex: Multiple dex files define 的解决方法
- HDOJ 3948 The Number of Palindromes 回文串自动机