崩潰堆棧信息

Caused by: java.lang.IllegalStateException:Can not perform this action after onSaveInstanceState
at android.support.v4.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:2080)
at android.support.v4.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:2106)
at android.support.v4.app.BackStackRecord.commitInternal(BackStackRecord.java:683)
at android.support.v4.app.BackStackRecord.commit(BackStackRecord.java:637)
at android.support.v4.app.DialogFragment.dismissInternal(DialogFragment.java:224)
at android.support.v4.app.DialogFragment.dismiss(DialogFragment.java:191)
at com.xxx.BaseActivity.dismissLoading(BaseActivity.java:170)

可以看到是在 onSaveInstanceState 之后操作了 DialogFragment。
那么什么場(chǎng)景下會(huì)觸發(fā) onSaveInstanceState 呢？

觸發(fā) onSaveInstanceState 的場(chǎng)景

用戶主動(dòng)銷毀 Activity 時(shí)，不會(huì)觸發(fā) onSaveInstanceState。有可能被動(dòng)銷毀 Activity 時(shí)，才會(huì)觸發(fā) onSaveInstanceState 來(lái)保存一些信息，等下次打開(kāi)這個(gè) Activity 時(shí)恢復(fù)這些信息。什么是被動(dòng)銷毀呢？比如說(shuō)用戶按了 HOME 鍵，去打開(kāi)其他的 App 了，那么 Activity 隨時(shí)可能被系統(tǒng)殺死，被系統(tǒng)殺死就叫做被動(dòng)銷毀。

觸發(fā) onSaveInstanceState 的場(chǎng)景有以下幾種：

1. 用戶按了 HOME 鍵
2. 用戶調(diào)出任務(wù)管理
3. 屏幕熄掉
4. 橫豎屏切換

從源碼角度分析為什么 DialogFragment 的 show 和 dismiss 不能在 onSaveInstanceState 之后

首先看下 DialogFragment 的 show 方法

public void show(FragmentManager manager, String tag) {
    this.mDismissed = false;
    this.mShownByMe = true;
    FragmentTransaction ft = manager.beginTransaction();
    ft.add(this, tag);
    ft.commit();
}

FragmentManager 是調(diào)用 show 方法時(shí)傳進(jìn)來(lái)的 getSupportFragmentManager()，getSupportFragmentManager 返回的是 FragmentManagerImpl，F(xiàn)ragmentManagerImpl 的 beginTransaction 返回的是 BackStackRecord。

也就是說(shuō)最后是調(diào)用 BackStackRecord 的 commit 方法。

我們來(lái)看一下 commit 方法的源代碼。

public int commit() {
    return this.commitInternal(false);
}

int commitInternal(boolean allowStateLoss) {
    if (this.mCommitted) {
        throw new IllegalStateException("commit already called");
    } else {
        // 此處省略不相干代碼
        this.mManager.enqueueAction(this, allowStateLoss);
        return this.mIndex;
    }
}

接著調(diào)用 FragmentManagerImpl 的 enqueueAction 方法

    public void enqueueAction(FragmentManagerImpl.OpGenerator action, boolean allowStateLoss) {
        if (!allowStateLoss) {
            this.checkStateLoss();
        }

        synchronized(this) {
            if (!this.mDestroyed && this.mHost != null) {
                if (this.mPendingActions == null) {
                    this.mPendingActions = new ArrayList();
                }

                this.mPendingActions.add(action);
                this.scheduleCommit();
            } else if (!allowStateLoss) {
                throw new IllegalStateException("Activity has been destroyed");
            }
        }
    }

可以看到，如果 allowStateLoss 為 false 的話，就需要 checkStateLoss 了。前面 commit 方法里面?zhèn)鬟M(jìn)來(lái)的正是 false。

再來(lái)看看 checkStateLoss 方法。

private void checkStateLoss() {
    if (this.isStateSaved()) {
        throw new IllegalStateException("Can not perform this action after onSaveInstanceState");
    } else if (this.mNoTransactionsBecause != null) {
        throw new IllegalStateException("Can not perform this action inside of " + this.mNoTransactionsBecause);
    }
}

