5.3 Toast与Snackbar反馈艺术

5.3 Toast 与 Snackbar 反馈艺术

本节摘要：反馈是"App 听到了"的证明。Toast 轻量无交互、适合纯告知；Snackbar 贴底、可带撤销动作；对话框则用于必须决策的场合。本节讲清两者的 API 细节与时长档位的真实含义，给出反馈密度与层级的选择框架。

先分清三件工具

用户按下"提交"，界面必须有回应。Android 给了三档反馈强度：Toast 是系统级小气泡，飘过即逝、不可交互；Snackbar 贴在界面底部、可带一个动作按钮；AlertDialog 模态拦截、必须处理。强度递增，打扰也递增，选择的标准不是"哪个更新"，而是这件事用户需要做决定吗。猜数字的三种反馈正好覆盖三档：输入非法用 Toast 告知；清空战绩用 Snackbar 给撤销机会；放弃进行中的一局用对话框要确认。

Toast 的基本用法本章已见过几次，补齐细节：

Toast.makeText(this, "请输入 1 到 100 之间的整数", Toast.LENGTH_SHORT).show()

// 连续反馈防叠泡：持有实例先取消
private var toast: Toast? = null
fun feedback(msg: String) {
    toast?.cancel()
    toast = Toast.makeText(this, msg, Toast.LENGTH_SHORT).apply { show() }
}
​

LENGTH_SHORT 与 LENGTH_LONG 是仅有的两档，实际大约 2 秒与 3.5 秒——别指望自定义 800 毫秒，也尽量少用 LONG，超过用户阅读速度的停留都是骚扰。连点五次按钮弹出五个 Toast 排队轮播是经典事故，feedback 写法先 cancel 再 show 就治好了。

Snackbar：能说话也能做事

Snackbar 的出场必须先认识 coordinatorLayout——把它作为父容器，Snackbar 能自动给浮动按钮让位、随滑动消失。基本形态：

Snackbar.make(binding.coordinator, "战绩已清空", Snackbar.LENGTH_SHORT)
    .setAction("撤销") { undoClearHistory() }
    .show()
​

setAction 是它与 Toast 的分水岭：可交互。破坏性操作后的三秒犹豫期里给一个撤销入口，比弹"确定要删除吗"对话框更流畅——用户先做、后悔再撤，操作路径短了一半。但有动作就得用 LONG 档给足反应时间；用户清楚地点了动作按钮后，Snackbar 该 dismiss。

三个实战细节。其一，setAnchorView 可以把 Snackbar 钉在某个控件上方，比如让提示条永远贴着按钮行而不是屏幕底——小屏上输入法弹出时，默认底部位置会被键盘顶飞。其二，短文本是铁律，一行放不下就说明该换对话框了。其三，同屏只留一条：新 Snackbar 出现旧的自动消失，别自己叠。

图：三档反馈强度的选择路径

反馈过载的三个反模式

复读机型：每次点击都弹 Toast"已提交"。首次之后这些气泡全是噪音——状态变化直接反映在界面上（按钮变灰、文字更新）就是最好的反馈，提示条只留给界面表达不了的信息。抢答型：操作还没生效就弹"成功"。正确顺序是动作完成后的回调里再反馈，提前庆祝等于撒谎，失败时用户体验到双重背叛。模态滥用型：什么都弹对话框确认。三个确认弹窗之后用户会形成"无脑点确定"的肌肉记忆，真正的危险时刻反而失去保护——能撤销的都改成 Snackbar，把模态留给不可逆操作。

本节要点回顾

• 三档对三问：纯告知 Toast、可撤销 Snackbar、须决策对话框，强度与打扰同涨。
• 两档时长不可微调：SHORT 约 2 秒 LONG 约 3.5 秒，LONG 要有理由。
• setAction 是分水岭：破坏性操作给撤销入口，比先拦后放流畅。
• 界面自明优于提示条：按钮变灰、文字更新是第一反馈，气泡只补盲区。
• 模态是稀缺资源：滥用确认框会训练用户无脑点确定，留给不可逆操作。

两个延伸场景

反馈要出现在哪一屏？ Snackbar 绑定的是当前界面容器，页面切换后旧反馈自然消失，这通常正是想要的；Toast 则跨页面存在，适合"后台任务完成"这类不属于任何一屏的广播式通知。分清"这屏的事"与"全局的事"，两者就不再难选。

无障碍视角下的反馈是什么？ 读屏用户看不见气泡浮现。系统对 Toast 与 Snackbar 都做了无障碍播报支持，前提是你的文案自足——"已清空"够好，"操作成功"则信息量为零。写反馈文案时假想它会被朗读出来，质量自然上一个台阶。

再往深处想一层：反馈的本质是"系统状态变化的外显"。沿着这个定义，反馈远不止提示条一种形态——按钮按下时的水波纹是反馈，猜错时标题颜色抖一下是反馈，列表新增条目的插入动画也是反馈。当你开始把"每次状态变化都有外显"当作界面的完成标准，而不是"每个按钮都配一个 Toast"，你的交互设计就从及格线迈向了专业线。猜数字 App 可以做这样的收尾练习：列出它全部的状态变化，逐一检查外显方式，把其中两处 Toast 升级成界面自明式的反馈，做完再回看本节的三档选择框架，体会会完全不同。

工具选型之外还有文案维度值得补一笔：反馈文案要写"发生了什么、接下来能做什么"，而不是单摆一个结果词。"已清空，可撤销"好过"完成"，"网络未连接，请检查后重试"好过"失败"。反馈是 App 与用户的对话，对话的质量落在动词与信息量上，这一点写在文案检查清单里，每次发布前过一遍。

顺带把 Snackbar 与视图体系的联动补完整：它对 CoordinatorLayout 的依附不只是让位浮动按钮——配合 Behavior 还能响应滑动 dismissing（用户上滑手势直接收走提示条），这类细节让反馈组件与界面手势浑然一体，也是"用对容器"红利的又一例证。至此第 5 章三节闭环：听（监听机制）、答（输入处理）、说（反馈艺术），App 的对话能力三件套全部到位，第 6 章开始给它换上得体的衣着。