Appearance
workmanager-foregroundservice-demo
1. 实验目标
用最小 Android 实现验证后台任务三层选型(对应 docs/03-background-tasks/):
- WorkManager:延迟、约束感知、可恢复的后台任务 → 观察任务状态流转
ENQUEUED → RUNNING → SUCCEEDED/FAILED/RETRY - Foreground Service:持续用户感知任务 → 观察常驻通知的出现与消失
- 对照结论:普通后台任务用 WorkManager,持续可见任务才用 FGS,精确定时再看 AlarmManager
2. 工程要点
SyncWorker(CoroutineWorker):模拟网络同步,约 30% 概率失败触发Result.retry()退避重试- 任务配置:
setInitialDelay(5s)+Constraints(需要联网)+BackoffPolicy.EXPONENTIAL(30s) DemoForegroundService:startForeground绑定常驻通知;Manifest 声明foregroundServiceType="dataSync"(Android 14+ 强制)- 日志区实时打印
WorkInfo.State变化,便于观察"约束满足后系统才调度执行"
3. 运行方式
bash
cd labs/android/host
./gradlew installDebug在设备/模拟器中打开 Android Host,进入 打开 WorkManager / 前台服务实验室。
Android 13+ 需先允许通知权限(POST_NOTIFICATIONS),否则 FGS 通知不可见。
4. 预期现象
- 点击"提交 WorkManager 任务":日志依次出现
ENQUEUED 等待约束满足→(约 5 秒后)RUNNING 执行中→SUCCEEDED(或偶发FAILED,取决于模拟的 30% 失败率) - 点击"启动 FGS":通知栏立即出现常驻通知(不可滑动移除)
- 点击"停止 FGS":通知消失,服务停止
5. 常见误区
| 误区 | 实际情况 |
|---|---|
| WorkManager 提交后立即执行 | 需要等约束满足 + 系统调度,可能延迟 |
| 用 FGS 做普通同步任务 | FGS 要求常驻通知、用户可见,滥用会被系统策略收紧 |
| FGS 不需要通知 | Android 规定前台服务必须绑定通知,否则抛异常 |
6. 对应知识库文档
- 理论主文档:WorkManager / ForegroundService / AlarmManager 对比
- FGS 深挖:Android Foreground Service 深挖(服务类型、通知约束与高版本后台限制)