正如在其他回答中提到的，此异常通常发生在用户

同时单击处理导航的多个视图 在处理导航的视图上多次单击。

使用计时器来禁用单击并不是处理此问题的合适方法。如果用户在计时器过期后还没有导航到目的地，应用程序无论如何都会崩溃，在许多情况下，导航不是执行的动作，快速点击是必要的。

在情况1中，android:splitMotionEvents=“false”在xml或setMotionEventSplittingEnabled(false)在源文件应该有帮助。将此属性设置为false将只允许一个视图进行单击。你可以在这里阅读

在情况2中，会有一些东西延迟导航过程，允许用户多次单击视图(API调用，动画等)。如果可能的话，应该解决根本问题，以便即时进行导航，不允许用户两次单击视图。如果延迟是不可避免的，就像在API调用的情况下，禁用视图或使其不可点击将是适当的解决方案。

在我的案例中，错误发生是因为我在启动画面后启用了带有Single Top和Clear Task选项的导航操作。

如果你使用的是recyclerview，只需在你的点击上添加一个点击监听器冷却时间，并在你的recyclerview xml文件中使用android:splitMotionEvents="false"

看来你在完成任务。应用程序可能有一次性设置或一系列登录屏幕。这些有条件的屏幕不应该被认为是应用程序的起始目的地。

https://developer.android.com/topic/libraries/architecture/navigation/navigation-conditional

似乎混合fragmentManager控件的backstack和Navigation Architecture控件的backstack也会导致这个问题。

例如，最初的CameraX基本示例使用fragmentManager后台导航，如下所示，它似乎没有正确地与导航交互:

// Handle back button press
        view.findViewById<ImageButton>(R.id.back_button).setOnClickListener {
            fragmentManager?.popBackStack()
        }

如果你在从主片段(在本例中是相机片段)移动之前记录这个版本的“当前目的地”，然后当你返回主片段时再次记录它，你可以从日志中的id中看到id是不相同的。据猜测，导航在移动到片段时更新了它，而fragmntManager在移动回来时没有再次更新它。日志显示:

修改前:D/CameraXBasic: currentDest?: androidx.navigation.fragment.FragmentNavigator Destination@b713195美元 After: D/CameraXBasic: currentDest?: androidx.navigation.fragment.FragmentNavigator Destination@9807d8f美元

更新版的CameraX基本示例使用导航返回如下:

 // Handle back button press
        view.findViewById<ImageButton>(R.id.back_button).setOnClickListener {
            Navigation.findNavController(requireActivity(), R.id.fragment_container).navigateUp()
        }

这可以正常工作，当返回到主片段时，日志显示相同的id。

修改前:D/CameraXBasic: currentDest?: androidx.navigation.fragment.FragmentNavigator Destination@b713195美元 After: D/CameraXBasic: currentDest?: androidx.navigation.fragment.FragmentNavigator Destination@b713195美元

我怀疑这个故事的寓意，至少在这个时候，是要非常小心地混合导航和fragmentManager导航。

I caught this exception after some renames of classes. For example: I had classes called FragmentA with @+is/fragment_a in navigation graph and FragmentB with @+id/fragment_b. Then I deleted FragmentA and renamed FragmentB to FragmentA. So after that node of FragmentA still stayed in navigation graph, and android:name of FragmentB's node was renamed path.to.FragmentA. I had two nodes with the same android:name and different android:id, and the action I needed were defined on node of removed class.