完成后台任务

完成后台任务

探索后台任务执行方面的最新进展，并了解系统如何进行运行时调度。我们将讨论如何充分利用后台运行时，让你的 App 既能在后台提供功能，又能保持出色的前台体验。我们还将介绍各种 API 如何为你的 App 提供后台运行时环境，以及每个 API 是怎样针对不同用例量身定制的 — 其中包括 iOS 和 iPadOS 26 中的新 API，这些 API 让你的 App 能够在从前台过渡到后台时顺利完成任务。

章节
- 0:00 - 开场介绍
- 1:22 - 简介
- 2:09 - 行为与限制
- 7:29 - 后台任务 API
- 11:23 - 持续处理任务
资源
大家好我叫 Ryan 是 Apple 的软件工程师今天我想聊聊 App 如何利用后台运行时
App Store 汇聚了数以百万计的 App 每一款都有自己的独特之处当你的 App 位于前台时它往往能展现出最耀眼的一面你可以完全掌控每一个像素打造令用户难忘的体验
用户也期待开发者能带来这样的 App 快速、实用且精心设计但是当 App 切换到后台时会发生什么呢？
在这个讲座中我将探讨后台运行时以及如何为 App 构建一个高效且表现良好的工具包这不仅是为了保持 App 的正常运行更重要的是发挥作用比如进行数据预取、同步和上传为 App 的下次启动做好准备合理运用后台运行时能让你的 App 显得快速、流畅甚至带点魔力
我会先简要概述前台和后台的实际定义并分享一些关于系统如何决定 App 在后台运行的时机和频率的原则
然后我将介绍多种现有的实现方法包括一个用于延续前台已启动任务的新 API
每一个处于前台的 App 都遵循相同的节奏
App 本身和它需要的一切包括框架、资产等都会载入到内存中在这种状态下 App 的界面是设备的焦点这时 App 处于前台状态
当用户离开 App 但进程仍在运行 App 就进入了后台默认情况下后台 App 处于暂停状态不会获得 CPU 时间这既能维持电池续航、保护隐私又能为前台 App 释放资源
在某些情况下 App 可以请求后台时间以便在暂停前完成正在进行的工作当用户通过 App 切换器返回你的 App 时系统会将它恢复到前台状态
在使用后台运行时之前你应该了解系统如何优先分配和管理资源以及你可以在 App 中做些什么来打造最佳体验
系统的主要目标很明确：维持电池续航、优化性能同时保持流畅且响应迅速的用户体验这意味着后台执行不是必然保证的而是伺机的通常由系统酌情决定并且受到严格管理成功的工作负载需要理解这一背景并与系统协同工作而不是与系统对抗
最根本的限制是能耗
每一项操作无论是 CPU 周期、 GPU 渲染、网络请求甚至是神经网络引擎的使用都会消耗电池电量电池续航是一种有限的资源为了维持电池续航系统会在设备唤醒时合并任务从而减少不必要的后台活动这项工作全天持续进行由于后台运行时间有限请将 App 在后台执行的任务视为独立的、定制化的任务每个任务高效地完成一件事并始终关注系统的优先级和约束这些后台工作反映在“电池设置”中用户可以从中了解哪些 App 对电池续航时间影响较大 iOS 26 为设备的电池性能提供了更深入的洞察会按 App 给出详细的耗电分析
你最明智的做法是提高效率如果一个任务不需要立即运行可以考虑推迟到设备充电时再执行如果确实需要运行也要保持轻量级且目标明确
除了电池系统还负责管理其他共享资源比如内存、CPU 时间和网络带宽当用户使用设备时前台 App 会被优先考虑如果后台 App 消耗过多内存或 CPU 它不仅效率低下还会与前台体验产生竞争这时系统可能会介入限制、暂停、甚至终止资源消耗过大的进程
核心要点很简单尽量减少后台工作量避免臃肿的工作优先使用批处理以最大限度地减少内存占用
即使工作负载表现良好也不能保证它们会被允许长时间运行后台工作队列永远不会为空因此系统可能会选择优先处理其他工作负载话虽如此我们都在协同工作系统是在尽其所能地优化前台体验
你的工作负载必须具有弹性尽早且频繁地保存增量进度及时响应到期信号并相信系统很快就会恢复你的工作负载系统欣赏合作型的进程并会利用这些行为来影响未来的调度但归根结底使用设备的人拥有最终决定权用户通过切换设置来影响调度例如切换到低功耗模式、后台 App 刷新和低数据模式等系统提供了透明度让用户能够自主做出这些决策例如如果你的 App 在后台消耗过多电量用户可能会采取行动而这未必对你有利
因此后台工作应该适度、保持轻量级并尊重用户偏好同时确保你的影响与你提供的价值成正比即使系统中的每个进程都完全遵循这些原则它们仍然运行在一个复杂且高度动态的环境中
网络可用性、CPU 负载、设备活动、散热状态和电池电量等因素都会作为参考信息影响调度决策
幸运的是系统会考虑这些具有挑战性的条件始终打造最佳体验这意味着即使是精心设计的任务如果条件不合适也可能会被推迟以实现全局优化保持适应性至关重要保持工作的原子化和轻量级同时清晰地表明你的需求将工作负载设计成能够从中断处继续执行以便在运行时机会出现时逐步推进你对系统条件和优先级的了解和适应程度越高你的工作负载就会越成功
高效、精简、弹性、适度和适应性强这些是构建与平台无缝契合的后台工作的关键要点在开发过程中你可以问自己几个关键问题
谁发起了这个任务？这项工作是明确启动的还是可酌情决定在稍后运行的？
这项工作需要多长时间？尝试将任务分为短、中、长三种持续时间这项工作对 App 状态和新鲜度是否至关重要？后台下载可以增强 App 的活跃度但遥测上传对设备用户没有直接好处最后这项工作是否需要用户同意或输入？
后台运行时不适用于这些类型的工作负载因此如果是这种情况我建议采取其他方法有了这个基础让我们来探索如何有效地设计任务 iOS 提供了许多不同的 API 可让你请求后台运行时并且每个 API 都具有不同的类型或描述文件具体取决于工作的支持这使系统能够根据我之前提到的约束和条件调整 App 的运行时例如用户期望自己最常用的 App 始终拥有最新、最棒的内容系统理应了解 App 使用模式从而优化后台任务和支持
第一个 API BGAppRefreshTask 就是这种情况
利用这个 API App 可以在正准备使用内容前从服务器静默获取内容同时完全遵循适度原则系统会将这些任务与 App 使用历史记录相匹配常用 App 被调度的几率更高从而保证每次启动时都获得新鲜内容
要在 SwiftUI 中创建 App 刷新任务请将 BackgroundTask 修饰符添加到场景中当系统在后台唤醒 App 时它将调用这个闭包并在闭包返回时暂停 App
虽然刷新任务涵盖了基于获取的用例你可能还需要维护不频繁或不定期更新的远程文档后台推送通知提供了一个巧妙的解决方案当你的服务器发送有关新内容的通知时系统会在适当的时间唤醒你的 App 以获取新内容请注意这与 App 刷新的情况不同在这里更新被推送到设备而不是设备适时主动获取数据
由于后台推送通知用于指示新的远程内容它们始终被视为是酌情进行的
它们还会以低优先级发送并合并以最大限度地降低开销和功耗
当用户从 App 切换器中移除你的 App 时系统会尊重用户的意图直到 App 再次启动通知才会传递给 App
不过有时你可能希望 App 执行其他类型的工作也许你想在生成的数据上运行机器学习模型或者只是处理数据库维护
BGProcessingTask API 可以帮助你实现这些任务
注册这个任务非常简单只需要任务标识符、回调队列和一个在运行时调用的闭包
你必须在启动期间立即注册 BackgroundTasks 这样如果任务在后台启动系统就会及时知晓并立即调用它的处理程序处理任务还支持其他配置遵循我之前介绍的原则例如如果工作对延迟不是特别敏感一项好的任务可能会选择仅在设备充电并连接到网络时运行这可以最大限度地减少对电池的影响从而降低 App 在电池设置中显示的耗电量到目前为止我已经介绍了一些 API 它们可以让 App 为在后台启动的任务获取运行时但有时你可能只是想在切换到后台时多一点时间继续运行 beginBackgroundTask API 和 endBackgroundTask API 允许 App 完成那些如果被中断而未完成继而可能无法恢复的工作
以一个简单的状态保存为例根据工作的不同提前终止可能会导致糟糕的体验
将代码包装在这些 API 调用中会通知系统 App 正在处理不应中断的关键工作这个 API 非常适合清理文件句柄或关闭数据库连接等场景
iOS 上的后台支持范围很广旨在处理各种各样的任务包括用户启动的任务确保这些用户发起的操作可靠地完成对于良好的体验至关重要在 iPadOS 和 iOS 26 中 BGContinuedProcessingTask 为 App 提供了一种支持这些功能的方法这个任务允许你在 App 进入后台后仍继续工作系统会提供 UI 来传达进度以“手记”App 为例它使用持续处理任务在后台驱动导出并向发起者显示进度更新任务完成后系统会短暂更新然后自动关闭 UI 用户始终具有控制权他们可以查看任务进度并随时取消工作因此这可以实现复杂的功能
持续处理任务总是始于用户在 App 中执行的明确操作例如轻点按钮或手势每个任务都代表用户希望 App 执行的一个明确且即时的目标例如导出文件、发布社交媒体内容或完成已连接配件的更新这些任务会取得可衡量的进展并且用户很容易理解任务完成的意义
用户不期望任务自动启动即使他们之前在 App 中设置过偏好避免自动执行工作负载比如维护、备份或照片同步如果任务在没有明确操作的情况下启动用户可能无法理解任务的目标或任务进度的真正含义执行这种意外的工作可能会导致 App 的任务被取消对于这些需求可以考虑其他更合适的 API
有了这些考虑采用持续处理任务就变得轻而易举首先在 Info.plist 中添加任务标识符你将使用它来注册一个启动处理程序用于管理状态和报告进度然后只需在出现提示时提交任务请求即可让我们从标识符开始要定义标识符在 Info.plist 中的允许的后台任务计划程序标识符数组中添加一个新值并确保它的前缀是 App 的套装 ID
除了静态标识符持续处理任务还支持带有动态后缀的新通配符表示法
通配符标识符始终以套装 ID 开头后跟一些语义上下文这里新的组成部分是点星号表示在注册和提交时将在标识符后附加一个动态后缀
用于注册和提交的完整组合标识符具有这样的形式
现在让我们先使用更静态的标识符
选择标识符后调度程序需要知道当持续处理任务被要求运行时要执行什么代码和之前一样提交任务请求后会调用提供给调度程序的闭包但这里有一个关键的转变启动处理程序不需要在 App 完成启动前注册现在你可以在表达使用意图时动态注册这些处理程序
就像在“手记”App 中一样必须及时更新工作负载的进度如果进度比预期慢系统将提示发起者询问是否希望工作继续进行系统依靠这些进度更新来管理正在进行的工作因此不报告任何进度的任务将会过期以便系统回收并重新分配资源 App 会使用进度报告协议主动传达这些更新与此同时系统会持续监控更新并在 UI 中显示进度现在我们仍然需要注意如果条件发生变化系统可能需要提前停止任务为了处理这种情况任务必须提供一个到期处理程序当任务需要停止时它将被调用可以将这个处理程序视为快速翻转变量的机会以便任务能够优雅地停止并避免做额外的工作
至关重要的是当任务完成它的工作时你必须调用 setTaskCompleted 这会告诉系统你已经完成好的我已经介绍了如何管理进度更新、处理潜在的中断以及发出运行中任务的完成信号现在让我们通过构建和提交一个有效的、用户发起的任务请求来整合这些内容
首先初始化一个任务请求对象这需要三部分信息与 Info.plist 中的标识符匹配的标识符、本地化的标题和本地化的副标题这些是用户在系统 UI 中看到的内容
接下来你需要提供提交策略供系统遵守默认情况下如果系统发现自己无法立即运行持续处理任务它会将这个任务添加到队列的末尾你不需要指定任何额外内容然而有时排队并不是正确的方法如果任务只有立即启动才有意义呢？与其让它排队你可以告诉系统如果不能立即启动就让提交失败这会给 App 提供即时反馈让你能够妥善处理这种情况
一旦你决定了策略并配置了请求只需提交给调度程序让系统管理工作负载这就是使用持续处理任务的核心流程通过提供标题和副标题并考虑提交策略你可以与系统顺畅集成同时遵守关键的同意原则这个 API 提供的功能比表面上看到的更多在 iPadOS 和 iOS 26 中持续处理任务还可以受益于受支持设备上的后台 GPU 访问
要利用这一点请确保在 Xcode 项目设置中添加后台 GPU 功能
添加后你可以并且应该动态查询调度程序的 supportedResources 属性这样 App 就可以准确地了解当前设备在运行时支持什么资源以便你可以相应地调整任务需求这项检查非常重要系统会强制执行这些要求任何对不可用资源的请求在提交时都会被拒绝以保持系统和任务处于健康、已知的状态
最后请记住系统优先级的更广泛背景 iOS 优先考虑前台体验这意味着后台任务获得的服务质量可能会低于 App 处于活动状态时的服务质量但是系统会智能地处理这种情况当 App 返回前台时它会智能地提高任务优先级以确保运行顺畅且响应迅速这些新 API 实现了迄今为止最强大、最流畅的后台执行功能将重要的 BGContinuedProcessingTask 添加到你的工具包中在全面了解这些任务以及它们如何融入更广泛的系统后你就可以开始采用它们了我们期待看到大家使用这些工具来打造更智能、更高效的后台体验感谢观看！

