LESSON 34 / 575 分钟
通知、后台任务与 Live Activities
系统决定 App 何时有机会执行。不同需求要选择不同机制。
用你的前端经验理解
不要把 setInterval 或常驻服务直接搬到后台；通知、任务调度和持续活动各有独立的系统契约。
01 / 理解问题
为什么需要它
通知、后台任务与 Live Activities 解决不同问题。通知把重要事件送到用户面前，后台任务给系统调度的有限执行机会，Live Activities 展示正在进行活动的状态。它们不能组合成“应用关闭后仍任意常驻运行”的承诺，产品需求必须先接受系统调度的不确定性。
它是怎样工作的
本地通知适合已知时间的提醒，远程通知来自服务端事件。后台刷新执行时间由系统决定，不宜用于精确闹钟或持续轮询；Live Activities 的更新与持续时间也受系统规则限制。计划改变或事项删除后，需要撤销旧通知，防止数据已经更新而提醒仍使用旧内容。
02 / 掌握要点
把关键概念连起来
1
通知
本地通知由设备调度；远程通知通常由服务端经 APNs 推送。请求授权，处理前台展示与点击路由。
2
后台
BGTaskScheduler 由系统择机执行，不能保证精确时间。静默推送也不保证即时执行。
3
实时活动
ActivityKit 适合展示正在进行的任务状态，受平台与生命周期限制，不是无限后台运行通道。
03 / 案例推演
为待办事项安排提醒
- 保存事项后为提醒生成稳定标识，授权允许时提交本地通知请求，并记录与事项的关联。
- 修改时间时替换对应请求，删除时取消；不要每次进入详情都新建一个随机 ID 的通知。
- 用户点击通知进入 App 时重新查找事项；它可能已经完成或删除，应展示合理状态。
这里需要你亲自判断
“每分钟后台请求一次接口”不是通用可行方案；提醒时刻可优先考虑合适的本地通知。
04 / 动手验证
做一个小练习
为一个倒计时工具选择通知与状态恢复方式，解释为什么不依赖后台秒级计时器。
- 为同一事项连续改三次时间，确认只保留最后一个有效提醒。
- 关闭通知权限，保证事项仍能保存，并清楚提示提醒未开启。
展开参考思路与验收标准
业务保存与提醒安排是两步独立结果。精确到时的体验应使用对应系统能力，不能用后台任务每分钟检查一次来模拟系统闹钟。
05 / 检查理解
BGTaskScheduler 能保证每天 9:00 准时执行代码吗？
答对理解题后即可标记完成