Fragment Transactions & Activity State Loss

Read the Fucking Source Code

上周在Fabric的Crashlytics榜首出现了一个关于Fragment状态引发的崩溃日志：

android.app.FragmentManagerImpl.checkStateLoss (FragmentManager.java:1858)
android.app.FragmentManagerImpl.enqueueAction (FragmentManager.java:1881)
android.app.BackStackRecord.commitInternal (BackStackRecord.java:688)
android.app.BackStackRecord.commit (BackStackRecord.java:646)
android.app.DialogFragment.show (DialogFragment.java:230)

刚开始以为是DialogFragment调用show的时候，没有判断Activity是否已经Finish了。结果发现在项目代码里是做了判断的，看崩溃的人数和次数还是一个非必现的bug，瞬间就感觉事情可能不是那么简单了，只能硬着头皮去RTFSC了....

这次我们反向追踪（就是这么皮）

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);
     }
    }

FragmentManagerImpl. enqueueAction

/**
 * Adds an action to the queue of pending actions.
 *
 * @param action the action to add
 * @param allowStateLoss whether to allow loss of state information
 * @throws IllegalStateException if the activity has been destroyed
 */
public void enqueueAction(OpGenerator action, boolean allowStateLoss) {
    //注意这里的allowStateLoss 它决定了checkStateLoss方法是否进行
    if (!allowStateLoss) {
        checkStateLoss();
    }
    synchronized (this) {
        if (mDestroyed || mHost == null) {
            throw new IllegalStateException("Activity has been destroyed");
        }
        if (mPendingActions == null) {
            mPendingActions = new ArrayList<>();
        }
        mPendingActions.add(action);
        scheduleCommit();
    }
}

BackStackRecord.commitInternal

  int commitInternal(boolean allowStateLoss) {
    if (mCommitted) throw new IllegalStateException("commit already called");
    if (FragmentManagerImpl.DEBUG) {
        Log.v(TAG, "Commit: " + this);
        LogWriter logw = new LogWriter(TAG);
        PrintWriter pw = new PrintWriter(logw);
        dump("  ", null, pw, null);
        pw.close();
    }
    mCommitted = true;
    if (mAddToBackStack) {
        mIndex = mManager.allocBackStackIndex(this);
    } else {
        mIndex = -1;
    }
    //重点
    mManager.enqueueAction(this, allowStateLoss);
    return mIndex;
}

BackStackRecord.commit

public int commit() {
    //这里传入的就是allowStateLoss参数
    return commitInternal(false);
}

DialogFragment.show

public void show(FragmentManager manager, String tag) {
    mDismissed = false;
    mShownByMe = true;
    FragmentTransaction ft = manager.beginTransaction();
    ft.add(this, tag);
    //没想到的时候DialogFragment的show方法会调用commit() 导火索
    ft.commit();
}

目前来看是因为DialogFragment的show方法导致强行检查Fragment的状态，而恰好在检查的时候状态已经被保存导致FragmentManager的标记位mStateSaved = true，那么去查mStateSaved = true的调用时机一切都会水落石出了..

---------------------------------------查找中-------------------------------------------
FragmentManager中mStateSaved = true总共出现了三次，最后确定了其中一条路线是本次崩溃走过的路...
---------------------------------------复现中-------------------------------------------

情景再现

当用户在进入首页模块时直接按Home键或者遇到内存不足等特殊情况下触发了onSaveInstanceState导致FragmentManager进行“智能”保存当前Activity中Fragment的状态，因为DialogFragment(广告弹窗)需要先从服务器拉取数据，所以之后在show的时候去checkStateLoss时触发了异常...

解决方案：

1.将广告弹窗实现改为纯Dialog，不再使用DialogFragment.
2.如果自己的项目里面不需要对Fragment的相关状态进行保存和维护，可以在相关Activity中复写onSaveInstance不进行super回调即可.