Doze 深度休眠模式与国内厂商后台限制

回到总览：异步后台任务、保活、系统能力
相关模块：WorkManager / ForegroundService / AlarmManager 对比 · Android Foreground Service 深挖（服务类型、通知约束与高版本后台限制）

一句话定义

Doze 模式（深度休眠模式）与国内厂商（小米 MIUI/HyperOS、华为 HarmonyOS、vivo OriginOS、OPPO ColorOS 等）定制的后台限制策略，是 Android 系统与手机厂商为了延长续航，通过限制后台应用的网络访问、挂起 CPU WakeLock、延迟 Job/Alarm 执行以及强杀后台进程的技术机制。

代码索引

对应 Lab：alarmmanager-doze-demo · AlarmManagerDemoActivity.kt

为什么需要

为什么在开发机上跑得好好的定时任务（如 AlarmManager 每 5 分钟响一次），手机屏幕关闭静止一段时间后就不再触发了？
- 一句话答：设备灭屏且静止一段时间后会进入 Android Doze 模式，系统会挂起 WakeLock 并限制网络，普通 AlarmManager 和 JobScheduler 的执行会被延后到统一的维护窗口（Maintenance Window）中批量处理。
为什么 10 年 Android 工程师必须了解国内厂商的“对齐唤醒”与“一键杀后台”？
- 一句话答：国内厂商 ROM 的后台拦截规则比原生 AOSP 更加激进（如自启管理、关联启动拦截、应用智能保活策略）；“代码能跑通”并不等于“在国产手机上能收到推送/跑完后台任务”，必须做适配与引导。

底层机制

1. 原生 Doze 模式两大阶段

对应 Lab：alarmmanager-doze-demo（setExact vs setExactAndAllowWhileIdle 触发对比）

Android 6.0 (API 23) 引入 Doze 模式，7.0 (API 24) 扩展为浅度与深度两阶段：

text

[灭屏 + 未插电源]
       │
       ▼ (浅度 Doze: 限制网络访问，挂起 Job/Sync)
 [Light Doze] ─── (定期进入短暂 Maintenance Window 批量跑任务) ───┐
       │                                                         │
       ▼ (静止不动一段时间后进入深度 Doze)                       │
 [Deep Doze] ───► 限制: 1. 忽略 WakeLock                         │
                  2. 暂停 Network 访问                           │
                  3. 挂起 AlarmManager (除非 setAndAllowWhileIdle)│
                  4. 停止 Wi-Fi 扫描                             │
                                                                 │
 [维护窗口] <────────────────────────────────────────────────────┘

Doze 限制四大核心禁令

禁用网络访问：应用无法发起任何 HTTP/TCP 连接。
忽略 WakeLock：系统忽略应用持有的 CPU PowerManager.WakeLock，强制 CPU 进入休眠。
延迟 Alarm 闹钟：标准的 set() / setExact() 闹钟被推迟，除非使用 setAndAllowWhileIdle() 或 setAlarmClock()。
暂停 JobScheduler 与 SyncAdapter：后台任务被挂起等待维护窗口。

2. 国内厂商 Rom 后台限制“三座大山”

关联启动拦截 (Auto-start / Associated Start)：阻止应用 A 唤醒应用 B。若 App A 的 Push SDK 尝试通过拉起同系的 App B 进程，厂商 ROM 会直接拦截并记录“关联启动违规”。
对齐唤醒 (Aligned Alarm)：厂商将不同应用申请的 Timer/Alarm 强行对齐到 5 分钟或 15 分钟的整数倍统一唤醒，降低 CPU 唤醒频次。
墓碑模式 / 进程冻结 (Process Freezing)：应用退后台一定时间后，厂商直接使用 Linux cgroups（freezer 机制）将整个应用进程中的所有线程挂起（SIGSTOP），导致代码完全停止运行。

Android / Flutter / Web / Backend 对照

维	原生 AOSP (Doze)	国内厂商 ROM (HyperOS/ColorOS)	iOS 宿主 (iOS Background)
后台控制粒度	统一规则（灭屏/静止触发）	极其激进（算法智能判断、内存清理）	绝对白盒控制（无授权直接冻结）
突破机制	申请系统电池优化白名单	引导用户在设置中开启“自启动/后台高耗电”	依赖 Apple Push Notification (APNs)
保活可行性	依靠 Foreground Service (FGS)	必须结合厂商 Push 通道 (小米/华为/vivo)	无法保活，只能靠 APNs 唤醒

常见场景

1. 检查并引导用户申请“忽略电池优化”白名单

如果应用确实需要高频后台协同（如蓝牙设备实时同步）：

java

