第2章 后台执行限制回顾：Android 6–14的后台限制演进、WorkManager对比传统Service、JobScheduler变更要点
适用场景
- 开发团队在适配新应用或迁移旧代码时，需要系统理解各Android版本对后台执行的限制差异。
- 测试团队设计后台行为验证用例时，需明确哪些场景已被系统禁止或降级。
- 项目管理者评估技术债务与发布风险，确定最低支持API等级。
前置条件
- 已了解Android应用四大组件（尤其是Service与BroadcastReceiver）。
- 熟悉Android API level概念，能区分targetSdkVersion与compileSdkVersion。
- 拥有Android 6.0（API 23）至14.0（API 34）的真实设备或模拟器用于验证。
操作步骤
- 列出版本关键节点：整理Android 6~14每个大版本中与后台执行相关的变更，重点标记Doze模式、App Standby、后台限制增强、前台服务类型要求。
- 对比执行模型：绘制WorkManager、传统Service、JobScheduler在调度能力、存活保障、省电约束三方面的核心差异。
- 分析JobScheduler变更：记录从API 21引入到API 34期间，JobInfo参数（如setRequiredNetworkType、setPersisted）、作业配额、执行窗口等变更。
- 形成决策矩阵：输出“后台任务技术选型表”，对每种典型业务场景（短时同步、定期轮询、立即执行等）给出推荐方案。
输入输出物
| 输入物 | 输出物 |
|---|---|
| Android SDK版本变更文档、官方兼容性说明 | 《版本限制对比表》（含API等级、影响范围、推荐方案） |
| 现有应用的后台任务清单 | 《后台任务技术迁移决策表》（每项任务标注当前实现与目标方案） |
责任边界
- 开发工程师：负责将旧式后台Service迁移至WorkManager或合理使用JobScheduler，确保在targetSdkVersion更新后不崩溃。
- 测试工程师：在多种Android版本与省电模式下验证后台任务存活与执行预期，记录违反限制的日志。
- 技术经理：审批迁移计划，确保发布时间不因后台限制导致合规问题。
记录材料
记录要点：
- 每项变更所对应的Android版本及官方Issue链接。
- WorkManager版本号与SDK依赖配置（来自build.gradle）。
- JobScheduler作业配额（如最大作业数、最短间隔）在目标设备上的实测值。
异常处理
常见异常场景与处理方案：
- 应用在Doze模式下任务不执行 → 确认任务使用WorkManager的setExpedited或setForeground，或利用JobScheduler的setRequiresCharging(false)但注意配额。
- 迁移后JobScheduler作业被丢弃 → 检查是否申请了
RECEIVE_BOOT_COMPLETED权限，并在Manifest中声明ACTION_BOOT_COMPLETED接收器。 - WorkManager重复调度 → 确保使用
ExistingPeriodicWorkPolicy.KEEP或CANCEL_AND_REENQUEUE正确策略。
验收标准
- 团队成员能口头描述Android 6、8、12、14四个版本对后台执行的具体限制差异。
- 代码库中所有后台定时任务均已替换为WorkManager，并附有单元测试覆盖调度约束分支。
- 在真实设备上（至少运行Android 12与14）通过“省电模式+充电状态+时间流逝”组合，验证后台任务在预期窗口内完成。
- 输出《版本限制与选型决策表》通过技术评审，无未处理的技术债务项。