onBackPressed()已废弃，如何优雅处理返回/onStop等逻辑？

谷歌正在引入预测返回手势（即提前返回回调）支持，onBackPressed()已被废弃。现有讨论多聚焦于“确认离开”弹窗的处理，但本文关注另一场景：我们需要在名为「Screen X」的页面，利用返回操作清除可能已修改数据的缓存。

思路一 #

理论上可在onStop中执行缓存清理，但打开Screen Y和Z时该方法也会触发，而这些场景下不能清除缓存；不过用户在Screen X关闭应用时触发该方法是可行的。
虽然我们可以控制Screen Y和Z的打开方式，通过缓存标记在onStop中判断，但这种方式冗余且不自然。

思路二（继续使用onBackPressed()） #

直接沿用之前的方式，继续使用onBackPressed()并在其中清除缓存似乎可行：

@Suppress("DEPRECATION")
override fun onBackPressed() {
    viewModel.clearFilterCache()
    super.onBackPressed()
}

这可能是最简单的解决方案，后续读代码的人能立刻明白缓存清除的触发场景。
谷歌希望开发者适配预测返回手势，因此禁止在onBackPressed()中加入阻塞导航的自定义“是否显示弹窗”逻辑，但我的场景中并无此类操作。理想情况下希望仅允许在其中执行业务代码，但无法实现。

总结 #

我认为onBackPressed()方案是最佳选择，但想了解其他开发者如何解决该问题，相信并非我一人遇到此情况。

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