import BackgroundTasks
import SwiftUI

@main
struct ColorFeed: App {
    var body: some Scene {
        WindowGroup {
            // ...
        }
        .backgroundTask(.appRefresh("com.colorfeed.wwdc25.appRefresh")) {
            await self.handleAppRefreshTask()
        }
    }
}

9:45 - Register a processing task

import BackgroundTasks
import UIKit

class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        BGTaskScheduler.shared.register(
            forTaskWithIdentifier: "com.example.apple-samplecode.ColorFeed.db_cleaning",
            using: nil
        ) { task in
            self.handleAppRefresh(task: task as! BGProcessingTask)
        }
    }

    func submitProcessingTaskRequest() {
        let request = BGProcessingTaskRequest(
            identifier: "com.example.apple-samplecode.ColorFeed.db_cleaning"
        )
        request.requiresNetworkConnectivity = true
        request.requiresExternalPower = true

        BGTaskScheduler.shared.submit(request)! 
    }
}

10:51 - Begin and end background task

import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    var backgroundTaskID: UIBackgroundTaskIdentifier = .invalid
   
    func saveState() { /*  ... */ }

    func handlePersistence() {
        let app = UIApplication.shared
        guard backgroundTaskID != .invalid else { return }
        backgroundTaskID = app.beginBackgroundTask(withName: "Finish Export") {
            app.endBackgroundTask(self.backgroundTaskID)
            self.backgroundTaskID = .invalid
        }

        self.saveState()

        app.endBackgroundTask(backgroundTaskID)
        backgroundTaskID = .invalid
    }
}

