編注：少數派會員第一季的內容更新已于 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 的翻譯其實是「休眠」。雖然這和系統中不一樣，但綜合上述，在我看來反倒是個更加準確、也更不容易讓人誤解的命名。