为什么调用navigateUp()后ViewModel无法观测到WorkInfo的ENQUEUED状态

问题原因 #

这个现象本质是异步操作和主线程调度的时序竞态问题，核心原因可以拆解为两点：

• WorkManager的enqueue入队操作是异步非阻塞的：调用该方法后，WorkManager会在子线程完成任务持久化、跨进程注册任务等流程，全部执行完成后才会将任务状态更新为ENQUEUED，并通过LiveData向观察者推送通知，这个过程存在毫秒级的时间差。
• navigateUp是主线程同步执行的操作：调用后会立刻在主线程处理Fragment出栈、页面切换动画、视图销毁等逻辑，整个过程会占用主线程数十到数百毫秒。

二者的执行顺序出现了竞态：当主线程优先处理完navigateUp的全部逻辑时，WorkManager的子线程刚好已经完成了入队，并且已经调度任务进入了RUNNING状态。而WorkInfo对应的LiveData的特性是只会向观察者推送最新的状态，不会补发中间的历史状态，因此你只能收到RUNNING和之后的SUCCEEDED状态，中间的ENQUEUED状态被直接跳过。
当你移除navigateUp调用时，主线程没有额外的耗时操作阻塞，能在任务被调度执行前先收到ENQUEUED的状态通知，因此三个状态都能正常打印。

潜在并发风险 #

这个问题本身就是典型的并发竞态问题，除了观测不到ENQUEUED状态外，还可能存在其他隐患：

• 如果你的业务逻辑依赖ENQUEUED状态做UI更新，会出现更新逻辑不执行的问题
• 极端情况下如果navigateUp的逻辑触发了Activity的销毁（比如当前Fragment是Activity回退栈的最后一个Fragment），绑定在Activity上的观察者会被自动移除，可能连后续的RUNNING、SUCCEEDED状态都收不到

修复方案 #

如果需要保证能观测到ENQUEUED状态，可以调整执行时序，等待入队确认后再做页面跳转：

override fun onActivityResult(requestCode: Int, resultCode: Int, intent: Intent?) {
    // 修改createOneTimeRequest返回WorkManager.enqueue()返回的Operation对象
    val enqueueOperation = myViewModel.createOneTimeRequest(intent)
    // 入队完成回调执行后再跳转页面
    enqueueOperation.addListener({
        findNavController().navigateUp()
    }, ContextCompat.getMainExecutor(requireContext()))
}

内容的提问来源于stack exchange，提问作者alpharoz