异步后台任务、保活、系统能力

模块目标

建立 Android / Flutter / iOS 在后台任务、持续任务、系统调度、保活边界上的现实认知。

本模块要回答的问题

• WorkManager 是什么，不是什么？
• Foreground Service 和 WorkManager 的边界在哪里？
• iOS 后台音频、后台刷新、silent push 的真实边界是什么？
• Flutter 自己能做什么，必须借原生做什么？
• 录音、下载、推送、同步这些任务应该怎么落位？

子主题清单

01. Android 后台任务

• [x] WorkManager / Foreground Service / AlarmManager 对比
• [x] Android 协程短任务模型（已在主文档中对照）
• [x] WorkManager：延迟 / 周期 / 可恢复任务（已并入主文档）
• [x] Foreground Service：持续用户感知任务（已并入主文档）
• [x] AlarmManager：精确定时边界（已并入主文档）
• [x] 推送唤醒 / JobScheduler 基本理解（已并入主文档）
• [x] 电池优化 / 厂商限制 / 后台冻结（已并入主文档）

02. Flutter 后台边界

• [x] Flutter 后台能力边界
• [x] Flutter 自身后台能力边界（已并入主文档）
• [x] 为什么真正后台任务要借原生（已并入主文档）
• [x] compute / isolate 只能解决什么（已并入主文档）
• [x] plugin / channel 调起原生后台任务（已并入主文档）

03. iOS 后台现实

• [x] iOS 后台能力现实边界
• [x] iOS 不存在通用强保活（已并入主文档）
• [x] 音频/定位/下载/silent push 的真实边界（已并入主文档）
• [x] 后台刷新为什么不准点（已并入主文档）

04. 业务落位案例

• [ ] 业务设计如何顺着系统约束走
• [ ] 录音场景的前后台差异
• [ ] 下载/上传/同步场景的正确模型

推荐复习顺序

1. WorkManager / Foreground Service / AlarmManager 对比
2. Flutter 后台能力边界
3. iOS 后台能力现实边界
4. 再用录音 / 下载 / 推送三个场景做交叉对照

对应 labs 入口

建议后续优先补：

• labs/android/background-tasks/
• labs/flutter/background-tasks/
• labs/shared/background-tasks/

备注

本模块应优先结合真实业务样本，例如录音、下载、推送、后台同步与电池优化问题。