9. 省电策略之JobScheduler与WorkManager：在Doze下的行为差异

说到Doze模式下的后台任务，有两个东西绕不开：JobScheduler和WorkManager。

很多开发者会问：“我到底该用哪个？” 嗯，这个问题我当年也纠结过。今天咱们就把它们掰开揉碎，看看在Doze模式下，它们到底有什么不一样。

9.1 先说说JobScheduler

JobScheduler是Android 5.0引入的。说白了，它是系统原生的任务调度器。你可以把它想象成一个“听话的管家”——你告诉它什么时间做什么事，它会尽量满足你。

但在Doze模式下，这个管家就没那么听话了。

我记得在Android 6.0刚推出Doze时，我们团队有个App需要在后台定期同步数据。用JobScheduler设置了个每15分钟的任务，结果Doze模式下，这个任务被硬生生拖了2个多小时才执行。用户反馈说数据一直不更新，我们排查了半天才发现是Doze在“捣鬼”。

JobScheduler在Doze下的行为特点

• 任务延迟：非紧急任务会被推迟到下一个维护窗口
• 批量执行：多个任务会合并在一起执行，减少唤醒次数
• 网络约束失效：在维护窗口期内，网络约束可能被忽略
• setRequiredNetworkType可能不生效：我遇到过，明明设置了需要WiFi，结果在维护窗口期用移动网络跑了

9.2 再说说WorkManager

WorkManager是Google后来推出的“亲儿子”。它其实是JobScheduler的封装，但做了很多优化。

我个人习惯用WorkManager，原因很简单：它帮我们处理了很多Doze模式下的兼容性问题。

WorkManager在Doze下的行为特点

• 自动适配：WorkManager会根据API级别自动选择底层实现（JobScheduler、AlarmManager等）
• 延迟灵活：支持设置初始延迟、退避策略，Doze下会自动调整
• 链式调用：可以串联多个任务，Doze模式下会尽量合并执行
• 观察者模式：任务状态变化可以监听，方便调试

9.3 核心差异对比

咱们直接看表格，一目了然：

特性	JobScheduler	WorkManager
最低API	21 (Android 5.0)	14 (Android 4.0)
Doze下延迟	严格延迟到维护窗口	智能调整，可设置退避策略
任务持久化	不支持（进程被杀任务丢失）	支持（Room数据库持久化）
链式任务	需要手动实现	原生支持beginWith().then()
调试难度	较高（需要看系统日志）	较低（自带WorkManager Debug）
Doze兼容性	基础兼容，需手动处理	自动兼容，开箱即用

9.4 代码示例对比

咱们直接看代码，感受一下差异：

JobScheduler实现

// 创建JobScheduler任务
ComponentName serviceComponent = new ComponentName(context, MyJobService.class);
JobInfo.Builder builder = new JobInfo.Builder(JOB_ID, serviceComponent);

// 设置约束
builder.setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED); // 需要WiFi
builder.setPeriodic(15 * 60 * 1000); // 每15分钟执行一次
builder.setPersisted(true); // 设备重启后保留

// 注意：Doze模式下，这个15分钟的周期会被拉长
// 我曾经测试过，在深度Doze下，实际执行间隔可能达到2小时以上

JobScheduler jobScheduler = (JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE);
jobScheduler.schedule(builder.build());

WorkManager实现

// 创建WorkManager任务
PeriodicWorkRequest syncWork = 
    new PeriodicWorkRequest.Builder(SyncWorker.class, 15, TimeUnit.MINUTES)
        .setConstraints(
            new Constraints.Builder()
                .setRequiredNetworkType(NetworkType.UNMETERED) // 需要WiFi
                .build()
        )
        .setBackoffCriteria(
            BackoffPolicy.EXPONENTIAL, 
            PeriodicWorkRequest.MIN_BACKOFF_MILLIS, 
            TimeUnit.MILLISECONDS
        )
        .build();

// WorkManager会自动处理Doze模式下的延迟
// 它会根据系统状态智能调整执行时间
WorkManager.getInstance(context).enqueueUniquePeriodicWork(
    "sync_data",
    ExistingPeriodicWorkPolicy.KEEP,
    syncWork
);

9.5 避坑指南

我曾经踩过几个坑，分享给大家：

1. 不要依赖setPeriodic的精确性：无论是JobScheduler还是WorkManager，在Doze模式下都不会精确按周期执行。如果你需要精确的定时任务，考虑用AlarmManager的setExactAndAllowWhileIdle()。
2. 注意任务重叠：Doze维护窗口期可能很短，如果多个任务同时触发，可能会互相影响。我建议用WorkManager的链式调用，把相关任务串起来。
3. 测试要真实：别只在模拟器上测试。我建议用真机，通过adb命令强制进入Doze模式：adb shell dumpsys deviceidle force-idle
4. 日志很重要：WorkManager提供了WorkManager.enableDebug()，可以打印详细的调度日志。这个在排查Doze下的问题特别有用。

9.6 核心逻辑图

下面这张图展示了JobScheduler和WorkManager在Doze模式下的行为差异：

9.7 我的最终建议

如果你问我选哪个，我的答案是：能用WorkManager就别用JobScheduler。

原因很简单：

• WorkManager帮你处理了Doze模式下的各种边缘情况
• 它提供了更好的持久化保证，进程被杀也不怕
• 调试工具更完善，出了问题容易定位
• Google官方也在主推，未来会持续优化

当然，如果你是在维护老项目，或者对API版本有特殊要求，JobScheduler也能用。但记得做好Doze模式下的测试，别像我当年那样，上线了才发现问题。

---

公众号:蓝海资料掘金营，微信deep3321