Chapter 185: Background Process Policy and Notification Delivery
后台进程策略和通知送达共同决定一个 Android OEM 系统对“应用继续存在”的态度。用户看到的是消息晚到、导航中断、音乐被暂停、健康数据缺口、设备控制失联；系统内部对应的是进程优先级、后台执行配额、网络保活、推送通道、通知权限、用户白名单和厂商省电服务的组合判断。
本章用一个贯穿行为展开：一个即时通讯 App 在锁屏一小时后收到服务端新消息，期望立即展示通知，并在用户点击通知后进入会话页。读完本章后，读者应能追踪这条路径经过哪些系统边界，定位延迟或丢失可能发生在哪一层，区分 AOSP 基础策略和 OEM 叠加策略，并用同一组检查维度评估不同厂商系统的后台控制面。
本章讨论 Android OEM 语境。AOSP 提供基础电源和后台执行模型，例如 Doze、App Standby、App Standby Buckets、Foreground Service 限制、JobScheduler 配额、通知权限和 Firebase Cloud Messaging 消息优先级。OEM 系统在此基础上加入电池管理器、自启动控制、保护应用、云推送、系统白名单和安全中心 UI。工程判断必须把这两层拆开：先判断 Android 基础策略是否已经解释现象，再判断厂商策略是否改变了默认结果。
贯穿路径可以简化为：服务端发出消息，推送通道尝试唤醒设备，系统根据空闲状态和消息优先级给 App 临时执行窗口，App 构造通知，通知管理服务根据权限、渠道和用户设置决定展示结果，用户点击通知后 App 获得前台交互并进入更高活跃度。每个环节都可能被 OEM 策略改变，后台问题的排查顺序也必须沿着这条路径推进。
这张图只覆盖通知送达主路径，暂时不讨论消息内容加密、服务端重试和业务层 ACK。它的核心价值是把“后台被杀”和“通知未到”拆成不同责任主体：推送通道负责把事件送到设备，系统电源策略负责给 App 执行窗口，通知管理负责展示权限和渠道，OEM 管理器负责额外限制和白名单，App 负责在短窗口内完成必要处理。
185.1 Background Process Policy 的厂商差异来源
Background Process Policy 指移动 OS 对后台 App 继续运行、被唤醒、访问网络、执行任务、展示通知和保留进程的策略集合。它解决的问题是：手机电量、热限制、内存、网络连接和用户注意力有限，系统需要在多个 App 之间分配后台机会，同时让用户保留对通知、耗电和隐私的控制权。
厂商差异的第一来源是电源目标不同。AOSP 策略倾向于用统一规则约束设备空闲状态和 App 使用频率；OEM 系统会根据电池容量、SoC 功耗特征、地区推送生态、预装服务、市场对续航的偏好继续收紧后台行为。同一个 App 在一台设备上能准时收到普通优先级消息，在另一台设备上可能等到维护窗口，差异常常来自 OEM 对空闲网络、进程冻结和推送通道的额外管理。
厂商差异的第二来源是进程清理策略。Android 内核和 framework 本身已经有进程优先级、低内存回收和后台执行限制；OEM 安全中心或电池管家还可能主动清理后台进程、冻结缓存进程、限制自启动广播、阻止关联启动。此时“进程被杀”只是结果，真实控制点可能在用户手动一键清理、自动清理规则、夜间省电计划、安装后默认限制或系统识别为高耗电之后的降级。
厂商差异的第三来源是推送通道。带 Google Mobile Services 的设备通常使用 FCM 作为统一下行消息通道。部分市场或设备还会叠加厂商推送服务，例如 OEM 云推送、系统消息中心或区域生态服务。推送通道发生变化时，通知送达不再只受 App 进程状态影响，还受账号登录、云服务连接、系统白名单、网络心跳和厂商服务器稳定性影响。
厂商差异的第四来源是用户设置。后台权限、自动启动、通知开关、省电模式、不受限制电池设置、数据节省、勿扰模式、通知渠道静默、应用锁和安全中心策略都可能改变同一条消息路径。用户以为自己只关闭了“省电提示”，系统内部可能已经改变了 JobScheduler 配额、Alarm 触发、网络访问或进程保留状态。
对贯穿案例，第一步应把现象拆成四个问题：服务端是否已经把消息交给推送通道；推送通道是否把事件送到设备；App 是否获得处理窗口；通知是否被系统展示。这个顺序能把后台策略、推送策略和通知策略分离。直接把所有失败归因于“厂商杀后台”会丢失责任边界，也会导致错误修复方向。
可复用判断顺序是：先看 Android 版本和目标 SDK，确认基础后台规则；再看 App 是否处于空闲、低频使用或 Restricted 类状态；再看 OEM 电池设置、自启动设置和白名单；再看推送通道和消息优先级；最后看通知权限、通知渠道和用户交互记录。这个顺序从平台基础规则走向厂商叠加规则，能减少排查中的交叉干扰。
185.2 Doze、App Standby、Standby Bucket 与基础 Android 策略
Doze 是设备级空闲策略。Android 官方文档把 Doze 描述为设备在未充电、静止、屏幕关闭一段时间后进入的低功耗状态；进入后系统会限制网络访问，延后 Job、Sync 和普通 Alarm，并周期性打开 maintenance window 处理积压活动。可参见 Android Doze and App Standby 文档。
App Standby 是 App 级空闲策略。它关注用户近期是否使用某个 App，使用频率越低，后台机会越少。Doze 的判断对象是设备整体空闲状态，App Standby 的判断对象是单个 App 与用户的关系。贯穿案例中，锁屏一小时后消息延迟可能来自设备进入 Doze，也可能来自 App 长期未被打开后被放入更低活跃度类别；两者可以同时发生。
App Standby Buckets 把 App 按使用状态分到 Active、Working set、Frequent、Rare、Restricted 等类别。Android 官方文档说明，厂商可以设置自己的非活跃 App 分桶标准，开发者应让 App 在不同 bucket 中都有合理行为，而不应依赖固定分桶结果；文档还说明 Android 12 引入 Restricted bucket，Android 13 以后在特定长期无交互或过量广播、绑定场景下可能进入 Restricted。可参见 App Standby Buckets 文档。
基础策略对后台任务的影响可以按资源看。网络访问在 Doze 中会被暂停到维护窗口或临时窗口；普通 JobScheduler 任务和 WorkManager 持久任务会被推迟；普通 Alarm 会被延后；高优先级 FCM 消息可以给 App 一个短暂网络和唤醒窗口，前提是它服务于用户可见通知。这个模型解释了很多“消息最终到了，但晚了几分钟或几十分钟”的现象。
贯穿案例中，如果服务端发送的是普通优先级数据消息，设备处于 Doze，系统可以把消息延后到 maintenance window。App 进程当时存在与否不是唯一因素；即使进程还在缓存状态，网络和 Job 也可能被系统延后。如果服务端发送的是高优先级 FCM 消息，系统可以唤醒 App 处理用户可见通知，但这不是长期后台执行许可，处理窗口结束后设备或 App 会回到空闲限制状态。
Android 基础策略还会把用户交互反馈给后台活跃度。用户点击通知可以让 App 暂时进入更活跃状态，后续 Job 和 Alarm 获得更宽松的机会；用户连续忽略或关闭通知，则通知渠道和 App 活跃度都可能下降。通知送达路径因此具有反馈环：通知展示影响用户交互，用户交互影响 standby bucket，standby bucket 又影响未来后台任务。
评估 AOSP 基础策略时，应记录五个事实：设备是否进入 Doze；App 所在 standby bucket；消息优先级；任务类型是 Foreground Service、JobScheduler、WorkManager、Alarm 还是推送回调；通知权限和渠道状态。这五个事实能解释基础 Android 层的绝大多数后台差异，随后才进入 OEM 定制层。
185.3 OEM Battery Saver、Auto-Start、Protected App、Whitelist
OEM Battery Saver 是厂商把省电目标产品化后的系统入口。它通常呈现为电池管理、省电模式、智能省电、睡眠应用、高耗电限制等 UI。它控制的对象可能包括后台网络、进程冻结、定时任务、后台定位、唤醒源、关联启动和通知保活。不同厂商 UI 名称差异很大，但系统目标一致：用更激进的后台收缩换取续航和温控余量。
Auto-Start 是厂商对应用被动启动路径的管理。Android 应用可以通过广播、推送、Job、Alarm、ContentProvider 初始化、服务绑定等路径从非前台状态进入执行。OEM 自启动管理会限制开机启动、后台关联启动、被其它 App 拉起、收到系统广播后的启动。贯穿案例中，推送到达设备后，如果厂商策略阻止 App 组件被唤起，通知可能表现为丢失或只在打开 App 后才补齐。
Protected App 是厂商给特定 App 提供的后台保护身份。保护身份通常意味着系统清理、一键加速、夜间冻结或省电模式不会按默认规则处理它。即时通讯、导航、运动健康、智能手表配套 App 往往需要这种保护。它的系统含义不是“无限后台运行”，而是从厂商额外限制中获得更高豁免级别；AOSP 的 Doze、权限、通知渠道和用户设置仍然可能生效。
Whitelist 包括多类白名单：Android 电池优化豁免列表、厂商电池白名单、自启动白名单、推送白名单、通知白名单、企业设备策略白名单和系统预装应用白名单。Android 官方文档提到部分电池优化豁免场景，但也强调即时通讯类应用若能使用高优先级 FCM，一般应通过 FCM 处理实时消息。厂商白名单的范围更宽，常由系统应用、账号服务或地区生态规则控制。
这些厂商开关的控制效果可以用同一张表比较。
| 控制面 | 常见 UI 名称 | 影响对象 | 用户可见表现 |
|---|---|---|---|
| 电池优化 | 智能省电、后台限制 | 网络、Job、Alarm、进程冻结 | 消息延迟、同步变慢 |
| 自启动 | 开机启动、关联启动 | 广播、服务、被动拉起 | 重启后收不到消息，打开后恢复 |
| 后台保护 | 保护应用、不受限制 | 清理、冻结、后台保留 | 通知稳定性提升，耗电上升 |
| 推送白名单 | 系统消息、云推送 | 推送心跳、通道保活 | 厂商生态 App 更稳定 |
| 通知设置 | 渠道、横幅、锁屏、静默 | 展示样式和打扰级别 | 有记录无提醒，锁屏不显示 |
贯穿案例中，OEM 策略可能把 FCM 高优先级消息送达之后的 App 处理窗口压缩，也可能允许厂商云推送绕过部分清理规则，还可能允许系统预装聊天 App 常驻连接。第三方 App 在这种系统上应把后台送达设计成“推送事件触发短处理，关键数据随 payload 携带，用户点击后再补全内容”的模型，减少对长连接和持续后台进程的依赖。
评估 OEM 白名单时要看实际控制对象。一个 App 被加入“允许通知”只说明通知展示权限开放，并不等于后台网络和自启动开放；加入“不限制电池”可能改善 Job 和网络窗口，但不自动授予通知权限；加入“允许自启动”可能解决开机后收不到消息，但无法改变用户把某个通知渠道设为静默的结果。把这些开关拆成控制对象，才能把用户设置说明和工程适配说明写准确。
185.4 Foreground Service、JobScheduler、WorkManager 的实际执行差异
Foreground Service 是 Android 给用户可感知持续任务提供的执行形态。它要求 App 展示常驻通知，并声明相应 service type。Android 12 以后，面向 API level 31 或更高的 App 在后台启动 Foreground Service 受到限制，官方文档列出少量例外，例如从用户可见状态转换、收到高优先级 FCM 消息等；Android 14 以后，涉及 while-in-use 权限的 Foreground Service 在后台启动时还会更早暴露权限限制。可参见 Foreground Service 后台启动限制文档。
JobScheduler 是系统批处理后台任务的调度入口。它适合网络可用、充电、空闲、延迟执行、周期性同步等任务。系统会根据 Doze、standby bucket、电量、网络和任务配额决定何时执行。App 交给 JobScheduler 的任务不代表获得确定时间点；它表达的是“满足约束后由系统调度”。在 OEM 系统上，厂商电池策略还可能进一步改变实际启动时机。
WorkManager 是 Jetpack 层对可持久化后台工作的推荐抽象。它在 Android 后端通常依赖 JobScheduler 等系统能力，适合必须最终完成的任务，例如日志上传、内容同步、离线处理。官方 Doze 文档明确指出 Doze 中 JobScheduler 不运行，WorkManager 使用 JobScheduler，因此 WorkManager 任务也不会在 Doze 中运行。可参见 WorkManager work request 文档。
这三类机制在真实设备上的差异应从启动时机、配额、取消和重试四个维度评估。
| 机制 | 适合任务 | 基础限制 | OEM 差异观察点 |
|---|---|---|---|
| Foreground Service | 导航、音乐、通话、运动记录 | 需要用户可见通知，后台启动受限 | 常驻通知是否被弱化，后台启动例外是否更严格 |
| JobScheduler | 延迟同步、批量上传、维护任务 | 受 Doze、bucket、网络和配额影响 | 任务是否被延后到充电或解锁后 |
| WorkManager | 需要最终完成的持久工作 | 底层受 JobScheduler 等限制 | expedited 配额和重试是否被省电策略压缩 |
| Alarm | 时间敏感提醒 | 普通 Alarm 在 Doze 中延后 | 精确闹钟权限和厂商闹钟保护策略 |
| Push 回调 | 用户可见事件触发 | 高优先级需服务通知 | 厂商推送通道和系统白名单差异 |
贯穿案例不应把消息接收设计成长期 Foreground Service 常驻。对 IM 类消息，合理路径是高优先级推送唤醒短窗口，App 解析 payload，立即发出用户可见通知；用户点击后进入前台，再建立长连接、拉取会话和更新本地数据库。Foreground Service 更适合通话进行中、语音播放、导航导航中这类用户已经明确感知的持续任务。
JobScheduler 和 WorkManager 在 OEM 系统上的常见表现是“最终执行，但时机不同”。如果用户抱怨通知晚到，后台同步日志显示 WorkManager 任务晚执行不能直接证明推送失败；它可能只说明消息后的补全同步被延后。排查时应把“唤醒通知”与“后台补全数据”分开记录：前者走推送和通知权限，后者走 Job 或 WorkManager 配额。
实际评估可以建立四列记录：触发时间、系统接受时间、开始执行时间、用户可见时间。Foreground Service 关注是否抛出后台启动异常和通知是否常驻；JobScheduler 关注约束满足后是否启动；WorkManager 关注任务状态、重试原因和 expedited 降级；推送关注高优先级消息是否触发短窗口。用同一组时间点比较多个 OEM，才能把“慢”转化成系统策略差异。
185.5 Push Channel、Notification Permission 与厂商推送服务
Push Channel 是服务端向设备侧 App 发送事件的通道。它的系统职责是保持一条比每个 App 自建长连接更节能、更可控的下行路径。FCM 是 Google 生态下的标准通道，Firebase 文档把 Android 消息优先级分为 normal 和 high；high priority 用于需要立即用户可见通知的消息，normal priority 在设备空闲时可能延后。可参见 FCM Android message priority 文档。
Notification Permission 是通知展示边界。Android 13 引入运行时通知权限 POST_NOTIFICATIONS，用户未授予权限时，App 即使收到推送，也可能无法展示普通通知。可参见 Android notification runtime permission 文档。这条边界经常被误判为推送失败：消息已经到达 App，业务数据库也可能已经更新，但通知管理服务根据权限和渠道设置没有把它展示给用户。
Notification Channel 是通知分类边界。Android 8.0 以后，App 需要把通知放入 channel，用户可以对每个 channel 设置声音、震动、锁屏、横幅、角标和静默。OEM 系统还可能在安全中心或通知管理页加入更多分类。贯穿案例中，“聊天消息”channel 允许声音，“营销消息”channel 静默，两个通知经过同一条推送通道也会形成不同用户可见结果。
厂商推送服务通常承担三类角色。第一类是 FCM 不稳定或不可用市场中的替代通道；第二类是 OEM 生态 App 的高可靠消息通道；第三类是系统级消息分发和账号服务的一部分。它可能比普通第三方长连接拥有更稳定的系统保活，也可能和厂商白名单绑定。开发者接入多个厂商推送 SDK 时，系统路径从单一 FCM 变成“服务端路由 → 厂商通道 → 设备系统服务 → App 回调 → 通知管理”。
推送通道和通知权限之间存在清晰顺序。推送先回答“事件是否到达设备和 App”，通知权限回答“事件是否能展示给用户”。高优先级推送也不自动覆盖用户关闭通知的决定；厂商推送通道也不自动解决 channel 静默。排查中应分别记录服务器发送成功、推送平台接受、设备回调、App 本地处理、通知发出、系统展示、用户点击这些事件。
贯穿案例中，一条合格实时消息应满足三项条件：服务端使用合适优先级；payload 包含展示通知所需的最小信息；App 在短窗口内完成通知构造。payload 信息不足会迫使 App 在唤醒后再访问网络拉取内容，而 Doze 或 OEM 网络策略可能让这次拉取失败，最终表现为推送到了但通知内容空白、延迟或无法展示。
对跨厂商设备，推送适配要从 SDK 接入、区域生态和系统镜像三方面共同确认默认通道：GMS 可用设备优先 FCM；部分中国大陆设备需要厂商推送；企业设备可能由 MDM 或专用通道控制；无网络或数据节省状态下所有通道都可能延迟。系统设计上，应把推送通道抽象为“事件到达能力”，把通知展示抽象为“用户可见能力”，二者分别监控。
185.6 Notification Delivery 的延迟、丢失和优先级变化
Notification Delivery 的延迟通常来自排队和窗口。设备进入 Doze 后，普通优先级消息、后台网络、Job 和普通 Alarm 会被延后到维护窗口；App 进入低活跃 bucket 后，任务和 Alarm 机会减少；OEM 省电策略还可能把后台网络集中到解锁、充电、Wi-Fi 或夜间维护时段。用户看到的“晚到”本质上是系统把后台活动合并到更少时间片。
Notification Delivery 的丢失需要拆成三类。第一类是推送事件未到达设备，例如网络断开、推送 token 失效、服务端发送失败、厂商通道不可用。第二类是事件到达但 App 未成功处理，例如进程启动受限、payload 不足、短窗口内又发起网络请求失败、后台启动 Foreground Service 被拒绝。第三类是通知已发出但未展示，例如通知权限关闭、channel 静默、勿扰模式、锁屏隐藏、OEM 通知过滤或用户把该类通知折叠到静默区域。
优先级变化来自系统对行为的反馈。FCM high priority 适合用户可见通知，若 App 用它做静默同步，系统和平台可能降低实际唤醒价值；用户长期不点击某类通知，系统可能降低该 App 活跃度或提示用户关闭通知；OEM 安全中心可能把频繁唤醒、频繁自启动或高耗电 App 放入更严格规则。优先级因此不是服务端单方面声明，而是服务端声明、系统策略和用户反馈共同塑造的结果。
贯穿案例可以按时间线解释三种结果。若服务端 10:00 发送普通优先级消息，设备 10:01 进入 Doze，系统 10:20 打开维护窗口，用户 10:21 看到通知，这是延迟。若服务端 10:00 发送高优先级消息，设备 10:00 收到，App 回调中又请求网络补内容失败，通知未发出，这是处理失败。若 App 10:00 成功调用通知 API，但用户关闭了聊天 channel，状态栏没有提醒，这是展示边界拦截。
后台冻结会改变进程可用性，但不会直接等同于推送丢失。很多推送 SDK 的目标就是在 App 进程不存在时由系统通道接收事件，再拉起 App 的消息处理组件。OEM 若冻结了相关系统通道、阻止组件启动或禁止自启动，才会把进程冻结转化为消息不可见。排查时应看通道回调和通知记录，不能仅凭进程列表判断送达能力。
网络保活是另一个高发误区。每个 App 自建长连接可以在前台或特定场景中提升实时性，但在后台会持续消耗电量和无线资源，也更容易触发 OEM 高耗电判断。统一推送通道用少量系统级连接承载多 App 下行事件，更符合移动 OS 的电源模型。长期后台长连接只适合少数被用户明确授权且持续可见的业务，例如通话、导航和设备连接。
评估延迟和丢失时，应把日志拆成“平台通道时间”和“App 展示时间”。平台通道时间包括服务端发送、推送平台接受、设备在线、设备回调；App 展示时间包括本地解析、权限检查、channel 选择、通知发出、通知点击。延迟主要比较时间差，丢失主要寻找最后一个成功事件。这个方法能把主观体验转化为责任边界。
185.7 后台策略对 IM、地图、音乐、健康、IoT App 的影响
不同类型 App 对后台策略的依赖不同。系统不会用同一个后台模型服务所有业务；它会根据用户可见性、持续性、传感器使用、网络实时性和安全风险做取舍。分析 OEM 策略时，应选择典型场景测试；单个定时任务只能说明任务调度表现，无法推出整个平台后台能力。
IM App 的核心需求是消息事件及时可见。合理路径是推送触发通知，用户点击后进入前台完成会话同步。它对 FCM 或厂商推送通道、通知权限、channel 设置和高优先级使用规范高度敏感。IM App 申请电池优化豁免并不总是可接受路径；如果高优先级推送已经能解决用户可见消息，系统更倾向让它走统一推送通道。
地图和导航 App 的核心需求是持续定位、语音提示、屏幕或后台路线维护。它需要 Foreground Service、定位权限、后台位置权限和常驻通知共同支撑。Android 14 以后，涉及 while-in-use 权限的 Foreground Service 启动边界更加严格；OEM 还可能在省电模式下降低定位频率或限制后台网络。测试地图类 App 时，应把“导航前台运行”“锁屏导航”“切后台导航”“省电模式导航”分开。
音乐和媒体 App 的核心需求是持续播放和媒体控制。它通常通过 Foreground Service、媒体通知、音频焦点和蓝牙控制实现后台体验。OEM 清理策略若把播放中的媒体服务清掉，用户会立即感知；因此多数系统会对活跃媒体播放给予较高保护。测试音乐类 App 时，应观察锁屏后播放是否持续、耳机按键是否可用、通知控制是否存在、电量优化是否改变播放稳定性。
健康和运动 App 的核心需求是传感器采样、运动记录和设备同步。它涉及 body sensor、location、Bluetooth、companion device、Foreground Service 和批量上传。系统可能允许低功耗传感器或硬件计步继续工作，但限制后台网络上传。OEM 策略对这类 App 的影响常表现为“本地数据还在，云端同步晚了”或“运动记录完整，实时提醒少了”。排查时要分离采样、存储、上传和通知。
IoT App 的核心需求是设备连接和控制响应。它可能依赖 Bluetooth Low Energy、局域网发现、MQTT、厂商云推送、Companion Device 角色和后台服务。OEM 策略会影响蓝牙扫描、后台网络和进程保留。可靠设计通常把“设备状态变化”走推送或系统 companion 能力，把“持续连接控制”限定在用户明确打开控制页或正在使用设备期间，把“离线恢复”交给 WorkManager 或下一次前台打开。
| App 类型 | 关键后台需求 | 推荐主路径 | 主要失败表现 |
|---|---|---|---|
| IM | 实时消息通知 | 高优先级推送加通知 channel | 消息晚到、静默、打开后补齐 |
| 地图 | 持续定位和导航提示 | Foreground Service 加定位权限 | 锁屏后定位降频、路线中断 |
| 音乐 | 持续播放和控制 | 媒体 Foreground Service | 播放暂停、控制通知消失 |
| 健康 | 传感器采样和同步 | 传感器批处理加受控上传 | 数据缺口、同步延迟 |
| IoT | 设备事件和连接恢复 | 推送事件加短窗口处理 | 状态滞后、设备离线误报 |
这些场景的共同判断点是用户可见性。用户正在听音乐、导航或记录运动时，系统更容易接受持续后台能力，因为用户能看到通知并理解耗电来源。用户没有打开 App，只等待一条聊天消息时，系统更倾向使用统一推送唤醒短窗口。用户长期不使用某个 IoT App 时，系统会把频繁扫描和长连接看作高成本后台活动。
185.8 从后台行为评估 OEM 系统策略
评估一个 OEM 系统的后台控制面，应从用户可见现象进入，再回到系统路径。可观察现象包括通知是否准时、锁屏后任务是否继续、重启后是否恢复、清理后是否保留、低电量模式是否改变行为、用户点击通知后是否改善后续送达。每个现象都对应系统控制点，不能用单一“激进”或“宽松”评价整个系统。
第一组评估维度是通知路径。发送同一类推送消息，记录 normal 和 high priority 的延迟差异；分别测试通知权限开启、关闭、channel 静默、勿扰模式、锁屏隐藏；观察用户点击通知后后续几小时的送达是否改善。这个维度回答 OEM 是否改变了推送通道、通知展示和用户交互反馈。
第二组评估维度是任务路径。使用同一 App 触发 JobScheduler、WorkManager、Alarm 和 Foreground Service，记录屏幕关闭、设备静止、低电量、充电、Wi-Fi、移动网络、自启动关闭、加入白名单等状态下的执行时间。这个维度回答 OEM 是否把后台工作集中到特定状态，是否在标准 Android 配额之外增加了限制。
第三组评估维度是进程路径。观察 App 从前台退到后台、锁屏、清理、夜间静置、重启后的进程状态和回调表现。进程被回收本身不是错误，移动 OS 本来就会回收后台进程；关键是系统是否保留了推送唤醒、任务重试和用户点击恢复路径。一个可靠的 OEM 策略可以积极回收进程，同时保证用户可见通知和明确任务能恢复。
第四组评估维度是用户设置路径。逐项改变电池优化、自启动、后台限制、通知权限、channel、数据节省、勿扰模式和安全中心清理策略，记录每个开关改变了哪类行为。这个维度能把厂商 UI 翻译成系统能力表：哪些开关控制启动，哪些开关控制网络，哪些开关控制展示，哪些开关只是改变提醒样式。
第五组评估维度是耗电反馈。OEM 系统通常会用耗电统计、高耗电提醒和自动限制闭环治理后台 App。一个 App 若频繁唤醒、长期持有 wakelock、后台扫描网络或反复自启动，可能被系统从普通后台策略推入更严格状态。评估时应同时记录耗电页面、后台运行时间和通知送达结果，因为 OEM 策略经常把“高耗电”作为后续限制的输入。
可以把完整评估流程写成稳定步骤：先固定 Android 版本、目标 SDK、GMS 状态和厂商系统版本；再固定 App 的权限、通知 channel 和电池设置；接着分别测试推送、Job、Alarm、Foreground Service；随后改变一个 OEM 设置并重复测试；最后用时间线归因到推送通道、执行窗口、通知展示或进程恢复。这个流程能在不同设备之间生成可比较结论。
贯穿案例最终得到的判断是：后台通知可靠性不是单点能力，而是一条跨服务端、推送平台、系统电源策略、OEM 管理器、通知服务和用户设置的责任链。AOSP 基础策略提供默认边界，OEM 策略改变默认边界的严格程度，App 设计决定它能否在短窗口内完成用户可见结果。评估 OEM 系统时，最可靠的方式是沿责任链记录证据；单个现象只能作为入口，不能直接推出整个平台的后台策略。
最小自检任务
你正在分析一个聊天 App：服务端确认 22:00 发送了新消息；用户手机锁屏并静置；23:10 用户打开 App 后看到消息补齐，但锁屏期间没有任何通知。请在不读取 AOSP 源码、不抓真实设备日志的前提下，写出你会怎样按系统路径排查，并说明每一步分别验证哪个责任边界。
答案要点
排查应从服务端和推送通道开始，确认消息是否交给 FCM 或厂商推送，以及消息优先级是否适合用户可见通知。若使用 normal priority，设备处于 Doze 时可以被延后到 maintenance window，打开 App 后补齐符合基础 Android 策略。
接着检查 App 是否获得处理窗口。需要确认 App 是否长期未使用、是否可能处于较低 standby bucket 或 Restricted 类状态，是否被 OEM 电池管理器限制后台网络、自启动或关联启动。若推送平台已接受但设备无回调，应重点检查通道可用性、厂商推送接入、GMS 状态和 OEM 后台限制。
然后检查通知展示边界。需要确认 Android 13 及以上的通知运行时权限、聊天 channel 是否开启、是否被设为静默、锁屏显示和勿扰模式是否允许展示。若 App 打开后数据库已有消息，但通知栏无记录，问题更可能在通知权限、channel 或 OEM 通知过滤。
最后检查用户设置和白名单。需要分别查看电池优化、自启动、后台限制、数据节省和厂商安全中心策略。加入白名单后若通知准时，说明 OEM 叠加策略改变了后台执行或推送保活；若白名单无效但开启通知权限后恢复，说明主要边界在通知展示层。
本章知识点总结
- 后台策略：后台进程策略把进程保留、网络访问、任务调度、推送唤醒和通知展示放入同一套电源与用户控制逻辑。
- 责任链：通知送达应按服务端、推送通道、系统执行窗口、App 处理、通知展示和用户点击顺序分析。
- Doze：Doze 是设备级空闲策略，会限制网络并延后 Job、Sync 和普通 Alarm 到维护窗口。
- Standby：App Standby 和 bucket 描述 App 与用户交互频率，低活跃类别会减少后台任务和 Alarm 机会。
- OEM 差异：厂商差异主要来自电池管理、进程清理、自启动控制、推送服务、白名单和用户设置。
- 白名单边界：通知允许、电池不受限制、自启动允许和推送白名单控制的是不同对象，效果不能互相替代。
- FGS 边界：Foreground Service 适合用户可感知持续任务，后台启动和 while-in-use 权限在新 Android 版本中受到明确限制。
- 任务调度：JobScheduler 和 WorkManager 表达延迟后台工作的调度请求，实际执行时间受 Doze、bucket、配额和 OEM 策略影响。
- 推送优先级：高优先级推送应服务用户可见通知，普通优先级消息在空闲状态下可以延后。
- 通知权限：Android 13 及以上通知运行时权限和通知 channel 会把“消息已到达”转化为“用户是否看见”。
- 延迟归因：延迟通常来自维护窗口、低活跃 bucket、后台网络限制或 OEM 省电策略的排队。
- 丢失归因：丢失要区分推送未到、App 未处理、通知未展示三类失败。
- 场景差异：IM、地图、音乐、健康和 IoT App 依赖不同后台能力，应按用户可见性和持续性分别测试。
- 评估方法：评估 OEM 后台策略要固定版本、权限、channel 和电池设置，再逐项改变 OEM 开关并记录时间线。