public void requestIgnoreBatteryOptimizations(Context context) {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
        PowerManager pm = (PowerManager) context.getSystemService(Context.POWER_SERVICE);
        boolean isIgnoring = pm.isIgnoringBatteryOptimizations(context.getPackageName());
        if (!isIgnoring) {
            // 弹出系统弹窗引导用户开启白名单
            Intent intent = new Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS);
            intent.setData(Uri.parse("package:" + context.getPackageName()));
            context.startActivity(intent);
        }
    }
}

2. 跳转国内厂商ROM“后台自启动管理”设置页

java

public static void jumpToVendorAutoStartSettings(Context context) {
    Intent intent = new Intent();
    String brand = Build.BRAND.toLowerCase();
    if (brand.contains("xiaomi")) {
        intent.setComponent(new ComponentName("com.miui.securitycenter", 
                "com.miui.permcenter.autostart.AutoStartManagementActivity"));
    } else if (brand.contains("huawei")) {
        intent.setComponent(new ComponentName("com.huawei.systemmanager", 
                "com.huawei.systemmanager.startupmgr.ui.StartupNormalAppListActivity"));
    }
    // ... 尝试捕获 Exception 避免 ActivityNotFoundException
    try {
        context.startActivity(intent);
    } catch (Exception e) {
        // 降级跳转到通用 App 详情页
    }
}

常见误配、事故后果与排障

1. 事故：依靠死循环或 Daemon 双进程守护企图“永生保活”

误配原因：在 Android 8.0+ 时代继续使用旧版 JNI fork 子进程、黑白灰保活或双进程 startService 互拉。
后果：国内厂商 ROM 会将此类黑产保活行为识别为恶意应用，直接在应用商店下架或在安装时弹“风险软件警告”，且 Android 8.0+ 系统会在数秒内直接 kill -9 该子进程。
排障与修法：放弃黑产保活！正统方案：业务消息靠厂商推送通道（小米/华为/OPPO/vivo Push），长耗时靠 FGS，延迟后台任务靠 WorkManager。

与相近概念对比

机制	触发条件	能否访问网络	能否持有 WakeLock	突破方式
Light Doze	屏幕关闭	否 (周期性放开)	是	维护窗口或高优先级 FCM
Deep Doze	灭屏 + 静止	否	否	白名单或 `setAndAllowWhileIdle`
App Standby	应用长时间未被主动点击	否	是	用户再次打开应用

对应实验

Lab	说明	源码
alarmmanager-doze-demo	setExact vs setExactAndAllowWhileIdle 在 Doze 下的触发差异（含 adb 进 Doze 步骤）	AlarmManagerDemoActivity.kt · AlarmReceiver.kt

复习检查题

如何使用 adb 命令在开发调试时手动强制设备进入深度 Doze 模式？
答：可以使用以下两条 adb 指令：
1. 模拟拔掉电源并灭屏：adb shell dumpsys battery unplug
2. 强制切入 Deep Doze 状态：adb shell dumpsys deviceidle step deep（重复执行该命令直至状态切换为 IDLE）。恢复命令为 adb shell dumpsys battery reset。
为什么在原生 Android 设备上已经进入 Doze 模式的情况下，AlarmManager.setAndAllowWhileIdle() 依然能响？
答：因为 setAndAllowWhileIdle() 是 Android 官方专门为紧急定时任务（如闹钟、药丸提醒）留出的 Doze 突破口。即便处于深度 Doze 模式下，系统也会按时触发该 Alarm，但系统规定此方法在 Doze 下每 9 分钟（或 15 分钟）最多触发一次，以防滥用。

速记

Doze 两阶段：浅度限制网络，深度忽略 WakeLock 且延迟 Alarm。
突破途径：电池优化白名单，或使用 setAndAllowWhileIdle 紧急定时。
国产 ROM 规矩：抛弃黑产双进程保活，消息全面接入厂商厂商 Push 通道。

Doze 深度休眠模式与国内厂商后台限制 ​

一句话定义 ​

代码索引 ​

为什么需要 ​

底层机制 ​

1. 原生 Doze 模式两大阶段 ​

Doze 限制四大核心禁令 ​

2. 国内厂商 Rom 后台限制“三座大山” ​

Android / Flutter / Web / Backend 对照 ​

常见场景 ​

1. 检查并引导用户申请“忽略电池优化”白名单 ​

2. 跳转国内厂商ROM“后台自启动管理”设置页 ​

常见误配、事故后果与排障 ​

1. 事故：依靠死循环或 Daemon 双进程守护企图“永生保活” ​

与相近概念对比 ​

对应实验 ​

复习检查题 ​

速记 ​