DialogFragment配置变更后丢状态 dismiss报错未关联FragmentManager

• 承载用户列表的DialogFragment处于显示状态时，触发切换系统语言、开关深色模式等配置变更操作，DialogFragment会自动关闭且丢失状态数据。
• 配置变更后触发onPositiveClick事件调用checkableContactsDialog?.dismiss()时，抛出IllegalStateException: Fragment not associated with a fragment manager异常。

Dialog创建代码 #

CheckableContactsDialog.newInstance(object : CheckableContactListener {
    override fun onPositiveClick(selected: MutableList<String>) {
         checkableContactsDialog?.dismiss()
        if (mVCall != null) {
            val (phones, phoneFlat) = extractPhonesNumberFromContacts(
                context, selected
            )
            if (phones.isEmpty()) {
                return
            }
            inviteNewUsers(phoneFlat)
        }
    }

    override fun onNegativeClick() {
        checkableContactsDialog?.dismiss()
    }
})

异常堆栈 #

E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.zetabox.totrapp, PID: 4368
java.lang.IllegalStateException: Fragment CheckableContactsDialog{58e7d9c} (77fb6c1e-6986-4eb0-8e35-c1ee51f4e0c9) not associated with a fragment manager.
at androidx.fragment.app.Fragment.getParentFragmentManager(Fragment.java:1040)
at androidx.fragment.app.DialogFragment.dismissInternal(DialogFragment.java:350)
at androidx.fragment.app.DialogFragment.dismiss(DialogFragment.java:307)
at com.google.android.material.bottomsheet.BottomSheetDialogFragment.dismiss(BottomSheetDialogFragment.java:47)
at com.zetabox.totrapp.ui.call.CallActivity$showAddUserDialog$1.onPositiveClick(CallActivity.kt:2123)
at com.zetabox.totrapp.ui.dialogs.CheckableContactsDialog.init$lambda-7(CheckableContactsDialog.kt:231)
at com.zetabox.totrapp.ui.dialogs.CheckableContactsDialog.$r8$lambda$BXYvl1NNrhMJYwo5PbYyZJ1LQtM(Unknown Source:0)
at com.zetabox.totrapp.ui.dialogs.CheckableContactsDialog$$ExternalSyntheticLambda0.onClick(Unknown Source:2)
at android.view.View.performClick(View.java:7171)
at android.view.View.performClickInternal(View.java:7148)
at android.view.View.access$3500(View.java:802)
at android.view.View$PerformClick.run(View.java:27409)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:214)
at android.app.ActivityThread.main(ActivityThread.java:7650)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:503)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)

• Android触发配置变更（语言切换、深色模式切换、屏幕旋转等）时，默认会销毁重建当前宿主Activity及其挂载的所有Fragment，旧Fragment实例会和FragmentManager解除关联，生命周期终止。
• 代码中持有的checkableContactsDialog是配置变更前创建的旧实例引用，配置变更后该实例已经脱离FragmentManager管理，此时调用其dismiss()方法，内部会尝试访问已经不存在的FragmentManager，直接抛出异常。
• 传入Dialog的匿名CheckableContactListener是在旧Activity中创建的，隐式持有旧Dialog实例的引用，配置变更后该监听器没有和重建后的新Dialog实例绑定，点击事件触发时操作的是已经失效的旧实例。
• Dialog状态丢失的核心原因是状态没有做持久化处理：选中的联系人数据存在Dialog的临时变量中，配置变更重建新Dialog实例时，没有任何渠道恢复之前的状态，表现为Dialog自动关闭、数据消失。

1. 解决dismiss崩溃问题 #

• 调用dismiss前增加状态校验，仅当DialogFragment当前已挂载到FragmentManager时才执行关闭逻辑：

override fun onPositiveClick(selected: MutableList<String>) {
    // 增加isAdded校验，避免操作已脱离生命周期的旧实例
    if (checkableContactsDialog?.isAdded == true) {
        checkableContactsDialog?.dismiss()
    }
    if (mVCall != null) {
        val (phones, phoneFlat) = extractPhonesNumberFromContacts(context, selected)
        if (phones.isEmpty()) {
            return
        }
        inviteNewUsers(phoneFlat)
    }
}

override fun onNegativeClick() {
    if (checkableContactsDialog?.isAdded == true) {
        checkableContactsDialog?.dismiss()
    }
}

• 长期优化建议：移除对DialogFragment实例的外部硬持有，改用Fragment Result API或者共享ViewModel实现Dialog和宿主的通信，从根源避免持有失效Fragment实例的问题。

2. 解决配置变更后Dialog状态丢失、异常关闭问题 #

• 不要在Activity的onStop、onDestroy等生命周期回调中主动调用Dialog的dismiss方法，系统在配置变更时会自动恢复已添加的DialogFragment实例，主动dismiss会导致Dialog无法恢复。
• Dialog初始化参数必须通过argumentsBundle传入，不要通过构造函数、setter方法直接赋值，否则重建时参数会丢失。
• Dialog内部的选中联系人状态，重写onSaveInstanceState方法存入Bundle，在onCreateView/onCreateDialog中从Bundle读取恢复，保证重建后选中状态不丢失。
• 如果业务场景允许，也可以在Activity的AndroidManifest.xml配置中增加configChanges属性，声明自行处理的配置变更（比如uiMode|locale），避免配置变更时Activity重建，该方案属于兜底方案，优先推荐通过状态保存实现兼容。

内容的提问来源于stack exchange，提问作者Aymen Ben Salah