在 Android 的词典里，「通知延后」可能不是你以为的意思

编注：少数派会员第一季的内容更新已于 5 月底顺利结束。目前，我们已经开始预售 第二季会员，预计于 7 月中下旬正式开始更新。关于第二季会员的详细信息，你可以 点此了解。

提起「延后（snooze）」这个词你会想起什么？

如果你是 Gmail、Spark 等邮件服务，或 Todoist 这类 GTD 工具的使用者，或许会认为延后就是「稍后提醒」：重要但不紧急的邮件没空处理，延后；到期无暇处理的任务，延后；准时响起的闹钟挡不住依然强烈的睡意，延后……

所有这些用到这一概念的场景，「延后」操作所对应的无一例外都是某个特定、并且一般也是唯一的对象，比如一封邮件、一项任务、一个闹钟。

但 Android 不是这么想的。虽然 Android 系统中也有一个名为「通知延后」（notification snooze）的功能，但它的含义和机制却没法用两三句话解释得清楚，也经常成为用户困惑的来源。本文中，我们就来翻翻 Android 的词典，看看它到底是怎么定义「延后」的。

▍延后不是单条通知的稍后提醒

熟悉 Android 演化历史的读者可能知道，对 Android 的通知系统来说，Android 8.0 可以说是一次非常关键的升级：通知渠道、通知圆点以及我们今天讨论的通知延后功能，均是在这个版本中引入的。

在早期的 Android 版本中，延后一条通知的方式是在这条通知上左右短距离轻扫（注意不是直接划掉），然后点击通知横幅侧边出现的时钟图标即可将其延后。默认支持的延后时间包括 15 分钟、30 分钟、1 小时和 2 小时四档。

早期 Android 版本中的通知延后功能

显然，这个交互容易和删除通知条目产生冲突和混淆。于是在 Android 12 中，Google 将该功能调整为一个安静地躺在通知右下角的小图标。展开通知后，点击这个小图标方可延后。

通知延后在基于 Android 12 的 One UI 4.1 中的操作方法

但无论是之前还是现在，Android 通知延后功能的操作方式，和其它通知相关操作（比如长按某条通知将其优先级设置为「静音」）一样，都是通过直接在特定通知上操作实现的。

长按通知进行交互的另一个例子

从好的角度看，这种与通知直接互动的方式，符合「我要对这条通知 / 这条通知的发起应用进行设置」的操作直觉。但这种设计的副作用在于，会给人一种「我正在与这条通知进行交互」的暗示；再加上「通知延后」这一命名并不清晰，就会让不少人对通知延后功能的实际效果产生误解，即理解成了「让这条通知晚点再出现」。

还有一种常见的说法称，通知延后的意思是「让应用完全静音」，即只要延后一条通知，就能在选定时间内阻止相关应用的所有通知。

▍延后针对的是整个通知渠道

这些理解都是不正确的，错误的根源是理解错了 Google 对通知延后的功能设计。

在 Google 的本意中，虽然通知延后的交互对象是某条具体的通知，但其作用对象并不是这一条通知及其内容，而是这条通知所对应的通知渠道（notification channels）。

例如，假设某款应用有「营销通知」和「对话通知」两种通知渠道。那么，当我们对一条属于「营销通知」的消息进行延后操作时，实际上将会推迟此后各条营销通知，直到选定的生效时间结束。相反，即使在这段时间内，该应用的对话通知依然可以正常推送。

换言之，在理想状态下，通知延后的实际效果包括：

让直接交互的那条通知稍后显示；

让对应通知渠道的所有通知在设定的时间范围内不再提醒；

设定时间范围内的其它通知能够在延后结束时正常出现；

被延后的所有通知的通知内容都能自动更新到最新状态。

这个机制的设计逻辑，某种程度上也与 Google 在 Android 8.0 同时推出通知渠道与通知延后功能的做法相吻合。二者应该是相辅相成的。

那么，延后单条通知可以「让应用彻底静音」的印象又是如何产生的呢？这是因为我们所接触到的国内应用大多没有正确适配通知渠道，国内定制系统「杀后台」问题一直都比较严重，进一步阻碍了通知的有效送达。

结果，一旦延后了一条通知，实际效果几乎总是让应用的所有通知都被延后。再加上延后本身就是一个使用人群规模相对较小的功能，以讹传讹，自然也就会有「通知延后可以直接让应用彻底静音」的普遍认知了。

▍延后功能本可以更有用

最近刚好有个从 iPhone 迁移到 Pixel 的朋友，提出了一个「短时间内让特定应用静音」的需求。当时，我也没有理解通知延后的正确含义，于是提出了一系列别的解决方案：

通过数字健康中的「专注模式」功能，将想要静音的应用放进黑名单，然后进行专注模式定时；

开启系统勿扰模式，然后将除了想要静音的应用之外的所有其它应用，全部加入「例外」；

通过其它方式（冰箱、屏幕时间限制等）将应用暂停、冻结或休眠。

两种可能但比较麻烦的解决方案

但这两种操作的确都太麻烦了，对于这种出现频率可能并不高的需求来说，一次设置之后的恢复成本也比较高。

意识到通知延后的实际含义后，我才顿觉「蓦然回首」：通知延后功能正是非常适合这一需求的解决方案。

可惜的是，通知延后要发挥全部功能，是以应用正确适配了「通知渠道」为前提的。但由于上述的设计问题以及国内应用的现状，「通知延后」并没有发挥出应有的价值，也没有为更多用户所发现。

值得一提，Google 似乎也意识到了「延后」（snooze）这个命名可能会引发的歧义。在 Android 10 的第三个测试版中，通知延后功能一度被 Google 砍掉。

但这未免有些矫枉过正了。毕竟，让现在来不及处理的通知晚点再出现，听上去是个非常有用的功能。Google 的决策也因而引起了用户的不满。

结果，在 Android 10 的第五个测试版本中，Google 又向用户妥协，将通知延后功能做成了一个默认关闭的可选开关。但这是治标不治本的，说明 Google 或许还是没有意识到，很多用户对这个功能的执念都来源于对「延后」操作的误解。但是，关于这一功能，Google 至今只在面向开发者的文档中，做了下面这段模棱两可的说明，却并未对一般用户进行任何更细致的解释。

Snoozing: Users can snooze notifications, which causes them to disappear for a period of time before reappearing. Notifications reappear with the same level of importance they first appeared with. Apps can remove or update a snoozed notification, but updating a snoozed notification does not cause it to reappear.

休眠：用户可以将通知置于休眠状态，以便稍后重新显示它。重新显示时通知的重要程度与首次显示时相同。应用可以移除或更新已休眠的通知，但更新休眠的通知并不会使其重新显示。

可以发现，中文版的文档中，notification snooze 的翻译其实是「休眠」。虽然这和系统中不一样，但综合上述，在我看来反倒是个更加准确、也更不容易让人误解的命名。