Android 15 预测性返回手势，我试了一下

Android 15 预测性返回手势，我试了一下

Android 15 在 2024 年 9 月正式发布，预测性返回手势（Predictive Back Gesture）从开发者选项里的实验性功能变成了系统默认行为。这个特性最早在 Android 13 的 Material 组件里露过面，Android 14 作为可选 API 开放，到了 Android 15 直接强制执行——如果你的应用没有适配，用户从屏幕边缘向内滑动时，系统会提供一个默认的返回预览动画，但这个预览可能跟你的应用实际返回行为完全对不上。

我手头的主力测试机是一台 Pixel 7，OTA 升级到 Android 15（AP3A.241005.015）之后，第一件事就是把几个自己维护的项目跑了一遍。预测性返回的适配比官方文档里写的 "只需在 AndroidManifest.xml 里加一行 android:enableOnBackInvokedCallback=true" 要复杂得多，这篇文章记录我实际踩到的坑。

系统行为变了：从同步拦截到异步回调

Android 15 之前，返回键的处理是同步的。无论是 Activity 的 onBackPressed()，还是 Fragment 的 OnBackPressedDispatcher，本质上都是在按键事件分发链条里拦截。用户手指碰到屏幕边缘，系统把事件传给你的应用，你的代码决定要不要消费，消费了就阻断，不消费就继续往上冒泡。

预测性返回把这个模型彻底改了。现在系统会在用户手指接触屏幕边缘的瞬间就启动一个手势识别流程，不等你的应用做任何响应，先开始渲染一个返回预览动画。这个预览动画的内容取决于你的应用声明了什么：如果适配了，系统会调用你注册的 OnBackInvokedCallback，给你一次异步回调的机会去准备返回动画；如果没适配，系统就拍一张当前 Activity 的缩略图，做一个向侧边滑出的默认动画。

问题就出在这个"拍缩略图"上。我维护的一个项目里有几个全屏播放视频的 Activity，用的是 ExoPlayer 的 SurfaceView 渲染。Android 15 上从边缘滑动手势触发时，系统拍的缩略图经常是一帧黑屏或者撕裂的画面，因为 SurfaceView 的缓冲区跟普通 View 的合成路径不一样，系统截图工具 captureSurface() 在异步场景下同步读帧的时机很微妙。用户看到的预览动画是一个残缺的视频画面滑出去，体验比 Android 14 之前直接返回还要差。

解决办法是把这些 Activity 的窗口属性调整，强制让系统走软件渲染路径截图，或者干脆升级到 TextureView。但这不是重点，重点是预测性返回的"系统默认预览"在很多场景下并不优雅，Android 15 把它变成默认行为之后，不适配的应用反而比 Android 14 看起来更破。

适配的第一步：Manifest 声明和 API 级别判断

官方文档说在 AndroidManifest.xml 的 application 或 activity 标签里加 android:enableOnBackInvokedCallback="true" 就行。这个属性确实需要，但它只解决了一半问题。

<<application
    android:enableOnBackInvokedCallback="true"
    ... >

这个属性在 Android 13（API 33）以下的系统上会被直接忽略，不会导致安装失败。但如果你在代码里直接调用 OnBackInvokedDispatcher.registerOnBackInvokedCallback()，在 API 33 以下的设备上会直接崩溃，因为那个类不存在。所以实际代码里必须做版本判断：

if (Build.VERSION.SDK_INT >= 34) {
    onBackInvokedDispatcher.registerOnBackInvokedCallback(
        OnBackInvokedDispatcher.PRIORITY_DEFAULT,
        onBackInvokedCallback
    )
}

注意这里我用的是 API 34（Android 14）而不是 33。虽然 OnBackInvokedDispatcher 在 Android 13 的某些预览版本里出现过，但正式 API 是在 Android 14 才稳定的。Google 官方文档有时候写 API 33，有时候写 API 34，我实际测试下来，Pixel 7 上 Android 13（TQ3A.230805.001）的系统镜像里没有这个类，编译时 targetSdk 34 的话在 33 的设备上运行会直接 NoClassDefFoundError。稳妥起见，我统一判断 Build.VERSION.SDK_INT >= 34。

另一个细节是 PRIORITY_DEFAULT 和 PRIORITY_OVERLAY 的区别。如果你的 Activity 里有 BottomSheet 或者 DialogFragment 这种需要拦截返回键的浮层，PRIORITY 的选择会影响回调顺序。我遇到的一个场景是：主 Activity 注册了 DEFAULT 优先级的回调，里面有一个 BottomSheetBehavior 也试图处理返回键。在 Android 15 上，BottomSheet 的滑动收起和系统的返回手势会冲突，用户从底部向上滑动收起 BottomSheet 时，如果手指轨迹稍微偏左，系统手势识别器会误判为返回手势，直接触发 Activity 级别的返回回调。