14:00 - Continued processing task registration

import BackgroundTasks

func handleDialogConfirmation() {
    BGTaskScheduler.shared.register("com.colorfeed.wwdc25.userTask") { task in
        let task = task as! BGContinuedProcessingTask
                                                                      
        var shouldContinue = true
        task.expirationHandler = {
            shouldContinue = false
        }

        task.progress.totalUnitCount = 100
        task.progress.completedUnitCount = 0

        while shouldContinue {
            // Do some work
            task.progress.completedUnitCount += 1
        }

        task.setTaskCompleted(success: true)
    }
}

15:47 - Continued processing task submission

import BackgroundTasks

func submitContinuedProcessingTaskRequest() {
    let request = BGContinuedProcessingTaskRequest(
        identifier: "com.colorfeed.wwdc25.userTask",
        title: "A succinct title",
        subtitle: "A useful and informative subtitle"
    )

    request.strategy = .fail

    BGTaskScheduler.shared.submit(request)!
}

- 0:00 - 开场介绍
- 了解如何使用后台运行时在 App 中执行数据预取和同步等任务。
- 1:22 - 简介
- App 会载入到内存中，然后移到前台，成为设备的主要焦点。当用户离开某个 App 时，这个 App 会进入后台，系统会将它暂停以节省电池电量和资源。App 可以请求一小段时间来完成任务。用户回到这个 App 后，它就会回到前台。
- 2:09 - 行为与限制
- 在 iOS 和 iPadOS 中，后台运行时受到严格管理，以优先延长电池续航并优化性能。后台执行会“伺机而动”，由系统酌情决定，其中耗电是最根本的制约因素。应将 App 的后台任务设计为高效、轻量级且目标明确。系统会合并任务，并可能限制、暂停甚至终止消耗过多资源的进程。尽量减少后台工作，将非必要的任务推迟到充电时再处理，并确保任务精简、独立且具有弹性。App 占用的资源应适度，应尊重用户偏好和系统状况。系统会给用户提供透明度，使他们能够影响调度决策。后台工作负载成功与否，取决于这些工作负载的适应性如何，以及是否与系统优先级一致。
- 7:29 - 后台任务 API
- iOS 和 iPadOS 提供了多个 API，用于设计在后台运行的任务。系统会根据 App 使用模式和设备限制来优化这些任务。 “BGAppRefreshTask”允许 App 在使用前静默获取内容，常用 App 的调度会更频繁。当服务器发送通知时，“后台推送通知”会唤醒 App 以获取新内容，但这些任务由系统酌情执行，优先级低，以充分减少开销。 “BGProcessingTask”使 App 能够执行更复杂的工作，例如运行机器学习模型或数据库维护。这个任务需要在启动期间注册，并且可以将它配置为仅在设备充电并连接到网络时才运行。 beginBackgroundTask API 和 endBackgroundTask API 为 App 提供额外的时间来完成关键工作，例如在转换到后台时保存状态或断开连接。
- 11:23 - 持续处理任务
- iPadOS 和 iOS 26 中新增了“BGContinuedProcessingTask”API，它让 App 即使在后台运行，也能完成用户从前台开始的任务。这个功能使 App 无需打开即可完成复杂的任务，从而增强了用户体验。例如，“手记”App 就使用这个 API 在后台导出文件。用户轻点按钮即可操作导出，然后 App 会通过系统 UI 提供进度更新。用户可以随时监控进度并取消任务，保持完全的控制权。这些任务总是从一项明确的操作开始，例如轻点按钮或手势。它们代表了明确而紧迫的目标，例如导出文件、发布社交媒体内容或更新连接的配件。系统期望这些任务取得可衡量的进展。你需要注册启动处理程序来管理状态和进度报告。使用进度报告协议及时提供有关工作负载进度的更新。如果任务进度慢于预期，系统会提示用户决定是否继续。任务完成后，需要使用“setTaskCompleted”方法通知系统。此外，App 必须提供到期处理程序来从容应对可能发生的中断。此外，这个 API 还支持在受支持的设备上进行后台图形处理器访问，让后台体验更强大、更高效。但请记住，iOS 会优先保障前台体验，后台任务的服务质量可能较低。尽管如此，当 App 返回前台时，系统会智能地提高任务优先级。

章节

资源