关于WorkManager一次性Worker代码更新后已调度重试任务执行行为的技术问询

针对你描述的场景，咱们可以分两部分拆解实际发生的情况，和你列出的三个选项都不完全匹配，但能对应到核心行为：

• 正在运行的Worker实例：当用户更新应用时，系统会强制终止旧版本应用的所有进程，包括正在执行Worker的进程。所以这个正在运行的旧代码Worker会直接被中断，不会继续运行（既不会跑旧代码到结束，也不会切换成新代码）。
• 已调度的重试任务：WorkManager会把未完成的任务（包括已排队的重试请求）持久化在本地数据库中。当新版本应用安装完成后，WorkManager会在触发条件满足时重新调度这些任务——这时候执行的会是更新后的新Worker代码，因为系统会加载新版本APK里的Worker类实现。

不过这里有个需要注意的细节：如果你的Worker更新涉及到输入数据（WorkerParameters）结构的重大变更，或者Worker的构造函数签名改变，可能会导致重新调度的任务执行失败，这时候WorkManager会按照你设置的重试策略处理（如果有的话），或者标记任务失败。

回到你列出的三个选项逐一对应：

1. 运行旧的Worker代码：只有在更新时Worker没被进程终止的极端情况下才会发生，但App更新时进程一定会被杀死，所以这个情况几乎不可能出现。
2. 继续运行但使用新的Worker代码：正在运行的Worker不会"继续"切换代码，但排队的重试任务会用新代码执行，这个选项部分符合重试任务的行为。
3. 因检测到Worker代码变更而取消当前任务：正在运行的Worker是被进程终止而非主动取消，重试任务不会被取消，而是会用新代码重新执行，所以这个选项不符合实际行为。

总结一下：更新后，正在运行的Worker会被中断，已调度的重试任务会用新代码重新执行，不会被直接取消。

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