SwipeAwayDialog 进阶：用 onSwipedAway 回调拦截滑动关闭，精准识别左右手势

SwipeAwayDialog是一个让 Android 弹窗（DialogFragment）支持 Tinder 式"滑动甩掉"关闭手势的开源库。本文聚焦它的进阶能力：如何重写onSwipedAway回调来拦截滑动关闭，并通过toRight参数精准识别左右方向手势，实现"左滑拒绝、右滑喜欢"的差异化交互。

一分钟回顾：SwipeAwayDialog 能做什么？

普通的 Android 弹窗只能点按钮或点外部关闭。SwipeAwayDialog 让你用横向滑动手势"甩走"弹窗，效果与 Tinder 卡片一样自然。

它的核心思路只有一个：

让你的弹窗继承SwipeAwayDialogFragment，而不是原生DialogFragment。

• 兼容DialogFragment：SwipeAwayDialogFragment.java
• 兼容support.v4包下的DialogFragment：support/v4/SwipeAwayDialogFragment.java
• 项目自带的多种弹窗示例（Alert、List、日期、时间、自定义图片等）：ExampleDialogFragment.java

官方安装方式（Gradle）：

dependencies { compile 'com.labo.kaji:swipeawaydialog:0.1.1' }

onSwipedAway 回调：滑动关闭的"拦截器"

库内部在 SwipeAwayDialogFragment.java 中定义了这个方法：

public boolean onSwipedAway(boolean toRight) { return false; }

它的语义非常直白，可以把它理解为一张"放行/拦截"通行证：

关键在于：这个回调发生在关闭动画已经播放完之后、真正执行dismiss()之前。也就是说，用户的手指已经"甩出去"了，但你的代码仍有一次反悔的机会。

拦截关闭：滑动前的最后防线

以"删除确认弹窗"为例——用户手滑甩走弹窗时，你不想让它就这么消失，可以拦截并给出提示：

@Override public boolean onSwipedAway(boolean toRight) { // 阻止滑动关闭，弹出二次确认 Toast.makeText(this, "确定要放弃吗？", Toast.LENGTH_SHORT).show(); return true; }

💡 小技巧：如果某个弹窗完全不需要滑动关闭（比如加载中的 ProgressDialog），可以调用setSwipeable(false)直接禁用，无需依赖回调拦截。

精准识别左右手势：Tinder 式"喜欢 / 拒绝"

onSwipedAway唯一的参数toRight是一个布尔值，用来区分用户是向右滑（true）还是向左滑（false）。这让弹窗可以像 Tinder 卡片一样，对两个方向做出完全不同的响应：

@Override public boolean onSwipedAway(boolean toRight) { if (toRight) { sendLike(); // 右滑：喜欢 👍 } else { skipProfile(); // 左滑：拒绝 } return false; }

这种"方向 + 拦截"的组合拳，正是构建 Tinder-like UI 的核心：

右滑 → 记录"喜欢" → 关闭弹窗 → 展示下一位 左滑 → 记录"拒绝" → 关闭弹窗 → 展示下一位 上滑/点按钮 → 走原有逻辑，onSwipedAway 不参与

底层原理：手势如何被判定为"甩掉"？

SwipeAwayDialog 的滑动判定来自 SwipeDismissTouchListener.java，它借用了 Android 官方 SwipeToDismiss 组件的成熟逻辑，判定规则有两条，满足其一即可触发关闭：

1. 拖拽超过一半：手指水平位移超过弹窗宽度的一半（见 第 148 行），此时toRight由位移方向deltaX > 0决定；
2. 快速甩动（Fling）：水平速度超过系统最小甩动速度、且水平速度明显大于垂直速度，此时按甩动速度方向判定左右。

方向判定后，会播放一次"平移 + 45° 旋转 + 淡出"的飞出动画（第 162-172 行），动画结束才回调onSwipedAway。若判定不成立，弹窗会弹性回位。

整个手势链路如下：

进阶技巧：让拦截逻辑更智能

结合 canDismiss：按状态决定能否滑动

内部回调 canDismiss 会检查isCancelable() && mSwipeable，所以"不可取消"的弹窗天然无法被滑动关闭。你也可以在业务层配合控制：表单未填写完时调用setSwipeable(false)，填写完成后恢复。

关闭倾斜动画，获得更"克制"的手感

默认滑动时弹窗会倾斜跟手。若觉得晃眼，可调用：

setTiltEnabled(false); // 见 setTiltEnabled 实现

对应实现在 SwipeAwayDialogFragment.java#L36-L41。

左右方向的业务化设计建议

• 右滑 = 肯定（喜欢、确认、点赞），左滑 = 否定（拒绝、删除、跳过）——符合用户从 Tinder 养成的肌肉记忆；
• 左右行为不一致时（比如删除操作只想响应左滑），在onSwipedAway中用toRight分支处理，另一个方向return true直接拦截；
• 拦截后建议给用户明确反馈（Toast、震动、提示音），否则用户会误以为"弹窗卡住了"。

常见问题 FAQ

Q1：onSwipedAway 返回 true 后，弹窗状态会不会出错？

不会。动画结束后库会重置视图的位置、旋转和透明度（见 performDismiss），弹窗完好地回到原位，可继续交互。

Q2：为什么我的回调里 toRight 判断反了？

toRight == true表示向右滑（手指从左往右甩）。如果视觉上感觉相反，先确认自己是按"手指移动方向"还是"卡片飞出的视觉印象"在写判断。

Q3：Kotlin 项目怎么写？

完全一致，Kotlin 中重写方法时不需要@Override public：

override fun onSwipedAway(toRight: Boolean) = !toRight && needConfirm()

Q4：滑动关闭会触发 onActivityResult 等生命周期吗？

会。滑动拦截不成立时内部调用的是标准dismiss()，与代码主动关闭完全等价，所有 DialogFragment 的生命周期回调都会正常触发。

总结：三个要点收尾

1. onSwipedAway 是拦截器：返回true即可阻止滑动关闭，是"最后悔机会"；
2. toRight 是方向传感器：true为右滑、false为左滑，天然适配 Tinder 式左右双向交互；
3. 拦截要有反馈：阻止关闭后请配合 Toast / 震动提示用户，体验才完整。

配合setSwipeable、setTiltEnabled两个开关，SwipeAwayDialog 可以用极少代码，让你的任意 DialogFragment 拥有卡片式滑动手感 🃏。