3个核心机制搞懂勿扰模式是，手写实现原理不再懵
面试被问“勿扰模式是”怎么实现的，90%的人只能说出“拦截通知”这四个字。
面试官追问一句：“底层拦截逻辑是什么？状态如何同步？”你瞬间大脑空白，只能尴尬微笑。
这种尴尬我见过太多次了。在掘金技术社区的技术面经里，关于 Android 系统服务（System Server）和通知管理（NotificationManagerService）的深挖，往往是区分初级和中级开发者的分水岭。
很多在职开发把“勿扰模式”当成一个系统设置项，觉得那是系统的事，跟自己写的业务代码没关系。错了。如果你不懂它背后的“门控机制”和“优先级仲裁”，你的 App 在用户开启勿扰时，推送就会石沉大海，或者触发误报。
今天这篇，咱们不整虚的。直接拆解 Android 源码中 NotificationManagerService 的核心逻辑，带你手写实现一个极简版的勿扰门控器。
看完这篇，下次再被问到“勿扰模式是”什么，你能直接画出时序图，把状态机讲得明明白白。
1. 入口定位：谁在管着这个“开关”？
在 Android 系统中，“勿扰模式”并不是一个独立的进程，它深埋在 NotificationManagerService (NMS) 这个系统核心服务里。
要搞懂源码，得先找对入口。大多数开发者一上来就去翻 Settings 应用的代码，那是 UI 层，离核心逻辑十万八千里。真正的核心在 frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService.java。
这里有一个关键对象：ZenMode（在旧版本中叫 SilentMode，AOSP 源码中有时也混用，但核心逻辑一致）。
核心痛点在于： 很多教程只告诉你去调用 setInterruptionFilter()，但没告诉你这个调用背后，系统到底做了什么。
在 NMS 内部，有一个 ZenModeConfig 对象，它存储了当前的勿扰配置。当用户拨动开关时，这个配置对象的状态会改变，并触发一系列广播和回调。
重点来了： 勿扰模式不仅仅是一个布尔值 on/off。它包含复杂的“过滤规则”（Filtering Rules）。比如：允许闹钟响铃？
允许联系人消息震动？
重复消息是否升级优先级？这些规则，就是我们要解析的核心数据模型。
2. 核心片段：源码里的“门”是怎么关上的
让我们直接看 AOSP 源码中 NotificationManagerService 处理通知投递时的关键片段。这是判断“是否拦截”的核心关卡。
// 源码位置: NotificationManagerService.java
// 方法: enqueNotificationInternal
// 核心逻辑：在通知入队前进行 ZenMode 过滤private void enqueNotificationInternal(...) {// ... 省略参数检查 ...// 1. 获取当前的 ZenMode 状态// zenModeConfig 是 NMS 内部维护的全局单例状态final ZenModeConfig zenModeConfig = mZenModeConfig;// 2. 判断当前是否处于勿扰模式// 注意：这里不是简单的 if (zenMode.isOn())，// 而是检查当前的中断过滤器类型if (zenModeConfig.isEnabled()) {// 3. 执行过滤逻辑// 这一步是核心：根据通知的 Category (类别) // 和 Priority (优先级)，决定是拦截、降级还是放行if (shouldBlockNotification(notification, zenModeConfig)) {// 如果被拦截，直接丢弃，不进入 NotificationQueueSlog.d(TAG, Notification blocked by ZenMode: + notification);return; }// 4. 如果未被完全拦截，但需要降级// 例如：将 VIBRATE 降级为 SILENTadjustNotificationForZenMode(notification, zenModeConfig);}// 5. 正常入队mNotificationQueue.enqueueNotification(notification);
}// 辅助方法：判断是否应该完全拦截
private boolean shouldBlockNotification(Notification n, ZenModeConfig config) {// 检查通知类别// 例如：CATEGORY_CALL 通常不受勿扰限制，// 但 CATEGORY_MESSAGE 在严格勿扰下会被拦截int category = n.getCategory();// 获取当前配置的允许列表// 这里涉及复杂的位运算和规则匹配return !config.isAllowed(category);
}逐行拆解与避坑：mZenModeConfig 是全局状态：NMS 是单例服务，这个配置对象在内存中实时维护。任何 UI 层的变更，最终都会通过 Binder 接口更新到这里。
isEnabled() 与 getFilter()：源码中，勿扰模式不仅有开关，还有 INTERRUPTION_FILTER_NONE（无限制）、INTERRUPTION_FILTER_ALARMS（仅闹钟）、INTERRUPTION_FILTER_PRIORITY（仅重要）等模式。面试常坑： 很多人以为勿扰就是“全静默”，其实系统允许“紧急呼叫”穿透。
shouldBlockNotification：这是最核心的函数。它不是简单的黑白名单，而是基于通知元数据（Metadata）的动态评估。比如，一条短信如果来自“紧急联系人”，在“仅重要”模式下会被放行；如果是普通好友，则会被拦截。
adjustNotificationForZenMode：即使通知没被拦截，它的表现形式也会被修改。比如，原本会震动的通知，在勿扰模式下会被强制设置为静音。这就是为什么你在勿扰模式下还能收到消息，但手机不响的原因。可信细节补充：
在 AOSP 源码注释中，明确提到了 ZenMode 的设计目标是“最小化干扰”（Minimize interruptions）。这意味着，默认策略是拒绝，例外策略是允许。这与安全领域的“默认关闭”原则一致。如果你手写实现，必须遵循这个原则，否则你的 App 可能会误拦截用户的紧急通知。
3. 设计思想：状态机与观察者模式
为什么 Android 要把勿扰逻辑写得这么复杂？直接加个 if (doNotDisturb) 不行吗？
不行。 因为通知的生命周期是异步的，且状态是多变的。
这里运用了两个经典的设计模式：
3.1 状态机（State Machine）
勿扰模式本身是一个状态机。它有几个状态：OFF: 关闭
ON_ALARMS: 仅闹钟
ON_PRIORITY: 仅重要
ON_ALL: 全静默（极少用）状态之间可以跳转。例如，从 OFF 跳到 ON_ALARMS。
关键设计： 状态跳转时，必须重新评估所有当前驻留的通知队列。
想象一下：用户开启了勿扰模式，此时队列里有一条 5 分钟前发出的普通短信。这条短信原本已经显示了。开启勿扰后，系统会检查这条短信。如果规则变了（比如从“允许”变成“禁止”），系统可能会移除这条通知，或者隐藏它。
这就是为什么你在开启勿扰的瞬间，屏幕上的通知栏可能会发生变化。这不是 UI 刷新，而是数据层的重新仲裁。
3.2 观察者模式（Observer Pattern）
NMS 内部维护了一个观察者列表。当 ZenModeConfig 发生变化时，它会通知所有注册过的监听器。
// 伪代码：ZenMode 变更通知
public class ZenModeConfig {private ObserverListZenModeListener mListeners = new ObserverList();public void updateConfig(ZenModeConfig newConfig) {// 1. 更新内部状态this.config = newConfig;// 2. 通知所有监听者// 包括：NotificationManager (给 App 用)// 包括：StatusBar (给 UI 用)// 包括：NotificationQueue (给队列重新排序/过滤用)mListeners.dispatchOnZenModeChanged(newConfig);}
}实战意义：
如果你要手写实现一个简易的推送服务，你必须模仿这个结构。状态隔离：不要把勿扰状态放在 Activity 里，要放在单例的服务或 Repository 里。
事件驱动：状态变化时，必须触发回调，让所有依赖这个状态的模块（UI、推送逻辑、震动逻辑）去更新自己。
历史数据重算：这是最容易漏掉的。状态变了，以前已经存下来的数据，要不要重新过滤？必须重新过滤。4. 手写简化版：30行代码搞定核心逻辑
光看源码不够，你得自己写一遍才能懂。下面我手写一个简化版的 ZenModeManager，模拟 Android 的核心逻辑。
场景假设：有一个通知列表 ListNotification。
有一个勿扰配置 ZenConfig。
我们需要一个方法 processNotifications，根据当前勿扰状态，返回应该显示的通知列表。import java.util.List;
import java.util.stream.Collectors;
import java.util.Objects;// 1. 定义通知类
class Notification {String id;String category; // ALARM, MESSAGE, SYSTEMint priority; // 1-5, 5最高public Notification(String id, String category, int priority) {this.id = id;this.category = category;this.priority = priority;}
}// 2. 定义勿扰配置类
class ZenConfig {boolean enabled;// 允许穿透的类别列表ListString allowedCategories;public ZenConfig(boolean enabled, ListString allowedCategories) {this.enabled = enabled;this.allowedCategories = allowedCategories;}// 核心判断逻辑：该通知是否被允许显示public boolean isAllowed(Notification n) {if (!enabled) return true; // 勿扰关闭，全部允许// 规则1：闹钟永远允许if (ALARM.equals(n.category)) return true;// 规则2：高优先级通知（=4）允许if (n.priority = 4) return true;// 规则3：在允许列表中的类别允许return allowedCategories.contains(n.category);}
}// 3. 核心管理器
class ZenModeManager {private ZenConfig currentConfig;private ListNotification notificationQueue;public ZenModeManager(ListNotification queue) {this.notificationQueue = queue;this.currentConfig = new ZenConfig(false, List.of()); // 默认关闭}// 设置勿扰状态public void setZenMode(boolean enabled, ListString allowedCats) {this.currentConfig = new ZenConfig(enabled, allowedCats);// 【关键】状态变更后，必须重新计算队列reEvaluateQueue();}// 重新评估队列：过滤掉被拦截的通知private void reEvaluateQueue() {// 使用 Stream 进行过滤this.notificationQueue = this.notificationQueue.stream().filter(n - currentConfig.isAllowed(n)).collect(Collectors.toList());System.out.println(Queue re-evaluated. Size: + notificationQueue.size());}// 添加新通知public void addNotification(Notification n) {// 新通知进来时，先检查是否被当前状态拦截if (currentConfig.isAllowed(n)) {notificationQueue.add(n);} else {System.out.println(Notification + n.id + blocked by ZenMode);}}public ListNotification getVisibleNotifications() {return notificationQueue;}
}代码解析与面试加分点：isAllowed 的逻辑分层：第一层：开关检查。
第二层：硬规则（闹钟）。
第三层：软规则（优先级）。
第四层：白名单（类别）。
面试技巧： 当被问到“如果规则冲突怎么办”，你可以回答：“采用短路求值和优先级覆盖原则。硬规则（如系统闹钟）优先级最高，其次是优先级数值，最后是类别白名单。”reEvaluateQueue 的必要性：很多新手只会在 addNotification 里做过滤。
错误示范： 如果用户开启了勿扰，之前已经存在的通知依然显示在屏幕上。
正确做法： 状态变更时，必须对存量数据进行回溯过滤。这就是 Android 源码中 NotificationQueue 被 ZenMode 监听器触发重新排序/过滤的原因。线程安全考虑：在实际生产中，setZenMode 可能在主线程调用，而 addNotification 可能在后台线程调用。
解决方案： 使用 CopyOnWriteArrayList 或加锁（synchronized）。在 Android 源码中，NMS 大量使用 synchronized 块来保护 mNotificationQueue 和 mZenModeConfig。手写实现的核心价值：
通过这个 30 行的代码，你掌握了勿扰模式的本质：它不是“不发送”，而是“不显示”或“降级显示”。
它是动态的，状态变更影响存量数据。
它是规则引擎，而非简单的开关。5. 应用场景与避坑指南
理解了源码和原理，在实际开发中有哪些应用场景？
5.1 第三方 App 的推送策略
如果你的 App 依赖系统推送（FCM/ACCS），你不需要自己实现勿扰逻辑，因为系统会帮你拦截。
但是， 如果你的 App 有自己的长连接推送，或者需要在前台展示重要消息，你需要主动适配勿扰模式。
场景： 用户开启了勿扰，但你的 App 正在前台，且用户正在参与一个实时语音通话。
错误做法： 忽略勿扰模式，强行震动提醒。这会极度打扰用户，导致卸载。
正确做法：监听 ACTION_ZEN_MODE_CHANGED 广播（或监听 NotificationManager 的状态）。
如果勿扰开启，且通知优先级低于“紧急”，则静默接收，仅在 App 内部角标 +1，不发出声音/震动。
如果通知是“紧急”级别（如语音通话断开），则请求系统提升通知优先级，或者在 App 内以非打扰方式（如顶部小气泡）提示。5.2 自定义通知渠道（Notification Channel）
Android 8.0 引入了 NotificationChannel。每个渠道都有独立的 importance。
技巧：
你可以为不同业务创建不同重要级的渠道。Channel_ID_URGENT: IMPORTANCE_HIGH
Channel_ID_NORMAL: IMPORTANCE_DEFAULT当用户开启“仅重要”勿扰模式时，系统会自动只放行 IMPORTANCE_HIGH 及以上的通知。
你不需要在代码里判断勿扰状态，只需要正确设置渠道的重要性。这就是 Android 设计的优雅之处：将策略（Strategy）交给系统，将数据（Data）交给开发者。
5.3 常见避坑误判“勿扰”与“静音”：静音（Mute）只是声音关，通知依然显示。
勿扰（Do Not Disturb）是通知不显示或降级。
面试坑： 问“用户关了声音，通知还会显示吗？”答：“会。除非开启了勿扰模式，或者通知本身被设置为静默。”状态不同步：在多进程 App 中，如果主进程开启了勿扰状态缓存，而子进程没同步，可能导致子进程发出的通知被错误拦截或放行。
解决方案： 使用 ContentProvider 或 Binder 共享状态，或者每次发送前实时查询系统状态。测试覆盖不全：很多开发者只在“勿扰关闭”时测试推送。
必须测试的场景：勿扰开启，普通消息。
勿扰开启，紧急消息。
勿扰从关闭变开启瞬间，正在显示的通知变化。
勿扰从开启变关闭瞬间，之前被拦截的通知是否补发？（通常系统不会补发，但你的 App 逻辑应该知道这一点）。6. 总结与互动
“勿扰模式是”什么？
从源码角度看，它是 Android 系统通知服务中的一个动态规则引擎。
从设计模式看，它是状态机与观察者模式的完美结合。
从开发实践看，它是尊重用户体验的底线机制。
手写实现这个机制，不是为了让你重写 Android，而是为了让你理解：状态变更的影响范围（存量 vs 增量）。
规则匹配的优先级（硬规则 软规则）。
系统级服务的职责边界（拦截 vs 降级）。下次面试，如果面试官问：“你怎么处理用户在勿扰模式下的重要通知？”
你可以这样回答：“我会在代码中监听系统勿扰状态的变化。对于高优先级通知，我会通过 NotificationChannel 设置较高的 Importance，确保在‘仅重要’模式下能穿透。对于普通通知，我会静默接收并更新角标，避免打扰用户。同时，我会确保在状态切换时，对内存中的通知队列进行重新评估，保证 UI 与系统状态的一致性。”这个回答，既有源码深度，又有实战细节，还能体现你对用户体验的思考。
最后，抛出一个问题：
在你的项目里，是依赖系统勿扰模式来拦截通知，还是自己实现一套“用户偏好设置”来手动控制？
你更常用哪种写法？评论区交流。 3个核心机制搞懂勿扰模式是，手写实现原理不再懵
3个核心机制搞懂勿扰模式是，手写实现原理不再懵
面试被问“勿扰模式是”怎么实现的，90%的人只能说出“拦截通知”这四个字。
面试官追问一句：“底层拦截逻辑是什么？状态如何同步？”你瞬间大脑空白，只能尴尬微笑。
这种尴尬我见过太多次了。在掘金技术社区的技术面经里，关于 Android 系统服务（System Server）和通知管理（NotificationManagerService）的深挖，往往是区分初级和中级开发者的分水岭。
很多在职开发把“勿扰模式”当成一个系统设置项，觉得那是系统的事，跟自己写的业务代码没关系。错了。如果你不懂它背后的“门控机制”和“优先级仲裁”，你的 App 在用户开启勿扰时，推送就会石沉大海，或者触发误报。
今天这篇，咱们不整虚的。直接拆解 Android 源码中 NotificationManagerService 的核心逻辑，带你手写实现一个极简版的勿扰门控器。
看完这篇，下次再被问到“勿扰模式是”什么，你能直接画出时序图，把状态机讲得明明白白。
1. 入口定位：谁在管着这个“开关”？
在 Android 系统中，“勿扰模式”并不是一个独立的进程，它深埋在 NotificationManagerService (NMS) 这个系统核心服务里。
要搞懂源码，得先找对入口。大多数开发者一上来就去翻 Settings 应用的代码，那是 UI 层，离核心逻辑十万八千里。真正的核心在 frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService.java。
这里有一个关键对象：ZenMode（在旧版本中叫 SilentMode，AOSP 源码中有时也混用，但核心逻辑一致）。
核心痛点在于： 很多教程只告诉你去调用 setInterruptionFilter()，但没告诉你这个调用背后，系统到底做了什么。
在 NMS 内部，有一个 ZenModeConfig 对象，它存储了当前的勿扰配置。当用户拨动开关时，这个配置对象的状态会改变，并触发一系列广播和回调。
重点来了： 勿扰模式不仅仅是一个布尔值 on/off。它包含复杂的“过滤规则”（Filtering Rules）。比如：允许闹钟响铃？
允许联系人消息震动？
重复消息是否升级优先级？这些规则，就是我们要解析的核心数据模型。
2. 核心片段：源码里的“门”是怎么关上的
让我们直接看 AOSP 源码中 NotificationManagerService 处理通知投递时的关键片段。这是判断“是否拦截”的核心关卡。
// 源码位置: NotificationManagerService.java
// 方法: enqueNotificationInternal
// 核心逻辑：在通知入队前进行 ZenMode 过滤private void enqueNotificationInternal(...) {// ... 省略参数检查 ...// 1. 获取当前的 ZenMode 状态// zenModeConfig 是 NMS 内部维护的全局单例状态final ZenModeConfig zenModeConfig = mZenModeConfig;// 2. 判断当前是否处于勿扰模式// 注意：这里不是简单的 if (zenMode.isOn())，// 而是检查当前的中断过滤器类型if (zenModeConfig.isEnabled()) {// 3. 执行过滤逻辑// 这一步是核心：根据通知的 Category (类别) // 和 Priority (优先级)，决定是拦截、降级还是放行if (shouldBlockNotification(notification, zenModeConfig)) {// 如果被拦截，直接丢弃，不进入 NotificationQueueSlog.d(TAG, Notification blocked by ZenMode: + notification);return; }// 4. 如果未被完全拦截，但需要降级// 例如：将 VIBRATE 降级为 SILENTadjustNotificationForZenMode(notification, zenModeConfig);}// 5. 正常入队mNotificationQueue.enqueueNotification(notification);
}// 辅助方法：判断是否应该完全拦截
private boolean shouldBlockNotification(Notification n, ZenModeConfig config) {// 检查通知类别// 例如：CATEGORY_CALL 通常不受勿扰限制，// 但 CATEGORY_MESSAGE 在严格勿扰下会被拦截int category = n.getCategory();// 获取当前配置的允许列表// 这里涉及复杂的位运算和规则匹配return !config.isAllowed(category);
}逐行拆解与避坑：mZenModeConfig 是全局状态：NMS 是单例服务，这个配置对象在内存中实时维护。任何 UI 层的变更，最终都会通过 Binder 接口更新到这里。
isEnabled() 与 getFilter()：源码中，勿扰模式不仅有开关，还有 INTERRUPTION_FILTER_NONE（无限制）、INTERRUPTION_FILTER_ALARMS（仅闹钟）、INTERRUPTION_FILTER_PRIORITY（仅重要）等模式。面试常坑： 很多人以为勿扰就是“全静默”，其实系统允许“紧急呼叫”穿透。
shouldBlockNotification：这是最核心的函数。它不是简单的黑白名单，而是基于通知元数据（Metadata）的动态评估。比如，一条短信如果来自“紧急联系人”，在“仅重要”模式下会被放行；如果是普通好友，则会被拦截。
adjustNotificationForZenMode：即使通知没被拦截，它的表现形式也会被修改。比如，原本会震动的通知，在勿扰模式下会被强制设置为静音。这就是为什么你在勿扰模式下还能收到消息，但手机不响的原因。可信细节补充：
在 AOSP 源码注释中，明确提到了 ZenMode 的设计目标是“最小化干扰”（Minimize interruptions）。这意味着，默认策略是拒绝，例外策略是允许。这与安全领域的“默认关闭”原则一致。如果你手写实现，必须遵循这个原则，否则你的 App 可能会误拦截用户的紧急通知。
3. 设计思想：状态机与观察者模式
为什么 Android 要把勿扰逻辑写得这么复杂？直接加个 if (doNotDisturb) 不行吗？
不行。 因为通知的生命周期是异步的，且状态是多变的。
这里运用了两个经典的设计模式：
3.1 状态机（State Machine）
勿扰模式本身是一个状态机。它有几个状态：OFF: 关闭
ON_ALARMS: 仅闹钟
ON_PRIORITY: 仅重要
ON_ALL: 全静默（极少用）状态之间可以跳转。例如，从 OFF 跳到 ON_ALARMS。
关键设计： 状态跳转时，必须重新评估所有当前驻留的通知队列。
想象一下：用户开启了勿扰模式，此时队列里有一条 5 分钟前发出的普通短信。这条短信原本已经显示了。开启勿扰后，系统会检查这条短信。如果规则变了（比如从“允许”变成“禁止”），系统可能会移除这条通知，或者隐藏它。
这就是为什么你在开启勿扰的瞬间，屏幕上的通知栏可能会发生变化。这不是 UI 刷新，而是数据层的重新仲裁。
3.2 观察者模式（Observer Pattern）
NMS 内部维护了一个观察者列表。当 ZenModeConfig 发生变化时，它会通知所有注册过的监听器。
// 伪代码：ZenMode 变更通知
public class ZenModeConfig {private ObserverListZenModeListener mListeners = new ObserverList();public void updateConfig(ZenModeConfig newConfig) {// 1. 更新内部状态this.config = newConfig;// 2. 通知所有监听者// 包括：NotificationManager (给 App 用)// 包括：StatusBar (给 UI 用)// 包括：NotificationQueue (给队列重新排序/过滤用)mListeners.dispatchOnZenModeChanged(newConfig);}
}实战意义：
如果你要手写实现一个简易的推送服务，你必须模仿这个结构。状态隔离：不要把勿扰状态放在 Activity 里，要放在单例的服务或 Repository 里。
事件驱动：状态变化时，必须触发回调，让所有依赖这个状态的模块（UI、推送逻辑、震动逻辑）去更新自己。
历史数据重算：这是最容易漏掉的。状态变了，以前已经存下来的数据，要不要重新过滤？必须重新过滤。4. 手写简化版：30行代码搞定核心逻辑
光看源码不够，你得自己写一遍才能懂。下面我手写一个简化版的 ZenModeManager，模拟 Android 的核心逻辑。
场景假设：有一个通知列表 ListNotification。
有一个勿扰配置 ZenConfig。
我们需要一个方法 processNotifications，根据当前勿扰状态，返回应该显示的通知列表。import java.util.List;
import java.util.stream.Collectors;
import java.util.Objects;// 1. 定义通知类
class Notification {String id;String category; // ALARM, MESSAGE, SYSTEMint priority; // 1-5, 5最高public Notification(String id, String category, int priority) {this.id = id;this.category = category;this.priority = priority;}
}// 2. 定义勿扰配置类
class ZenConfig {boolean enabled;// 允许穿透的类别列表ListString allowedCategories;public ZenConfig(boolean enabled, ListString allowedCategories) {this.enabled = enabled;this.allowedCategories = allowedCategories;}// 核心判断逻辑：该通知是否被允许显示public boolean isAllowed(Notification n) {if (!enabled) return true; // 勿扰关闭，全部允许// 规则1：闹钟永远允许if (ALARM.equals(n.category)) return true;// 规则2：高优先级通知（=4）允许if (n.priority = 4) return true;// 规则3：在允许列表中的类别允许return allowedCategories.contains(n.category);}
}// 3. 核心管理器
class ZenModeManager {private ZenConfig currentConfig;private ListNotification notificationQueue;public ZenModeManager(ListNotification queue) {this.notificationQueue = queue;this.currentConfig = new ZenConfig(false, List.of()); // 默认关闭}// 设置勿扰状态public void setZenMode(boolean enabled, ListString allowedCats) {this.currentConfig = new ZenConfig(enabled, allowedCats);// 【关键】状态变更后，必须重新计算队列reEvaluateQueue();}// 重新评估队列：过滤掉被拦截的通知private void reEvaluateQueue() {// 使用 Stream 进行过滤this.notificationQueue = this.notificationQueue.stream().filter(n - currentConfig.isAllowed(n)).collect(Collectors.toList());System.out.println(Queue re-evaluated. Size: + notificationQueue.size());}// 添加新通知public void addNotification(Notification n) {// 新通知进来时，先检查是否被当前状态拦截if (currentConfig.isAllowed(n)) {notificationQueue.add(n);} else {System.out.println(Notification + n.id + blocked by ZenMode);}}public ListNotification getVisibleNotifications() {return notificationQueue;}
}代码解析与面试加分点：isAllowed 的逻辑分层：第一层：开关检查。
第二层：硬规则（闹钟）。
第三层：软规则（优先级）。
第四层：白名单（类别）。
面试技巧： 当被问到“如果规则冲突怎么办”，你可以回答：“采用短路求值和优先级覆盖原则。硬规则（如系统闹钟）优先级最高，其次是优先级数值，最后是类别白名单。”reEvaluateQueue 的必要性：很多新手只会在 addNotification 里做过滤。
错误示范： 如果用户开启了勿扰，之前已经存在的通知依然显示在屏幕上。
正确做法： 状态变更时，必须对存量数据进行回溯过滤。这就是 Android 源码中 NotificationQueue 被 ZenMode 监听器触发重新排序/过滤的原因。线程安全考虑：在实际生产中，setZenMode 可能在主线程调用，而 addNotification 可能在后台线程调用。
解决方案： 使用 CopyOnWriteArrayList 或加锁（synchronized）。在 Android 源码中，NMS 大量使用 synchronized 块来保护 mNotificationQueue 和 mZenModeConfig。手写实现的核心价值：
通过这个 30 行的代码，你掌握了勿扰模式的本质：它不是“不发送”，而是“不显示”或“降级显示”。
它是动态的，状态变更影响存量数据。
它是规则引擎，而非简单的开关。5. 应用场景与避坑指南
理解了源码和原理，在实际开发中有哪些应用场景？
5.1 第三方 App 的推送策略
如果你的 App 依赖系统推送（FCM/ACCS），你不需要自己实现勿扰逻辑，因为系统会帮你拦截。
但是， 如果你的 App 有自己的长连接推送，或者需要在前台展示重要消息，你需要主动适配勿扰模式。
场景： 用户开启了勿扰，但你的 App 正在前台，且用户正在参与一个实时语音通话。
错误做法： 忽略勿扰模式，强行震动提醒。这会极度打扰用户，导致卸载。
正确做法：监听 ACTION_ZEN_MODE_CHANGED 广播（或监听 NotificationManager 的状态）。
如果勿扰开启，且通知优先级低于“紧急”，则静默接收，仅在 App 内部角标 +1，不发出声音/震动。
如果通知是“紧急”级别（如语音通话断开），则请求系统提升通知优先级，或者在 App 内以非打扰方式（如顶部小气泡）提示。5.2 自定义通知渠道（Notification Channel）
Android 8.0 引入了 NotificationChannel。每个渠道都有独立的 importance。
技巧：
你可以为不同业务创建不同重要级的渠道。Channel_ID_URGENT: IMPORTANCE_HIGH
Channel_ID_NORMAL: IMPORTANCE_DEFAULT当用户开启“仅重要”勿扰模式时，系统会自动只放行 IMPORTANCE_HIGH 及以上的通知。
你不需要在代码里判断勿扰状态，只需要正确设置渠道的重要性。这就是 Android 设计的优雅之处：将策略（Strategy）交给系统，将数据（Data）交给开发者。
5.3 常见避坑误判“勿扰”与“静音”：静音（Mute）只是声音关，通知依然显示。
勿扰（Do Not Disturb）是通知不显示或降级。
面试坑： 问“用户关了声音，通知还会显示吗？”答：“会。除非开启了勿扰模式，或者通知本身被设置为静默。”状态不同步：在多进程 App 中，如果主进程开启了勿扰状态缓存，而子进程没同步，可能导致子进程发出的通知被错误拦截或放行。
解决方案： 使用 ContentProvider 或 Binder 共享状态，或者每次发送前实时查询系统状态。测试覆盖不全：很多开发者只在“勿扰关闭”时测试推送。
必须测试的场景：勿扰开启，普通消息。
勿扰开启，紧急消息。
勿扰从关闭变开启瞬间，正在显示的通知变化。
勿扰从开启变关闭瞬间，之前被拦截的通知是否补发？（通常系统不会补发，但你的 App 逻辑应该知道这一点）。6. 总结与互动
“勿扰模式是”什么？
从源码角度看，它是 Android 系统通知服务中的一个动态规则引擎。
从设计模式看，它是状态机与观察者模式的完美结合。
从开发实践看，它是尊重用户体验的底线机制。
手写实现这个机制，不是为了让你重写 Android，而是为了让你理解：状态变更的影响范围（存量 vs 增量）。
规则匹配的优先级（硬规则 软规则）。
系统级服务的职责边界（拦截 vs 降级）。下次面试，如果面试官问：“你怎么处理用户在勿扰模式下的重要通知？”
你可以这样回答：“我会在代码中监听系统勿扰状态的变化。对于高优先级通知，我会通过 NotificationChannel 设置较高的 Importance，确保在‘仅重要’模式下能穿透。对于普通通知，我会静默接收并更新角标，避免打扰用户。同时，我会确保在状态切换时，对内存中的通知队列进行重新评估，保证 UI 与系统状态的一致性。”这个回答，既有源码深度，又有实战细节，还能体现你对用户体验的思考。
最后，抛出一个问题：
在你的项目里，是依赖系统勿扰模式来拦截通知，还是自己实现一套“用户偏好设置”来手动控制？
你更常用哪种写法？评论区交流。