一、JobScheduler 到底是什么？

说实话，我刚接触 Android 开发那会儿，对 JobScheduler 的第一印象就是——「又一个系统调度工具」。但用久了才发现，它其实是 Google 为了解决一个老大难问题而生的：应用在后台乱搞，把用户的电量耗光。

你想想看，早期的 Android 应用，想做什么就做什么。后台开个 Service 一直跑，AlarmManager 定时唤醒，系统根本管不住。结果呢？用户的手机半天就没电了。Google 实在看不下去了，于是在 Android 5.0（API 21）推出了 JobScheduler。

说白了，JobScheduler 就是一个智能的任务调度器。它帮你把「不那么紧急的任务」攒起来，等到条件合适了再统一执行。比如：

  • 等到连上 Wi-Fi 再下载大文件
  • 等到手机在充电时再备份照片
  • 等到系统空闲时再清理缓存

我个人习惯把 JobScheduler 理解为「有教养的后台任务管家」。它不会像熊孩子一样乱来，而是乖乖等系统说「可以了」，才开始干活。

核心思想：把任务的执行时机交给系统，而不是由应用自己决定。系统根据电量、网络、空闲状态等条件，统一调度所有应用的 Job。

二、它解决了什么问题？

我在项目中遇到过不少因为后台任务滥用导致的线上问题。最典型的一个：某个社交应用，每 5 分钟用 AlarmManager 唤醒一次，去拉取新消息。结果用户反馈「手机待机一晚上掉了 30% 的电」。嗯，这就是典型的「好心办坏事」。

JobScheduler 主要解决了以下三个痛点：

2.1 电量优化

系统可以把多个应用的 Job 合并到一起执行。比如 A 应用要等 Wi-Fi，B 应用也要等 Wi-Fi。系统会让它们在同一批网络唤醒中完成，而不是各唤醒一次。这叫「批量处理」。

2.2 减少网络请求

以前每个应用各自为政，你唤醒一次我唤醒一次，网络模块频繁开关，功耗巨大。JobScheduler 允许你设置「只在非计费网络下执行」，说白了就是帮用户省流量。

2.3 避免应用互相唤醒

Android 上有个臭名昭著的问题叫「链式唤醒」。A 应用唤醒 B，B 唤醒 C，最后整个手机都在跑。JobScheduler 由系统统一调度，从根源上杜绝了这种乱象。

我的经验：如果你在做一个内容型 App，比如新闻客户端，强烈建议把「预加载下一屏数据」这个任务交给 JobScheduler。设置条件为「连接到 Wi-Fi 且设备空闲」。这样用户打开 App 时，数据已经准备好了，体验极佳。

三、与 Service、AlarmManager 的对比

很多新手会问：我直接用 Service 跑后台不行吗？AlarmManager 定时唤醒不行吗？嗯，我们来掰扯掰扯。

特性 Service AlarmManager JobScheduler
引入版本 API 1 API 1 API 21
执行时机 立即执行 指定时间执行 条件满足时执行
系统管控 无 弱（可被省电策略限制） 强（由系统统一调度）
电量影响 高 中 低
适用场景 前台服务、即时任务 闹钟、定时提醒 后台同步、预加载、上传

3.1 Service 的问题

Service 本身就是一个「没脑子的苦力」。你让它跑，它就跑，不管系统是不是在低电量，不管用户是不是在看视频。从 Android 8.0 开始，后台 Service 被严格限制，你根本跑不了多久。

我曾经接手过一个项目，里面有个 Service 每 10 秒轮询一次服务器。结果呢？用户手机发烫，被各大应用商店下架了。惨痛的教训。

3.2 AlarmManager 的问题

AlarmManager 适合做「必须准时」的事情，比如闹钟。但如果你用它来做「每隔半小时同步一次数据」，那就大错特错了。

为什么？因为 Android 6.0 引入了 Doze 模式。手机关屏后，AlarmManager 的唤醒间隔会被拉长。你以为半小时一次，实际上可能两小时才一次。而且频繁唤醒会打断 Doze 模式，让系统无法进入深度休眠。

注意：不要用 AlarmManager 做周期性网络请求。这是我在多个项目里踩过的坑。用 JobScheduler 的 setPeriodic() 方法，系统会自动帮你做对齐和合并。

3.3 JobScheduler 的优势

JobScheduler 最大的优势就是「听话」。它完全服从系统的调度策略：

  • 系统说「电量低，别跑了」，它就等着
  • 系统说「网络不好，别下载了」，它就暂停
  • 系统说「用户正在玩游戏，别打扰」，它就推迟

说白了，JobScheduler 是一个懂得审时度势的调度器。它不会为了完成你的任务，去牺牲用户的体验。

四、核心知识体系

下面这张图，是我自己总结的 JobScheduler 知识体系。你可以把它当作学习路线图：

JobScheduler 知识体系 JobScheduler 什么是 JobScheduler？ 解决了什么问题？ 与 Service 对比 与 AlarmManager 对比 JobInfo.Builder JobService JobScheduler 系统服务 网络约束 充电状态约束 空闲状态约束 存储/时间约束

五、一个最简单的例子

光说不练假把式。我们来看一个最简单的 JobScheduler 用法。假设我们要在「设备充电且连接 Wi-Fi」时，执行一次数据同步：

// 1. 构建 JobInfo
JobInfo jobInfo = new JobInfo.Builder(JOB_ID, new ComponentName(context, SyncJobService.class))
    .setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED)  // 非计费网络（Wi-Fi）
    .setRequiresCharging(true)                               // 需要充电
    .setPersisted(true)                                      // 设备重启后保留
    .build();

// 2. 获取 JobScheduler 系统服务
JobScheduler jobScheduler = (JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE);

// 3. 调度任务
int result = jobScheduler.schedule(jobInfo);
if (result == JobScheduler.RESULT_SUCCESS) {
    // 调度成功
} else {
    // 调度失败（可能是 Job 太多，系统拒绝了）
}

对应的 JobService 实现：

public class SyncJobService extends JobService {
    @Override
    public boolean onStartJob(JobParameters params) {
        // 在这里执行你的后台任务
        // 注意：这个方法运行在主线程，耗时操作要开子线程
        new Thread(() -> {
            // 执行数据同步...
            // 同步完成后，通知 JobScheduler
            jobFinished(params, false);
        }).start();
        
        return true; // 返回 true 表示任务正在执行
    }

    @Override
    public boolean onStopJob(JobParameters params) {
        // 系统要求停止任务（比如条件不满足了）
        // 返回 true 表示希望重试
        return true;
    }
}
小提示：onStartJob 返回 true 时，你必须确保在任务完成后调用 jobFinished()。否则系统会认为你的 Job 一直在运行，永远不会释放资源。我曾经因为这个 bug 导致线上出现大量 ANR，排查了好久才发现。

六、什么时候该用 JobScheduler？

我总结了一个简单的判断标准：

  • 必须立即执行 → 用 Service（比如播放音乐、导航）
  • 必须准时执行 → 用 AlarmManager（比如闹钟、日历提醒）
  • 可以延迟执行 → 用 JobScheduler（比如同步、备份、预加载）

说白了，如果你的任务晚几分钟执行也没关系，那就交给 JobScheduler。它会让你的 App 更省电，用户更满意。

嗯，这一章就到这里。JobScheduler 的入门概念、解决的问题、以及和 Service、AlarmManager 的对比，你应该已经清楚了。下一章我们会深入 JobInfo 的各种约束条件，看看怎么精细控制任务的执行时机。

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

← 上一章 📖 返回目录 下一章 →