Appearance
ios-background-boundary-sim
Swift Playground 版：单文件 Swift，macOS 直接
swift BackgroundBoundarySim.swift运行，Foundation 层状态机模拟 iOS 后台能力边界。
1. 实验目标与工程要点
- 用状态机复现 iOS App 生命周期
active → background → suspended → terminated的关键边界。 - 验证 beginBackgroundTask 过期窗口：约 30s 的机会窗（模拟固定预算），窗口内收尾存活、超时被系统掐断。
- 验证两条「被杀路径」：后台任务超期 expired → terminated；suspended 进程遇内存压力无回调地被杀。
- 工程落点：iOS 后台是机会型能力——短小收尾可用窗口，长期/准点/常驻任务必须改模型（服务端兜底），不是代码写法问题。
2. 深入原理与生活浅显比喻
2.1 生活浅显比喻
iOS 后台像图书馆闭馆前的 30 分钟清场广播：管理员（系统）允许你把摊子收拾一下（beginBackgroundTask），但时间一到直接熄灯赶人；平时闭馆后你的东西可以留在柜子里（suspended，进程驻留内存），但馆方大扫除（内存压力）时会不经通知直接清走。
2.2 底层原理分析
iOS 无通用强后台：退后台后若未申请后台任务/模式，很快进入 suspended（进程在、代码不执行）；beginBackgroundTask 只是向系统申请一段有限过期预算（经验值 ~30s，真实时长由系统依电量/负载决定，非承诺）。BGTaskScheduler / silent push 均为机会型触发。对照 Android：Foreground Service 用户可感知可常驻，WorkManager 系统延迟调度但保证最终执行——模型完全不同。
2.3 方案对比矩阵
| 方案 | 通俗比喻 | 底层原理 | 保证特性 | 吞吐性能 | 运行开销 | 适用场景 |
|---|---|---|---|---|---|---|
| iOS beginBackgroundTask | 闭馆前 30 分钟清场广播 | 有限过期窗口，超时系统掐断 | 仅短小收尾有短暂保证 | 低（秒级窗口） | 极低，受电量优先策略约束 | 落盘、补发一次同步请求等收尾 |
| iOS BGTask / silent push | 有空就帮你捎个信 | 系统机会型调度 | 不准点、不保证到达 | 低 | 低 | 可延迟的数据刷新、远程触发辅助 |
| Android Foreground Service | 自己租了间常驻办公室 | 用户可感知通知换取持续执行 | 持续运行（受厂商管控差异） | 高 | 常驻通知 + 电量成本 | 导航、录音、播放等持续任务 |
3. 移动端实战场景与误配事故
3.1 实战场景
- 「每 X 分钟后台检查一次」的需求：Android 心智下会找 WorkManager/alarm；iOS 上应反向推动产品改成前台刷新 + 机会窗补齐 + 服务端兜底。
- Flutter 插件层无法补平宿主授权差异：isolate 再多也拿不到 iOS 后台执行窗口。
3.2 常见误配与事故注意事项
- 把 silent push 当稳定闹钟：受系统策略/网络/设备状态影响，经常不来或漂移。
- 在 beginBackgroundTask 里塞长同步任务：超期被掐断且无提示，数据停在中间态。
- 以为 suspended = 保活：内存压力下随时被杀，且不会收到任何回调。
3.3 排障思路
线上「后台任务偶发不执行」先分三层：是否根本没拿到窗口（没进白名单模式）？拿到但超期（任务太大）？进程已被杀（需服务端兜底）？用日志打点 state 流转即可定位到层。
4. 实验源码与运行验证
关键源码
- BackgroundBoundarySim.swift ——
AppLifecycleSim状态机（1 tick = 10s）：场景1 窗口内收尾→ suspended→ 复活 active；场景2 累计 40s > 30s 预算 → EXPIRED → terminated；场景3 未申请任务 + 内存压力杀进程。
关键参数 / 开关
backgroundBudgetSeconds = 30：过期窗口预算（真机为系统决定的经验值，非承诺）。enterBackground(beginTask:)：是否申请后台任务，决定退后台后还有没有执行窗口。doWork(seconds:)：消耗窗口预算；suspended/terminated 状态下一律拒绝执行。
运行方式
bash
cd labs/swift-playground/ios-background-boundary-sim
swift BackgroundBoundarySim.swift # 直接运行演示
./verify.sh # 运行 + 断言校验预期控制台运行输出（节选）
text
[BG] [app-A] t+20s endBackgroundTask：任务在窗口内主动结束
[BG] [app-B] t+40s [EXPIRED] 后台任务超过过期窗口 -> 系统掐断任务，state=suspended
[BG] [app-B] 最终状态：terminated，完成后台工作 40s，超期被杀？true
[BG] [app-C] t+0s doWork(10s) 被拒绝：当前 state=suspended，suspended 后代码不再执行
PASS: 全部检查通过断言脚本说明
verify.sh 校验三点：① Swift 内置 3 项自检全部 PASS；② 场景1 全程无 terminated 且回前台恢复 active；③ 场景2 出现 [EXPIRED] 且终态 terminated、场景3 出现 doWork 被拒与内存压力致死。任一失败退出码为 1。
5. 对应知识库文档
- 理论主文档：iOS 后台能力现实边界
复习检查题
为什么说 beginBackgroundTask 的 30s 是「机会窗」而不是承诺？
答：真实时长由系统按电量、负载、用户习惯动态决定，30s 只是经验值；demo 里把它固定成预算是为了让边界行为可断言。
suspended 和 terminated 的本质区别是什么？
答：suspended 进程还驻留内存（回前台可快速复活）但任何代码不再执行；terminated 进程已死。两者共同点是：都不会再执行你的代码。
demo 场景2 对应 docs 页说的哪句话？
答：「很多团队在 iOS 上不是技术不会写，而是目标设错了」——想靠过期窗口做长期后台同步，超期被掐断是必然结果，正确修法是把强时效任务交给服务端。