这个冲突在 Android 14 之前也存在，但以前返回手势是"触发即执行"，用户没有反悔空间，所以手势识别区域比较保守。Android 15 的预测性返回给了用户一个"预览后取消"的机会，系统手势识别区域似乎放宽了，导致边缘 20dp 左右的滑动都会被捕获。我测量了一下，Pixel 7 上从屏幕左边缘向内滑动大约 18dp 就会触发返回手势预览，而 BottomSheet 的拖拽阈值通常设定在 16dp 左右，两个数值太接近了。

自定义返回动画：Material Motion 的坑

如果只是让系统显示默认的返回预览，适配工作相对简单。但很多设计团队会要求自定义返回动画，比如当前页面缩小、后方页面露出的效果。这时候需要用到 Material 组件库里的 MaterialBackAnimation 或者自己实现 OnBackAnimationCallback。

Material 组件库 1.12.0 开始提供了 PredictiveBackHandheldFragment 和相关的动画辅助类。我尝试在一个新项目里接入：

implementation 'com.google.android.material:material:1.12.0'

然后在 Activity 里注册：

val callback = object : OnBackInvokedDispatcher.OnBackInvokedCallback {
    override fun onBackInvoked() {
        // 默认返回处理
    }
}

if (Build.VERSION.SDK_INT >= 34) {
    val animatedCallback = OnBackAnimationCallback { progress, backEvent ->
        // 进度 0.0 到 1.0
        view.scaleX = 1.0f - progress * 0.1f
        view.scaleY = 1.0f - progress * 0.1f
    }
    onBackInvokedDispatcher.registerOnBackInvokedCallback(
        OnBackInvokedDispatcher.PRIORITY_DEFAULT,
        animatedCallback
    )
}

OnBackAnimationCallback 是 Android 14 新增的接口，比普通的 OnBackInvokedCallback 多了一个 onBackProgressed() 方法，系统会在手势滑动过程中持续回调，progress 参数从 0.0 增长到 1.0。如果用户中途松手取消返回，还会调用 onBackCancelled()。

这个接口设计看起来合理，实际用的时候有几个问题。第一是回调频率，我在 Pixel 7 上打日志测量，一次完整的手势滑动（从触碰到释放）大约收到 40-60 次 onBackProgressed 回调，频率跟屏幕刷新率相关但不完全同步，有时候两帧之间会跳 0.03 的进度，有时候只跳 0.01。如果你的自定义动画依赖于平滑的进度插值，不能直接用 progress 做线性映射，需要自己做一点平滑处理。

第二是 onBackCancelled() 的调用时机。用户手指离开屏幕的瞬间，如果系统判断手势速度不够、不会触发返回，会调用 onBackCancelled()。但这个回调和 onBackProgressed() 的最后一帧之间可能有 1-2 帧的延迟，视觉上会出现动画已经回弹了，但进度值还停留在 0.3 左右的情况。我试着在 onBackCancelled() 里强制把 view 属性重置，但重置动画和系统默认的回弹动画叠加，会产生一个轻微的抖动。

第三是跟 Fragment 返回栈的整合。很多应用用 Navigation Component 管理 Fragment 跳转，返回时弹出返回栈。预测性返回的自定义动画需要跟 NavController 的 popBackStack() 时机配合。我查了一下 Navigation 2.7.0 以上的源码，NavHostFragment 内部已经做了预测性返回的适配，但它是通过 FragmentManager 的 OnBackStackChangedListener 间接实现的，不是直接注册 OnBackAnimationCallback。这意味着如果你想在 Fragment 级别做自定义返回动画，需要和 Navigation 的内部机制抢注册权，或者干脆放弃 Navigation 的默认返回处理。

我实际的做法是：在需要自定义动画的 Fragment 里，先 unregister 掉 Activity 级别注册的回调，再注册自己的 OnBackAnimationCallback，在 onBackInvoked() 里手动调用 findNavController().popBackStack()。这个做法很脏，但没有找到更干净的方案。

跨 Activity 的返回预览：最难搞的部分

单个 Activity 内部的返回动画相对好控制，跨 Activity 的返回预览才是噩梦。

Android 15 的预测性返回支持两种预览模式：in-app 和 cross-activity。in-app 预览显示的是当前应用内部的前一个界面，比如你在一个详情页返回列表页，预览里会显示列表页。cross-activity 预览显示的是系统桌面或者上一个应用，适用于当前 Activity 是任务栈最后一个的情况。