public boolean isStateSaved() {
    return this.mStateSaved || this.mStopped;
}

可以看出如果 mStateSaved 是 true 的話，就會(huì)拋出文章開(kāi)頭提到的異常。
那么 mStateSaved 是不是 onSaveInstanceState 之后就變成 true 了呢？

我么接著看 onSaveInstanceState 的源代碼

protected void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);
    this.markFragmentsCreated();
    Parcelable p = this.mFragments.saveAllState();
    // 省略不相干代碼
}

public Parcelable saveAllState() {
    return this.mHost.mFragmentManager.saveAllState();
}

Parcelable saveAllState() {
    // 省略不相干代碼
    this.mStateSaved = true;
    // 省略不相干代碼
}

可以看到 onSaveInstanceState 被調(diào)用之后，mStateSaved 就變成了 true。

致此，整個(gè)過(guò)程就明朗了，只要 onSaveInstanceState 被調(diào)用之后，再調(diào)用 DialogFragment 的 show 方法，就會(huì)拋出異常。
※ 注意：onSaveInstanceState 的生命周期在 onPause 或者 onStop 之后，不是固定的。

我們分析了 show 方法的源碼，同理，dismiss 也可以照葫蘆畫(huà)瓢，這邊就不再描述了。

如何避免呢？

其實(shí)從源碼可以看出，如果 allowStateLoss 為 true 的話，就不會(huì)拋出異常了。

除了 commit 方法，還有一個(gè) commitAllowingStateLoss 方法，傳的 allowStateLoss 正是 true。

But。。。我們只可以調(diào)用 show 方法，show 方法只能調(diào)用 commit，沒(méi)有機(jī)會(huì)去調(diào)用 commit 方法。
show 方法不可以，dismiss 倒是可以直接調(diào)用 dismissAllowingStateLoss。

不懂 Google 為什么只設(shè)計(jì)了 dismissAllowingStateLoss 而沒(méi)有設(shè)計(jì) showAllowingStateLoss。

如果要讓 show 方法也達(dá)到同樣的效果，可以在自定義的 DialogFragment 中覆寫(xiě) show 方法，然后把 commit 修改為 commitAllowingStateLoss，但是發(fā)現(xiàn) mDismissed 和 mShownByMe 這兩個(gè)變量的修飾符是 default，不是同一個(gè) package，是訪問(wèn)不了的，可以在自己項(xiàng)目中新建和 android.support.v4.app 同樣的 package 就可以了。

還有一種方法就是 try catch。這種方法雖然可以避免拋出異常，但是對(duì)話框是彈不出來(lái)了。

try {
    mDialogFragment.show(getSupportFragmentManager(), getClass().getName());
} catch (Exception e) {
    // 容錯(cuò)，不做任何處理
}

還有一種辦法，如果操作 DialogFragment 的時(shí)候，onSaveInstanceState 已經(jīng)被調(diào)用過(guò)了，那么先把操作保存起來(lái)，等頁(yè)面顯示的時(shí)候再執(zhí)行。

首先新建一個(gè) PausedAction 的類用來(lái)保存操作。

public class PausedAction {

    private ActionCallback mCallback;

    public void pause(boolean shouldPause, ActionCallback callback) {
        if (shouldPause) {
            this.mCallback = callback;
        } else {
            callback.call();
        }
    }

    public void resume() {
        if (mCallback != null) {
            mCallback.call();
            mCallback = null;
        }
    }

    public interface ActionCallback {
        void call();
    }
}

在操作 DialogFragment 的時(shí)候，根據(jù) mStateSaved 的值，判斷直接執(zhí)行還是先保存起來(lái)

mPausedAction.pause(getSupportFragmentManager().isStateSaved(), 
    () -> mDialogFragment.show(getSupportFragmentManager(), getClass().getName()));

然后在頁(yè)面可見(jiàn)的時(shí)候再執(zhí)行

@Override
public void onResume() {
    super.onResume();
    mPausedAction.resume();
}