BGTaskScheduler是苹果在iOS 13和macOS 10.15之后推出的后台任务调度框架，它取代了被标记为废弃的NSBackgroundActivityScheduler，成为macOS应用执行后台工作的推荐方式。很多桌面应用都有类似需求：定期从服务器拉取最新数据、在系统空闲时清理临时文件、对本地数据库做压缩整理等。如果依赖传统的定时器方案，应用一旦退到后台或被挂起，定时器就不再可靠，而BGTaskScheduler把调度权交给操作系统，系统会在合适的时间点唤醒应用执行任务，兼顾了电量、性能与用户体验。本文将从任务类型、配置流程、代码实现和调试技巧几个方面，完整讲解如何在macOS项目中落地这套机制。
一、理解两种任务类型的区别与适用场景
BGTaskScheduler框架下最核心的两个类是BGAppRefreshTask和BGProcessingTask，它们对应两种完全不同的使用场景。简单来说，前者用于短时间的数据刷新，后者用于可能耗时较长的处理工作。
BGAppRefreshTask适合做内容更新，比如新闻类应用拉取最新文章列表、日历类应用同步日程。系统为这类任务分配的执行时间较短，通常在几十秒以内，所以任务内部应该只做轻量级的网络请求。BGProcessingTask则适合做重活，比如图片批量压缩、数据库迁移、日志上传、机器学习模型训练等。它有一个额外的优势：可以通过参数声明任务需要外部电源和网络连接，系统会等到条件满足时才触发，这在小脚本或后台服务型应用中非常实用。
需要注意的是，BGTaskScheduler并不提供精确定时能力。你无法要求系统在每天早上8点准时执行任务，系统会根据用户的 使用习惯、设备状态、电量情况来综合决定调度时机。苹果在设计上刻意模糊了触发时间，开发者能做的是提交请求并设置一个earliestBeginDate，表示任务最早可以执行的时间。这个特性经常让初学者困惑，以为框架不工作，其实是调度机制本身就是启发式的。
二、项目配置：Info.plist与启动注册
使用BGTaskScheduler的第一步是在Info.plist中注册任务标识符。需要添加一个名为BGTaskSchedulerPermittedIdentifiers的数组键，把所有要用到的任务ID写进去。这个ID建议使用反向域名格式，例如com.example.myapp.refresh，且必须与代码中提交请求时使用的字符串完全一致，任何不一致都会导致任务被系统拒绝。
第二步是在应用启动时注册任务处理器。注册必须发生在应用 didFinishLaunching 阶段完成，也就是在applicationDidFinishLaunching方法返回之前，否则系统在尝试唤起任务时找不到对应的handler，会直接终止应用。这一点是硬性要求，很多运行时崩溃都源于注册时机太晚。
import BackgroundTasks
func applicationDidFinishLaunching(_ aNotification: Notification) {
// 注册应用刷新任务
BGTaskScheduler.shared.register(forTaskWithIdentifier: "com.example.myapp.refresh",
using: nil) { task in
self.handleAppRefresh(task: task as! BGAppRefreshTask)
}
// 注册后台处理任务
BGTaskScheduler.shared.register(forTaskWithIdentifier: "com.example.myapp.processing",
using: nil) { task in
self.handleProcessing(task: task as! BGProcessingTask)
}
scheduleAppRefresh()
scheduleProcessingTask()
}注册和调度是两个独立的动作。register只执行一次，告诉系统这个标识符对应的任务由谁来处理；而submit则是在每次任务执行完毕后再次提交，形成持续调度的循环。如果忘记在任务结束时重新提交，任务只会执行一次就不会再触发了。
三、提交任务请求与处理器实现
提交刷新任务使用BGAppRefreshTaskRequest，提交处理任务使用BGProcessingTaskRequest。两者都通过BGTaskScheduler.shared.submit方法发送，调用后可能抛出错误，常见错误码包括任务未注册、标识符不匹配、同类型任务重复提交等，建议用do-catch捕获并打日志。
func scheduleAppRefresh() {
let request = BGAppRefreshTaskRequest(identifier: "com.example.myapp.refresh")
// 15分钟后 earliest 才可能被调度，实际时间由系统决定
request.earliestBeginDate = Date(timeIntervalSinceNow: 15 * 60)
do {
try BGTaskScheduler.shared.submit(request)
} catch {
print("提交刷新任务失败: \(error)")
}
}
func scheduleProcessingTask() {
let request = BGProcessingTaskRequest(identifier: "com.example.myapp.processing")
request.earliestBeginDate = Date(timeIntervalSinceNow: 60 * 60)
request.requiresExternalPower = true // 要求接通电源
request.requiresNetworkConnectivity = true // 要求有网络
do {
try BGTaskScheduler.shared.submit(request)
} catch {
print("提交处理任务失败: \(error)")
}
}处理器实现的关键是正确管理任务的生命周期。系统传入的task对象有一个expirationHandler属性，必须在任务开始时立即设置。当系统决定收回执行时间时，会调用这个handler，你的代码必须在这里尽快保存状态、停止工作并调用task.setTaskCompleted(success:)。如果不设置expirationHandler，或者超时后没有结束任务，系统会直接杀掉应用进程，还会降低该应用后续被调度的优先级。
func handleAppRefresh(task: BGAppRefreshTask) {
// 安排下一次刷新，保证循环继续
scheduleAppRefresh()
// 创建一个后台任务占位，防止线程被挂起
let queue = OperationQueue()
task.expirationHandler = {
queue.cancelAllOperations()
}
queue.addOperation {
let success = self.fetchLatestData()
task.setTaskCompleted(success: success)
}
}一个容易忽略的细节是，expirationHandler运行在哪个队列、能否执行耗时操作。苹果文档明确说明这个handler必须快速返回，所以正确做法是在设置它时就准备好取消信号，让正在进行的工作线程能感知到并尽快收尾，而不是在handler里再去做清理重活。
四、调试技巧与常见坑
由于BGTaskScheduler的触发时机不确定，调试时不能干等系统调度。可以在Xcode中先暂停程序，然后在lldb控制台执行e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateLaunchForIdentifier:@"com.example.myapp.refresh"]来强制触发指定任务。这是苹果工程师在WWDC上公开演示过的私有调试方法，只能在开发阶段使用，上架前不要依赖它。
另外几个常见的坑值得注意。第一，Info.plist中的标识符与代码不一致不会在编译期报错，只会运行时报NSInternalInconsistencyException，务必仔细核对。第二，macOS上如果应用被完全退出（Dock图标被移除），任务将不会被调度，BGTaskScheduler的前提是应用仍处于已安装且未被彻底终止的状态。第三，如果提交时抛出错误码为1的错误，通常是同标识符的上一个任务还挂起未执行，可以先调用BGTaskScheduler.shared.cancel(taskRequestWithIdentifier:)清理后再提交。
最后建议在任务执行路径中加入完善的日志或埋点，把每次任务的实际触发时间、执行时长、成功与否记录下来。因为后台任务的行为在开发机上和用户机器上可能差异很大，只有依赖线上数据才能判断调度频率是否符合预期，进而调整earliestBeginDate的设置策略，在系统允许的范围内获得更稳定的刷新节奏。
BGTaskScheduler后台任务macOS开发修改时间：2026-09-03 01:31:07