cross-activity 预览默认由系统处理，应用无法自定义。但 in-app 预览需要应用自己提供，通过 overrideActivityTransition() 或者 ActivityOptions 设置。

我在一个有两个 Activity 的项目里测试：Activity A 启动 Activity B，在 B 里做返回手势。期望的预览是 A 的界面从左侧滑入，B 的界面向右滑出。实际配置：

overrideActivityTransition(
    OVERRIDE_TRANSITION_OPEN,
    R.anim.slide_in_right,
    R.anim.slide_out_left
)
overrideActivityTransition(
    OVERRIDE_TRANSITION_CLOSE,
    R.anim.slide_in_left,
    R.anim.slide_out_right
)

这个 API 是 Android 14 引入的，替代了已经被废弃的 overridePendingTransition()。但 overrideActivityTransition() 的文档写得含糊，OVERRIDE_TRANSITION_OPEN 和 OVERRIDE_TRANSITION_CLOSE 到底对应什么场景，我试了好几遍才确认：OPEN 是指当前 Activity 被打开时的动画，CLOSE 是指当前 Activity 被关闭时的动画。所以在 Activity B 里设置 OVERRIDE_TRANSITION_CLOSE，对应的是用户从 B 返回 A 时的预览动画。

坑在于这个动画只在预测性返回的预览阶段播放，真正执行 finish() 的时候，系统还会再播放一次 transition。如果两次动画不一致，用户会看到预览是一个动画，松手后实际返回是另一个动画，割裂感很强。我一开始把 OVERRIDE_TRANSITION_CLOSE 设成了 slide_in_left/slide_out_right，但 Activity 真正 finish 时用的是默认的窗口动画，结果预览里 A 从左边进来，实际返回时 A 是从下面淡入。

解决办法是同时设置窗口动画和 overrideActivityTransition，保持一致：

window.exitTransition = Slide(Gravity.END).apply { duration = 300 }
window.reenterTransition = Slide(Gravity.START).apply { duration = 300 }

然后 overrideActivityTransition 也用对应的 xml 动画。但 Transition API 和 overrideActivityTransition 的时序不完全一致，Slide Transition 的进度由系统控制，overrideActivityTransition 的动画时长如果跟 Transition 不匹配，预览和实际执行之间会有肉眼可见的差异。

更麻烦的是 shared element transition。如果 Activity A 到 B 有一个共享元素图片的过渡动画，返回时理论上应该反向播放。但预测性返回的预览阶段，共享元素的位置信息可能还没准备好，因为 B 里的共享元素可能已经被 RecyclerView 回收或者重用了。我项目里有一个图片浏览场景，从网格列表点进详情，返回时预览里的共享元素图片位置是错的，直接从屏幕中央出现，而不是从详情页的实际位置缩小回去。

这个问题在 Android 15 的 issue tracker 上有记录（issue #331998778），状态是 Assigned，但几个月没有更新。 workaround 是在返回预览开始前强制把共享元素的位置信息 snapshot 下来，但 OnBackAnimationCallback 的 onBackStarted() 回调时机不够早，用户手指已经滑动一段距离后才触发，snapshot 出来的位置有滞后。

性能：手势识别和渲染的额外开销

预测性返回不是纯 UI 层的改动，它引入了系统级的手势识别流程和额外的渲染管线。我在 Pixel 7 上做了一些粗略的测量，数据仅供参考。

用 Android Studio 的 Profiler 抓 GPU 帧时间，同一个列表页面，Android 14 上平均帧时间 8.2ms，Android 15 上 8.7ms。差距不大，但触发返回手势预览时，帧时间会跳到 14-18ms，持续大约 3-4 帧。这个峰值对应的是系统合成器（SurfaceFlinger）在准备返回预览的额外图层。

内存方面，系统需要维护一个返回预览的缓冲层，大约是屏幕分辨率 RGBA 的纹理。Pixel 7 的屏幕是 1080x2400，一个全屏缓冲大约 10MB。如果应用有多个 Activity 同时参与返回预览，系统会保留多个缓冲。我在一个有三层 Activity 嵌套的任务栈里测试，连续触发返回预览但没有真正返回，系统进程的内存增长了约 30MB，在 /proc/system_meminfo 的 SurfaceFlinger 相关项里可以看到。

这些开销对旗舰机影响不大，但中低端设备上可能会更显著。我借了一台小米 13T（天玑 8200，Android 15 的 MIUI 测试版）做对比，同样的场景下返回预览的帧时间峰值能到 25ms，偶尔出现掉帧。Google 在官方文档里提到预测性返回的预览渲染是"尽力而为"（best-effort），系统会根据设备性能动态调整预览质量，但具体调整策略没有公开。

