第四章 AlarmManager 与 JobScheduler 对比及 setExactAndAllowWhileIdle 使用

4.1 原理：为什么 AlarmManager 能绕过后台限制

Android 从 8.0（API 26）开始对后台执行严格限制：当应用进入 cached（缓存） 状态后，后台服务、隐式广播、JobScheduler 等均会被系统推迟或取消。AlarmManager 本用于定时闹钟和精确提醒，但它的 setExactAndAllowWhileIdle() API 能在 Doze 模式下依然唤醒设备并传递 PendingIntent。这是因为它被系统视为“高优先级事件”，允许短暂唤醒 CPU 完成注册的广播或服务。

4.2 AlarmManager vs JobScheduler：核心对比

4.3 实现流程

1. 注册广播接收器（在 AndroidManifest.xml 中静态注册或动态注册）
2. 构建 PendingIntent（指向广播接收器，FLAG_IMMUTABLE 必须）
3. 调用 AlarmManager.setExactAndAllowWhileIdle()
4. 在广播接收器中执行后台任务（可启动前台服务或直接处理）
5. （可选）在任务完成后重新设置下一次 Alarm 以形成周期性唤醒

4.4 代码实现

4.4.1 声明广播接收器（AndroidManifest.xml）

<receiver
    android:name=".KeepAliveReceiver"
    android:exported="false">
    <intent-filter>
        <action android:name="com.example.ACTION_KEEP_ALIVE" />
    </intent-filter>
</receiver>

4.4.2 设置 Alarm（在 Activity 或 Service 中调用）

// 构建 PendingIntent（必须使用 FLAG_IMMUTABLE）
Intent intent = new Intent("com.example.ACTION_KEEP_ALIVE");
PendingIntent pendingIntent = PendingIntent.getBroadcast(
        context,
        0,
        intent,
        PendingIntent.FLAG_IMMUTABLE | PendingIntent.FLAG_UPDATE_CURRENT
);

// 获取 AlarmManager
AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);

// 设置精确唤醒，允许在空闲模式下触发
long triggerTime = System.currentTimeMillis() + 10 * 60 * 1000; // 10分钟后
alarmManager.setExactAndAllowWhileIdle(
        AlarmManager.RTC_WAKEUP,
        triggerTime,
        pendingIntent
);

4.4.3 广播接收器实现

public class KeepAliveReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        // 执行后台任务，例如启动前台服务
        Intent serviceIntent = new Intent(context, MyForegroundService.class);
        context.startForegroundService(serviceIntent);

        // 可选：重新设置下一次 Alarm（注意间隔需 ≥ 9 分钟）
        long nextTrigger = System.currentTimeMillis() + 10 * 60 * 1000;
        AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
        PendingIntent pi = PendingIntent.getBroadcast(
                context, 0, new Intent("com.example.ACTION_KEEP_ALIVE"),
                PendingIntent.FLAG_IMMUTABLE | PendingIntent.FLAG_UPDATE_CURRENT
        );
        alarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, nextTrigger, pi);
    }
}

4.5 调试与验证

• 使用 adb shell dumpsys alarm 查看当前已注册的 Alarm 列表，确认 triggerTime 和 package。
• 过滤 Logcat：adb logcat -s KeepAliveReceiver:V 观察广播是否按时触发。
• 进入 Doze 模式：adb shell dumpsys deviceidle force-idle 后检查 Alarm 能否穿透。
• 检查唤醒间隔：多次触发后查看 dump alarm 中 count 字段，确保不触发系统限頻。

4.6 部署注意事项

4.7 常见错误

• PendingIntent 冲突： 使用 FLAG_UPDATE_CURRENT 保证多次设置的 Alarm 使用同一个 Receiver 实例。
• 未处理 TIMEOUT： 系统可能取消之前设置的相同 RequestCode 的 Alarm，导致无响应。
• minSdkVersion 不足： setExactAndAllowWhileIdle 需要 API 23+，旧版本需回退到 setExact。
• 唤醒时间不准： 如果设备处于深度空闲且电量低，系统可能推迟唤醒最多几秒，不要依赖毫秒级精度。

4.8 性能与稳定性优化

1. 合并唤醒： 多个组件需要定时执行时，使用同一个 Alarm 作为心跳，在广播中分发给各模块，减少唤醒次数。
2. 避免死循环： 每次 onReceive 结束时判断是否需要继续调度；如需停止，调用 cancel() 并置空 PendingIntent。
3. 使用 WorkManager 替代长时间任务： Alarm 仅负责“唤醒”，具体任务应交由 WorkManager 的 ExpeditedWork 或前台服务，防止 ANR。
4. 记录触发日志： 在广播接收器内记录时间戳和触发次数，通过 Logcat 或自建 SQLite 监控异常高频唤醒。
5. 动态感知电池状态： 当收到 ACTION_BATTERY_LOW 或 ACTION_POWER_DISCONNECTED 时，暂停或延长 Alarm 间隔。