企业官网建设流程全解析

• 移动开发
• UI库/组件

SnackBar 是一个受 Google Material Design 规范启发的 Android 轻量级提示组件库，它实现了类似 Toast 的底部通知条，并内置了消息队列（Queue）机制：同一时刻屏幕上只显示一条消息，其余消息按先进先出顺序排队等待。本文带你读懂它的 Queue 设计原理，搞懂"单条显示"背后的完整流程。

什么是 SnackBar？先认识这个单条提示组件

SnackBar 的定位是"toast-like alert"——底部滑出、自动消失、可带操作按钮（如 UNDO、REFRESH）的轻量提示。与传统 Toast 相比，它支持：

• ✅ 自定义显示时长（短/中/长/永久）
• ✅ 操作按钮与点击回调
• ✅同一时间只显示一条，多条消息自动排队（本文主角）
• ✅ 按 Material 规范向下滑动手势可一次关闭全部队列

官方文档中明确列出了这条特性："Shows only one message at a time"，可参阅 README.md 的 Features 部分。

核心答案：一个 LinkedList 队列 + 单一容器视图

"只显示一条"的秘密藏在 SnackContainer.java 中，队列定义只有一行：

private Queue<SnackHolder> mSnacks = new LinkedList<SnackHolder>();

• Queue 接口 + LinkedList 实现：经典 FIFO（先进先出）队列，天然保证消息按创建顺序逐条展示；
• SnackHolder 是排队单元：每条消息被包装成 SnackHolder，携带消息数据Snack、视图snackView和可见性监听器；
• 容器本身只有一个：SnackContainer是一个全屏FrameLayout（见 sb__snack_container.xml），它同一时刻只挂载一条消息的视图——这就是物理层面"不能重叠显示"的原因。

入队一步：showSnack 的"只许第一条立即显示"规则

当你调用 Builder 的show()时，消息最终流入 SnackContainer.showSnack()，关键判断如下：

SnackHolder holder = new SnackHolder(snack, snackView, listener); mSnacks.offer(holder); if (mSnacks.size() == 1) showSnack(holder, immediately);

逻辑非常简洁：

1. 新消息无条件offer进队列尾部；
2. 只有当队列 size 恰好等于 1（说明它是队首且屏幕当前空闲）时，才立即上屏；
3. 否则消息默默排队，等待前面所有消息播完。

💡 对比一下：很多自绘提示条会用"只显示最新一条"的覆盖策略，而 SnackBar 选择"全部保留、按序播放"，不会丢失任何一条消息。

单条播放：时长、动画与 postDelayed 定时隐藏

消息上屏后，showSnack 私有方法 完成三件事：

• 将消息视图addView进容器，填充文案与操作按钮，播放"上滑+淡入"动画；
• 若设置了自动消失时长，则postDelayed(mHideRunnable, duration)安排定时隐藏任务；
• 绑定 OnTouchListener 支持滑动手势（见下文）。

四档时长常量定义在 SnackBar.java：

队列推进一步：动画结束回调是"下一条消息"的扳机

整个队列的推进不靠轮询，而是挂在出场动画的结束回调里，见 onAnimationEnd：

removeAllViews(); if (!mSnacks.isEmpty()) { sendOnHide(mSnacks.poll()); // 弹出刚播完的这条 } if (!isEmpty()) { showSnack(mSnacks.peek()); // 队首下一条立即上场 } else { setVisibility(View.GONE); // 队列空了，隐藏容器 }

三步完成一次"换挡"：移除旧视图 → poll 出队 → peek 出下一条上屏。由于每条消息占用的唯一视图先被removeAllViews()清空，新消息才能独占舞台——"单条显示 + 自动接力"的循环由此闭合。

队列管理辅助 API 也都很直白，见 Queue 管理区：

• isEmpty()/isShowing()：判断队列是否为空；
• peek()：只看队首不弹出（按钮点击时取 token 就靠它）；
• pollSnack()：弹出队首；
• clearSnacks(animate)：清空整个队列。

你还能通过OnVisibilityChangeListener的onShow(stackSize)/onHide(stackSize)回调拿到剩余排队条数，方便实现"还有 2 条提示等待显示"这类 UI 提示，接口定义在 SnackBar.java。

特殊行为：下滑手势为什么能"清空整个队列"

Material Design 规范要求：用户手动滑掉 Snackbar 后，等待中的消息也应一并放弃（因为用户已表明"我不想看这些提示了"）。

这一行为在 触摸监听 中实现：当向下滑动越过屏幕阈值时：

removeCallbacks(mHideRunnable); // 取消定时隐藏 sendOnHide(holder); startAnimation(mOutAnimationSet); if (!mSnacks.isEmpty()) { mSnacks.clear(); // 整个队列一并清空 }

除了手势清空，Builder 还提供了withClearQueued(true)选项（SnackBar.java），可在展示新消息前主动清空旧队列并决定是否播放隐藏动画。

进阶：队列状态如何跨进程保活？

SnackBar 把队列做成了可持久化的：

• saveState() 遍历队列，把每条Snack序列化进Bundle（键名SAVED_MSGS）；
• restoreState() 反序列化后逐条重新入队，且第一条以 0ms 动画时长立即显示，后续照常接力；
• 数据模型Snack实现了Parcelable，完整读写逻辑见 Snack.java。

示例工程 SnackBarActivity.java 中已给出onSaveInstanceState/onRestoreInstanceState的接入位置（默认注释，取消注释即可启用）。

常见问题速答

Q1：为什么 SnackBar 不允许两条消息重叠显示？一方面是 Material 规范约束（单一 Snackbar 位）；另一方面容器只挂载一个消息视图，若叠加显示会互相遮挡、无法分别接收触摸与操作按钮点击。队列化是唯一干净的解法。

Q2：多条消息会丢失吗？不会。只要不触发下滑清空或clear()，所有消息都会按入队顺序完整播放；旋转屏幕时还可配合saveState完整保活。

Q3：这条机制和系统 Toast 有区别吗？系统 Toast 不保证顺序、不可交互、无法取消；SnackBar 的 Queue 方案则保证 FIFO 顺序、支持操作按钮点击、支持手势/代码两种方式清空队列，可控性强得多。

小结：一张图看懂 SnackBar 队列流转

回顾三个设计要点：

1. 单一容器视图决定了"同时只能上一条"；
2. LinkedList 队列 + offer 入队保证了不丢消息的 FIFO 顺序；
3. 动画结束回调驱动的 poll → peek 接力让消息自动、平滑地逐条轮换。

理解了这三点，你就掌握了 SnackBar 队列机制的全部核心。想要动手验证，可用 sample 模块 中的示例工程，通过不同时长与按钮组合观察排队、接力与手势清队的完整表现。

• 移动开发
• UI库/组件