一、问题
先来看两个Crash Log:
1.
java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState
at android.support.v4.app.ab.v(FragmentManager.java:1377)
at android.support.v4.app.ab.a(FragmentManager.java:1395)
at android.support.v4.app.h.a(BackStackRecord.java:637)
at android.support.v4.app.h.b(BackStackRecord.java:616)
at android.support.v4.app.DialogFragment.show(DialogFragment.java:139)
at com.sankuai.common.views.ai.a(MaoyanDialogBuilder.java:184)
at com.sankuai.movie.y.handleMessage(MovieMainActivity.java:750)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4424)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
at dalvik.system.NativeStart.main(Native Method)
2.
java.lang.IllegalStateException: Can not perform this action inside of onLoadFinished
at android.support.v4.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1381)
at android.support.v4.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:1395)
at android.support.v4.app.BackStackRecord.commitInternal(BackStackRecord.java:637)
at android.support.v4.app.BackStackRecord.commit(BackStackRecord.java:616)
at android.support.v4.app.DialogFragment.show(DialogFragment.java:139)
at com.sankuai.common.views.MaoyanDialogBuilder.show(MaoyanDialogBuilder.java:185)
at com.sankuai.movie.MovieMainActivity$8$1$1.onLoadFinished(MovieMainActivity.java:609)
at com.sankuai.movie.MovieMainActivity$8$1$1.onLoadFinished(MovieMainActivity.java:590)
at android.support.v4.app.LoaderManagerImpl$LoaderInfo.callOnLoadFinished(LoaderManager.java:427)
at android.support.v4.app.LoaderManagerImpl$LoaderInfo.onLoadComplete(LoaderManager.java:395)
at android.support.v4.content.Loader.deliverResult(Loader.java:104)
二、原因
经过查找,发现这两个Crash处于由同一个方法触发:
FragmentManagerImpl#checkStateLoss():
private void checkStateLoss() {
if (mStateSaved) {
throw new IllegalStateException(
"Can not perform this action after onSaveInstanceState");
}
if (mNoTransactionsBecause != null) {
throw new IllegalStateException(
"Can not perform this action inside of " + mNoTransactionsBecause);
}
}
这个方法中的每一个异常分别对应了上述的两段Crash Log。下面逐一分析。
三、分析
第一部分:mStateSaved:
关于这个问题,可以参考这篇文章,Fragment Transactions & Activity State Loss。
从代码中可以看出,若这个字段为true,则会抛出异常。检查代码中与这个字段相关的内容,如下:
Parcelable saveAllState() {
// Make sure all pending operations have now been executed to get
// our state update-to-date.
execPendingActions();
if (HONEYCOMB) {
// As of Honeycomb, we save state after pausing. Prior to that
// it is before pausing. With fragments this is an issue, since
// there are many things you may do after pausing but before
// stopping that change the fragment state. For those older
// devices, we will not at this point say that we have saved
// the state, so we will allow them to continue doing fragment
// transactions. This retains the same semantics as Honeycomb,
// though you do have the risk of losing the very most recent state
// if the process is killed... we'll live with that.
mStateSaved = true;
}
...
}
public void noteStateNotSaved() {
mStateSaved = false;
}
public void dispatchCreate() {
mStateSaved = false;
moveToState(Fragment.CREATED, false);
}
public void dispatchActivityCreated() {
mStateSaved = false;
moveToState(Fragment.ACTIVITY_CREATED, false);
}
public void dispatchStart() {
mStateSaved = false;
moveToState(Fragment.STARTED, false);
}
public void dispatchResume() {
mStateSaved = false;
moveToState(Fragment.RESUMED, false);
}
public void dispatchPause() {
moveToState(Fragment.STARTED, false);
}
public void dispatchStop() {
// See saveAllState() for the explanation of this. We do this for
// all platform versions, to keep our behavior more consistent between
// them.
mStateSaved = true;
moveToState(Fragment.STOPPED, false);
}
可以看到,这个字段的使用与生命周期有关,随便找一个生命周期的传递方法去查看使用:
会有三处使用到,分别研究
1)Fragment#getChildFragmentManager
/**
* Return a private FragmentManager for placing and managing Fragments
* inside of this Fragment.
*/
final public FragmentManager getChildFragmentManager() {
if (mChildFragmentManager == null) {
instantiateChildFragmentManager();
if (mState >= RESUMED) {
mChildFragmentManager.dispatchResume();
} else if (mState >= STARTED) {
mChildFragmentManager.dispatchStart();
} else if (mState >= ACTIVITY_CREATED) {
mChildFragmentManager.dispatchActivityCreated();
} else if (mState >= CREATED) {
mChildFragmentManager.dispatchCreate();
}
}
return mChildFragmentManager;
}
这是在Fragment中获取嵌套使用Fragment,获取childFragmentManager时调用,即告知childFragmentManager父Fragment当前的生命周期。此时也会执行childFragmentManager的初始化。
2)Fragment#performStart
void performStart() {
if (mChildFragmentManager != null) {
mChildFragmentManager.noteStateNotSaved();
mChildFragmentManager.execPendingActions();
}
mCalled = false;
onStart();
if (!mCalled) {
throw new SuperNotCalledException("Fragment " + this
+ " did not call through to super.onStart()");
}
if (mChildFragmentManager != null) {
mChildFragmentManager.dispatchStart();
}
if (mLoaderManager != null) {
mLoaderManager.doReportStart();
}
}
这是在Fragmen在自己的生命周期变化过程中,通知子Fragment。
3)FragmentActivity#onStart
/**
* Dispatch onStart() to all fragments. Ensure any created loaders are
* now started.
*/
@Override
protected void onStart() {
super.onStart();
mStopped = false;
mReallyStopped = false;
mHandler.removeMessages(MSG_REALLY_STOPPED);
if (!mCreated) {
mCreated = true;
mFragments.dispatchActivityCreated();
}
mFragments.noteStateNotSaved();
mFragments.execPendingActions();
if (!mLoadersStarted) {
mLoadersStarted = true;
if (mLoaderManager != null) {
mLoaderManager.doStart();
} else if (!mCheckedForLoaderManager) {
mLoaderManager = getLoaderManager("(root)", mLoadersStarted, false);
// the returned loader manager may be a new one, so we have to start it
if ((mLoaderManager != null) && (!mLoaderManager.mStarted)) {
mLoaderManager.doStart();
}
}
mCheckedForLoaderManager = true;
}
// NOTE: HC onStart goes here.
mFragments.dispatchStart();
if (mAllLoaderManagers != null) {
final int N = mAllLoaderManagers.size();
LoaderManagerImpl loaders[] = new LoaderManagerImpl[N];
for (int i=N-1; i>=0; i--) {
loaders[i] = mAllLoaderManagers.valueAt(i);
}
for (int i=0; i
这是Activity在生命周期发生变化时,通知Fragment。
现在了解了这个行为是和整个Activity、Fragment的生命周期有关的,回过头再来看mStateSaved,这个字段是在onPause或者onStop之后就被置为true。在Android中,由于对运行时的生命周期应用能做的实在是很少,用户可以随时切换Activity,系统也可以随时回收处于后台的Activity内存,所以Android为了保证在再次返回Activity时让它看起来同离开时相似,会使用onSaveInstanceState()来保存一些状态。若在onSaveInstanceState()被调用之后调用FragmentTransaction#commit(),那么这个Fragment的状态就不会被保存,在之后恢复时也不会恢复这个Fragment,使得恢复时UI发生一些变化。
那为什么是onPause或者onStop之后被置为true?这和Android的版本发展有关,在HoneyComb之前,Activity被设计成在onPause之前不会被杀掉,所以onSaveInstanceState()是紧挨着onPause()之前调用的,但是在HoneyComb之后,Activity被设计成只有在onStop()之后才会被杀死,所以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()
由于这个原因,若是在旧机型的onPause()之后调用FragmentTransaction#commit(),这个状态就可能会丢失。这是由于Android开发者为了避免过多的异常而做出的让步,允许在onPause()和onStop()之间偶尔丢失commit()状态。
pre-Honeycomb
post-Honeycomb
commit() before onPause() OK OK
commit() between onPause() and onStop() STATE LOSS OK
commit() after onStop() EXCEPTION
EXCEPTION
应当注意的是,不仅仅是Activity的生命周期会影响,若使用的是嵌套在Fragment中的子Fragment,由上述代码可知,也会有类似情况。
第二部分:mNoTransactionsBecause
再看一下FragmentManagerImpl#checkStateLoss()方法,
private void checkStateLoss() {
if (mStateSaved) {
throw new IllegalStateException(
"Can not perform this action after onSaveInstanceState");
}
if (mNoTransactionsBecause != null) {
throw new IllegalStateException(
"Can not perform this action inside of " + mNoTransactionsBecause);
}
}
还有一个和StateLoss相关的字段是mNoTransactionsBecause,若这个字段不为空,则抛出异常。先查看这个字段在哪里使用,或者说,在什么情况下这个字段会不为空。
可以看到调用的地方主要是两个类,FragmentManager 和 LoaderManager,在FragmentManager中的使用都是用于抛出异常的,并不在意这个,而是在意何时不为空的,在LoaderManager中主要两个地方为这个字段赋值:
1)destory
void destroy() {
if (DEBUG) Log.v(TAG, " Destroying: " + this);
mDestroyed = true;
boolean needReset = mDeliveredData;
mDeliveredData = false;
if (mCallbacks != null && mLoader != null && mHaveData && needReset) {
if (DEBUG) Log.v(TAG, " Reseting: " + this);
String lastBecause = null;
if (mActivity != null) {
lastBecause = mActivity.mFragments.mNoTransactionsBecause;
mActivity.mFragments.mNoTransactionsBecause = "onLoaderReset";
}
try {
mCallbacks.onLoaderReset(mLoader);
} finally {
if (mActivity != null) {
mActivity.mFragments.mNoTransactionsBecause = lastBecause;
}
}
}
mCallbacks = null;
mData = null;
mHaveData = false;
if (mLoader != null) {
if (mListenerRegistered) {
mListenerRegistered = false;
mLoader.unregisterListener(this);
}
mLoader.reset();
}
if (mPendingLoader != null) {
mPendingLoader.destroy();
}
}
2)callOnLoadFinished
void callOnLoadFinished(Loader
在这两个地方的考量,也是由于loader的异步可能导致fragment在onSaveInstanceState()之后调用导致状态丢失。
四、解决方案
那么如何解决这个问题?
1)在LoaderManager.LoaderCallbacks#onLoadFinished 或者 LoaderManager.LoaderCallbacks#onLoaderReset中使用
这里直接使用commit()方法会直接抛出异常,需要加Handler避免在这两个回调函数中直接使用commit()方法
2)在使用FragmentTransaction#commit()方法时注意当前的生命周期。
一般而言,会在onCreate()或者响应用户的操作事件时才会使用commit()方法,这不会有问题,但假若在别的生命周期中使用就要小心了。例如onActivityResult(), onStart(), 和 onResume(),就需要注意。例如,在onResume()中使用,但onResume()并不会保证在Activity状态恢复之后调用,此时需要使用FragmentActivity#onResumeFragments()或者Activity#onPostResume()中调用,这两个会保证在状态恢复之后调用。
3)避免异步回调中使用commit()方法
异步回调,如AsyncTask#onPostExecute() 和 LoaderManager.LoaderCallbacks#onLoadFinished(),之后无法保证当前的生命状态,而且异步通常会执行一些比较耗时的操作,更容易使得这样的丢失发生,如用户发出一个请求之后点了HOME键。
4)使用 commitAllowingStateLoss()方法
这个方法会跳过mStateSaved的检查,也不会在意会发生怎样的影响,就算无法执行或Activity状态恢复之后发生了UI变动也不会有警报。
5)针对DialogFragment的解决方案
由于DialogFragment和其它Fragment相比比较特殊,创建、回收更频繁也更不容易控制。
方法一:
对于DialogFragment而言,只有show()方法而没有showAllowingStateLoss()方法。。。而且很多时候都需要在网络请求返回之后根据返回的字段来显示,所以最好在base中添加对Activity和Fragment的生命周期追踪方法。但自己添加的方法和原生的毕竟在执行时间上还是有一点时间差的,不能够100%避免crash。
方法二:
或许有想法说可以重写DialogFragment#show()方法,让它支持commitAllowingStateLoss(),好吧,来看下源码。。。这是show方法:
/**
* Display the dialog, adding the fragment to the given FragmentManager. This
* is a convenience for explicitly creating a transaction, adding the
* fragment to it with the given tag, and committing it. This does
* not add the transaction to the back stack. When the fragment
* is dismissed, a new transaction will be executed to remove it from
* the activity.
* @param manager The FragmentManager this fragment will be added to.
* @param tag The tag for this fragment, as per
* {@link FragmentTransaction#add(Fragment, String) FragmentTransaction.add}.
*/
public void show(FragmentManager manager, String tag) {
mDismissed = false;
mShownByMe = true;
FragmentTransaction ft = manager.beginTransaction();
ft.add(this, tag);
ft.commit();
}
/**
* Display the dialog, adding the fragment using an existing transaction
* and then committing the transaction.
* @param transaction An existing transaction in which to add the fragment.
* @param tag The tag for this fragment, as per
* {@link FragmentTransaction#add(Fragment, String) FragmentTransaction.add}.
* @return Returns the identifier of the committed transaction, as per
* {@link FragmentTransaction#commit() FragmentTransaction.commit()}.
*/
public int show(FragmentTransaction transaction, String tag) {
mDismissed = false;
mShownByMe = true;
transaction.add(this, tag);
mViewDestroyed = false;
mBackStackId = transaction.commit();
return mBackStackId;
}
可以看到,和普通的Fragment显示方法区别并不大,其实DialogFragment只是一个Fragment里面套了个Dialog而已。但,有个很神奇的字段,mShownByMe,这个字段是做什么的?定义处和这里并没有注释,通过查找这个字段的使用,发现了这两个方法:
@Override
public void onAttach(Activity activity) {
super.onAttach(activity);
if (!mShownByMe) {
// If not explicitly shown through our API, take this as an
// indication that the dialog is no longer dismissed.
mDismissed = false;
}
}
@Override
public void onDetach() {
super.onDetach();
if (!mShownByMe && !mDismissed) {
// The fragment was not shown by a direct call here, it is not
// dismissed, and now it is being detached... well, okay, thou
// art now dismissed. Have fun.
mDismissed = true;
}
}
通过这里可以发现,这个字段是判断DialogFragment是不是通过原生API的show()方法来显示的。。否则就不在onAttach()和onDetach()里设置mDismissed字段的,再看onDetach里的注释,为什么有种深深恶意。。(我辛辛苦苦写好了API,你为什么不用?你为什么不用?你为什么不用?(╯‵□′)╯︵┻━┻)
重写show()也是可以的,但需要紧接着重写onAttach()、onDetach()等方法。
若有需要重写show(FragmentTransaction transaction, String tag)方法,除了mShownByMe字段还需要注意mViewDestroyed字段的值设置。
其实对于重写show()方法的弊端主要在于无法保证show()的执行,从而导致isShowing()等方法的判断不准确,引起一些其他的问题。
方法三:
弃用DialogFragment。这种方法可以避免如此繁复的生命周期,代码和使用简洁不少,但也少了 DialogFragment 的优势,例如不能在切换屏幕时保留 Dialog 等。
方法一的优势在于并不需要对DialogFragment的内部实现做详尽的了解,也避免了开发者的恶意,但在onPause()之后,onSaveInstanceState()之前的dialog都不会展示出来。
方法二的优势在于API使用者并不需要在调用API的同时还为它的上下文环境担惊受怕,但重写难度较大,而且会有状态丢失的情况。
方法三也不是不可,只是有些问题只适用 DialogFragment 解决,手动实现会有很多变数。
自行斟酌使用。