第三方库和旧代码的兼容性

预测性返回的强制化对依赖旧版返回处理机制的库是个打击。

我项目里用了一个第三方的图片裁剪库 uCrop，版本 2.2.8。它的裁剪 Activity 重写了 onBackPressed() 来提示用户"是否放弃编辑"。在 Android 15 上，这个重写不会触发预测性返回的预览问题，因为 onBackPressed() 的调用时机是在用户手势完成、系统已经决定返回之后。但用户体验变了：用户从边缘滑动，先看到系统返回预览（默认是桌面或者前一个 Activity），松手后才弹出 uCrop 的"放弃编辑"对话框。预览告诉用户"你要返回了"，但返回后又拦住他问"确定吗"，逻辑上有点荒谬。

uCrop 2.2.9 之后加了对 OnBackInvokedDispatcher 的适配，但实现方式是在 onBackInvoked() 里直接调用 onBackPressed() 的兼容逻辑，没有真正做预测性返回的动画整合。很多第三方库的适配都是这种"能跑就行"的态度，对于需要精细控制的应用来说，可能需要 fork 出来自己改。

另一个坑是 Flutter 混合工程。Flutter 引擎自己处理返回键，通过 MethodChannel 跟 Android 层通信。Flutter 3.22 开始支持预测性返回，但需要在 Android 工程的 MainActivity 里手动配置 enableOnBackInvokedCallback，然后在 Flutter 的 WillPopScope 或者 PopScope 里处理。我维护的一个混合项目，Android 原生部分已经适配了，但 Flutter 模块里的路由栈和原生 Activity 的返回栈是两套系统，预测性返回的预览只能显示原生层的前一个 Activity，Flutter 内部的页面跳转历史对系统不可见。用户从 Flutter 页面返回，预览里显示的是原生壳的某个页面，而不是 Flutter 里的上一个路由。

这个架构层面的问题没有完美的解决方案。我们目前的做法是在 Flutter 容器 Activity 里禁用预测性返回的自定义预览，让系统走默认截图，至少预览内容和实际返回目标一致（都是退出 Flutter 容器）。

一些未文档化的细节

Android 15 的预测性返回有几个行为在官方文档里没提，或者提得很隐晦。

第一个是手势触发区域。Pixel 7 上，屏幕底部 20% 的区域是系统手势排除区（gesture exclusion zone），从底部边缘向上滑动是 Home 手势，不会触发返回预览。但如果应用用了 Edge-to-Edge 显示，内容延伸到导航栏后面，这个排除区的计算会变化。我测试发现，当应用启用 WindowInsetsCompat.Type.systemGestures() 的边衬区适配后，系统手势识别区域会向内容区扩展大约 8dp，导致一些靠近边缘的按钮更容易被误触为返回手势。

第二个是夜间模式下的预览渲染。系统拍的返回预览缩略图似乎不跟随应用的夜间模式设置，如果应用内部用 AppCompatDelegate.setDefaultNightMode() 强制指定了模式，而系统设置是另一个模式，预览缩略图的色彩可能和实际界面不一致。这个问题在 WebView 里尤其明显，因为 WebView 的 forceDark 策略和系统截图的合成路径不同步。

第三个是多窗口模式。在分屏或者桌面模式下，预测性返回的预览动画被禁用，直接回退到传统的返回行为。这个 fallback 在 Android 15 的源码里写死了，没有给应用配置的空间。我测试了 Samsung DeX 模式和 Pixel 的桌面模式，都是如此。

最后一点个人看法

预测性返回手势是 Android 手势导航的补完，方向是对的。但 Android 15 把它从"可选适配"变成"默认启用"，对存量应用的冲击比 Google 预期的要大。很多应用的返回逻辑写在深层的 BaseActivity 或者 Fragment 基类里，牵一发而动全身，适配成本不低。

我不太认同官方文档里"只需一行 Manifest 配置"的说法。那行配置只是入场券，真正的适配工作涉及窗口动画、共享元素、第三方库、混合架构，还有一堆系统行为的变化。Android 15 的强制推行节奏，跟当年 Scoped Storage 有点像——技术债迟早要还，但还债的过程总是痛苦的。

目前我的策略是：新项目从第一天就按预测性返回设计，老项目按优先级分批适配，先处理用户可见的核心流程。对于那些边缘场景（比如深度嵌套的 Fragment 返回栈、复杂的共享元素过渡），如果短期内搞不定，宁可先禁用自定义预览，让系统走默认截图，也不要给用户一个错位的动画预期。