Chapter 145: Background Execution Policy

后台执行（Background Execution）是移动 OS 对应用离开可见界面后继续使用 CPU、网络、定位、蓝牙、音频、通知等资源的策略分配。读完本章后，读者应能定位一个后台任务经过哪些系统边界，判断它属于实时任务、可延迟任务、可恢复任务还是用户可见长期任务，并据此选择合适的执行模型。

本章用一个导航 App 作为贯穿材料：用户在前台输入目的地并开始导航，随后锁屏或切到别的 App。导航 App 仍然希望接收定位、播放语音播报、保持蓝牙音频输出、上传少量路况、在路线变化时通知用户。这个行为表面上像“App 还在运行”，系统视角却是多个受控授权叠加：定位有隐私边界，音频有焦点和路由边界，网络有电源策略边界，通知占用用户注意力，CPU 时间受调度窗口限制。

Android 和 Apple 平台都把后台执行收束到少量受认可的路径。Android 公开文档把后台任务放入异步工作、任务调度 API 和 foreground service 等类别，并说明后台状态会触发系统限制；相关入口可见于 Android Background tasks overview、Foreground services overview 和 Doze and App Standby。Apple 公开文档把后台能力组织在生命周期、BackgroundTasks、background modes、background URLSession 和 remote notification 等入口中；相关入口可见于 BackgroundTasks、Choosing Background Strategies for Your App 和 background URLSession。Apple 平台的具体调度器实现属于系统内部，本章只使用公开行为和可观察边界。

后台执行的核心结论是：应用离开前台后，执行权从 App 自己的线程模型转移到系统策略模型。开发者仍然提交任务、声明用途、提供约束和处理回调，真正决定何时运行、运行多久、能用哪些硬件能力、失败后如何恢复的是系统服务、生命周期管理、电源策略、隐私授权和用户设置共同形成的控制面。

145.1 Background Execution 作为系统授权资源

后台执行首先是一组授权资源，而非普通线程继续运行。前台 Activity、ViewController 或页面仍然可见时，App 可以把计算放到异步线程、协程、队列或回调中；页面离开可见状态后，CPU 时间、网络连接、定位采样、蓝牙扫描、音频播放、相机使用和通知展示都进入系统策略分配。这个转变让后台执行从“代码是否还活着”变成“系统是否继续授予某种能力”。

导航 App 的后台导航路径可以拆成多项授权。定位需要持续位置权限和后台位置策略；语音播报需要音频会话、音频焦点或路由策略；蓝牙耳机输出依赖系统音频路由和连接状态；路线重算需要短时间 CPU 和网络；路线偏离提醒需要通知权限和展示策略。每一项都可能单独成功、延迟、降级或失败，所以后台执行问题不能归结为一个进程是否被杀。

移动 OS 使用这种授权模型有三个直接原因。第一，电池容量和散热空间受限，后台 CPU、modem、GNSS、Wi-Fi、Bluetooth 和屏幕唤醒会共同改变续航曲线。第二，传感器在后台工作时会产生隐私暴露，系统需要把位置、麦克风、相机、蓝牙扫描等能力放到用户授权和可见提示下。第三，用户注意力也属于系统资源，通知、前台服务通知、锁屏提醒和声音提示都需要由系统集中管理。

后台执行的责任链可以用一条路径表示：App 提交后台意图，Framework API 记录任务类型和约束，系统服务检查身份、权限、生命周期和电源状态，调度器在合适窗口分配 CPU、网络或传感器访问，最终通过回调、通知或失败状态返回给 App。这个路径中，App 负责声明“我要做什么”和“失败后如何恢复”；系统负责判断“现在是否允许做”和“可以占用多少预算”。

下图把导航 App 的后台路径压缩成一个跨层决策图。图中每个节点都对应后文某个判断点，重点是执行资格从 App 代码外移到系统控制面。

这个图也说明了后台问题的排查顺序。先确认 App 提交的任务类型，再确认权限和生命周期状态，随后看系统电源策略和调度窗口，最后分析用户可见结果。把顺序反过来会导致误判，例如只看到网络请求延迟便归因于服务器，可能忽略 Doze、低电量、后台刷新关闭或系统窗口尚未到达。

145.2 App Visibility 与后台执行资格

App 可见性是后台执行资格的第一层输入。移动 OS 会区分前台可见、前台服务或用户可见长期任务、最近使用、后台挂起、缓存进程、被限制应用等状态。可见性越强，系统越容易把任务视为用户当前意图的一部分；可见性越弱，系统越倾向于延迟、批处理或停止任务。

Android 语境中，一个应用没有可见 Activity 且没有 foreground service 时，系统会把它视为后台运行，并施加后台限制。foreground service 的语义是“用户能感知到的长期任务”：它通过状态栏通知向用户暴露资源消耗和停止入口，并要求声明合适的服务类型。导航、媒体播放、通话、用户主动上传下载等场景更容易满足这种语义；普通内容刷新、埋点上传、缓存清理应交给任务调度器。

Apple 语境中，应用进入后台后通常会被挂起，系统保留内存状态并暂停普通代码执行。获得继续执行资格的路径包括短时间任务完成、系统批准的 background modes、BGTaskScheduler、background URLSession、remote notification 唤醒等。音频、位置、蓝牙、VoIP 类场景有明确用途声明和系统策略；普通刷新和处理任务通常由系统选择窗口执行。

导航 App 切到后台后能继续工作的原因不是“它刚刚打开过”，而是它的任务和用户当前意图仍然可解释：用户已经开始导航，位置变化会影响路线，语音播报直接服务当前行程，锁屏后的提醒有明确用户收益。相同 App 在后台静默上传历史轨迹时，系统会把它放入更严格的网络、定位和隐私审查路径，因为这个行为和用户当前可见任务的关系变弱。

可见性判断还要纳入用户主动操作。用户刚点击“上传 2GB 视频”后切到后台，系统可以把它视为用户发起的数据传输；定时同步旧草稿则更适合进入可延迟任务。用户正在听播客时锁屏，音频播放有持续用户感知；页面离开后继续录音或采集摄像头画面，则需要更强权限、提示和平台批准用途。

工程上应把后台执行资格集中写入任务建模，并让线程和回调服从这个任务模型。每个任务至少记录四个字段：触发来源、用户可见性、资源需求和可恢复状态。触发来源说明任务由用户动作、系统事件、推送、定时器还是内部状态触发；用户可见性说明是否需要通知、播放、导航或通话界面；资源需求说明 CPU、网络、定位、蓝牙、音频、相机等能力；可恢复状态说明任务被延迟或终止后如何继续。

145.3 Foreground Service、Background Task、Push、Alarm、Job 的角色区分

后台执行 API 的选择应从任务语义出发。Foreground Service、Background Task、Push、Alarm、Job 这些名词属于不同调度角色：有的代表用户可见长期执行，有的代表系统托管延迟执行，有的代表服务器到设备的唤醒信号，有的代表时间触发，有的代表约束化批处理。把它们当作互相替代的“后台保活手段”会直接破坏系统策略。

Foreground Service 适合用户能感知且中断会破坏当前体验的任务。导航、媒体播放、通话、实时运动记录、用户主动的大文件传输属于典型例子。它的系统代价是高可见性和高审查：系统要求通知、服务类型、权限和启动条件，用户可以看到任务正在占用资源。Foreground Service 的价值在于把长期资源消耗暴露给用户，并让任意后台代码的永久运行诉求接受系统审查。

Background Task 适合由系统安排窗口的工作。Android 中 WorkManager 和 JobScheduler 常用于持久化、约束化、可重试的工作；Apple 中 BGTaskScheduler 用于后台刷新和后台处理。系统可以根据充电、Wi-Fi、空闲、低电量、App 近期使用、温控状态等条件安排执行。任务设计重点是幂等、可分片、可恢复和能表达约束。

Push 是从服务器触发设备侧响应的通道。它的主要作用是传递用户相关事件或状态变化，例如新消息、订单状态、通话邀请或需要展示给用户的提醒。高优先级或静默推送受平台预算、用户设置和系统状态约束；它适合把“有新事发生”传给设备，随后由系统决定是否唤醒 App、是否展示通知、是否给予短时间后台处理。

Alarm 是时间语义更强的触发器。闹钟、日程提醒、药物提醒、倒计时结束等任务需要在接近指定时间提醒用户；内容同步、日志上传、缓存整理这类任务通常可以进入批处理窗口。Android 在 Doze 中会推迟普通 Alarm 到维护窗口，精确 Alarm 和闹钟类 Alarm 有更严格的用途边界；Apple 侧更多通过通知、后台任务窗口和系统提醒模型表达类似需求。

Job 是约束化执行单元。它可以表达“有网络时同步”“充电时处理”“空闲时清理”“失败后按退避重试”等策略。Job 的优点是让系统把多个 App 的工作合并到更少唤醒次数中，降低 CPU、modem 和存储反复启动的成本。Job 的边界是实时性弱，触发时间由系统窗口决定。

导航 App 可以把同一功能拆成多个角色。正在导航的定位与语音播报属于用户可见长期任务；路线偏离提醒可以通过通知展示；离线地图包下载属于用户发起数据传输或约束化后台任务；历史轨迹上传适合 Job 或 Background Task；服务器下发道路封闭事件可以通过 Push 触发短处理或通知。这样拆分后，每个资源请求都有自己的系统理由和失败恢复方式。

角色	适合的任务语义	系统主要检查点	失败或降级表现
Foreground Service / 用户可见长期执行	导航、播放、通话、主动传输	通知、服务类型、启动条件、权限	无法启动、被用户停止、超时、权限错误
Background Task / BGTask	刷新、处理、清理、同步	约束、窗口、配额、电源状态	延迟执行、被中断、下次重试
Push	服务器事件到达设备	优先级、用户设置、预算、通知策略	延迟、静默处理失败、只展示通知
Alarm	接近指定时间的提醒	精确性用途、Doze、权限、用户设置	推迟到窗口、降级为通知、被系统限制
Job	可约束、可重试、可批处理工作	网络、充电、空闲、退避、配额	等待约束、退避重试、被取消

这个表的迁移用法是先写任务语义，再选 API。若任务中断会直接破坏用户正在感知的体验，优先进入用户可见长期执行；若任务可以推迟并恢复，进入 Job 或 Background Task；若事件源在服务器，使用 Push 通知设备；若核心语义是指定时间提醒，使用 Alarm 或通知模型。

145.4 Network、Location、Audio、Bluetooth、Camera 的后台访问边界

不同硬件能力在后台具有不同边界。后台 CPU 是基础预算，网络涉及 modem 和 Wi-Fi 唤醒，定位涉及 GNSS、Wi-Fi、蜂窝和传感器融合，音频涉及用户当前听觉体验，蓝牙涉及连接和扫描，Camera 涉及强隐私传感器。系统不会用同一套规则处理这些能力，因为它们的功耗、隐私和用户可见性差异很大。

Network 的后台边界主要是电源和公平性。移动网络唤醒 modem、建立无线连接、保持心跳和传输数据都会改变全机功耗。系统因此倾向于合并后台网络请求，延迟普通同步，给用户可见通知或高优先级事件短窗口。导航 App 的路况上传如果是少量且服务当前导航，系统更容易接受；批量上传历史轨迹应进入约束化任务，并允许 Wi-Fi、充电或空闲条件参与调度。

Location 的后台边界同时涉及功耗和隐私。持续 GNSS 采样会增加能耗，后台位置还会暴露用户移动轨迹。系统因此要求明确权限、用途声明、用户可见提示和可撤销设置。导航 App 锁屏后继续定位有清晰用户意图；一个优惠券 App 在后台持续定位以判断商圈触达，则需要面对更严格的权限提示、后台刷新设置和平台审核。

Audio 的后台边界与用户感知强绑定。媒体播放、播客、导航语音、通话和录音会直接影响用户听觉体验，也会占用音频路由、蓝牙设备、麦克风或扬声器。系统通常要求声明音频会话、处理音频焦点、响应中断，并在锁屏或控制中心提供可见状态。导航 App 的语音播报应和音乐播放、电话通话、蓝牙耳机连接形成稳定协作，不能假设后台线程可以直接占有音频设备。

Bluetooth 的后台边界取决于连接类型和扫描行为。已连接设备的数据交换、低功耗外设同步、音频路由和配件通信有不同系统路径；后台扫描和广播则会影响功耗和隐私，因为蓝牙信号可用于环境识别和位置推断。系统会把 companion device、蓝牙权限、位置权限、扫描频率和后台模式共同纳入判断。导航 App 使用蓝牙耳机播报语音主要走音频路由；它若在后台扫描周边 Beacon，则进入另一套权限和功耗边界。

Camera 的后台边界最敏感。相机画面属于强隐私输入，系统会通过运行时权限、隐私指示器、前台可见性、foreground service 类型或平台批准用途限制后台采集。普通 App 在后台持续打开相机通常会触发权限拒绝、服务限制、隐私提示或平台治理。对导航 App 来说，后台路线引导不需要相机；若增加行车记录或 AR 导航功能，架构必须把相机采集限定在用户可见、明确授权和可停止的路径中。

能力	主要系统资源	后台策略核心	用户可见证据	架构设计判断
Network	modem、Wi-Fi、CPU、TLS 状态	合并、延迟、窗口、数据节省	同步状态、通知、失败重试	可延迟数据进入 Job 或 Background Task
Location	GNSS、Wi-Fi、蜂窝、传感器	权限、用途、采样频率、前后台状态	位置指示器、权限设置、导航状态	当前导航可持续，历史分析应批处理
Audio	DSP、音频路由、蓝牙、麦克风	音频会话、焦点、中断、后台模式	锁屏控制、声音、录音指示	播放和录音分开建模
Bluetooth	蓝牙控制器、扫描、连接	权限、扫描预算、配件关系	蓝牙状态、连接提示、权限弹窗	已连接传输和后台扫描分开建模
Camera	ISP、sensor、buffer、隐私通道	权限、可见性、指示器、用途审查	相机指示器、权限弹窗、预览界面	采集路径应用户可见且可停止

这个矩阵的作用是把“后台能不能用某硬件”转成五个问题：资源成本是什么，隐私敏感度多高，用户是否能感知，系统在哪个服务执行检查，失败后 App 如何恢复。回答完这些问题，后台能力才有可维护的工程边界。

145.5 Scheduling Window、Batching、Backoff 与系统调度

后台调度的核心手段是窗口、批处理和退避。窗口（Scheduling Window）表示系统愿意分配后台执行预算的时间段；批处理（Batching）表示系统把多个 App 或多个任务合并到同一唤醒周期；退避（Backoff）表示失败后按照固定或指数策略延后重试。这些策略共同减少无序唤醒、网络心跳、存储写入和 CPU 频繁切换。

Android 的 Doze 会在设备长时间未使用时限制网络、WakeLock、普通 Alarm、Wi-Fi 扫描、同步适配器、JobScheduler 和 WorkManager 任务，并在维护窗口集中放行部分工作。App Standby 会根据用户近期交互把 App 放入不同后台能力状态。系统版本、设备厂商和电池优化设置会进一步影响窗口长度、配额和限制强度。Android 6.0 以后这些电源管理能力成为后台行为判断的长期边界，后续版本又持续加强 foreground service 启动和类型约束。

Apple 的后台窗口更强调系统选择。BGTaskScheduler 允许 App 提交刷新或处理请求，并给出 earliestBeginDate、网络和电源需求等约束；系统根据用户使用习惯、电量、温度、网络、充电和隐私设置安排执行。Background URLSession 把上传下载交给系统进程托管，App 被挂起后仍可由系统完成传输并在合适时机回调。Apple 公开文档不会承诺精确执行时间，工程设计应把窗口看作机会，而非定时器。

批处理改变了后台任务的代码结构。一次同步任务应能读取本地待处理队列，按小批次处理，保存进度，接受中断，并在下次窗口继续。任务中间状态要落盘，网络请求要可重试，服务端接口要支持幂等或去重。若 App 把 30 分钟后台工作写成一个不可拆分的长事务，系统中断会把它变成反复失败的耗电源。

退避策略用于处理失败后的公平性。后台任务失败可能来自网络不可用、服务器限流、权限撤销、电量过低、温控状态、用户关闭后台刷新或系统配额耗尽。固定间隔重试会在弱网或服务器故障时制造额外唤醒；指数退避、约束重试和服务端重试窗口可以降低冲突。对导航 App 的路况上传来说，失败后应记录最后成功点和待上传片段，随后在网络恢复或系统窗口到达时继续，而不应保持后台循环。

调度窗口还要求 App 区分“用户等待的结果”和“系统可以延后的结果”。导航重新规划路线属于用户等待的结果，应通过用户可见路径争取即时执行；上传匿名路况、同步历史轨迹、刷新离线地图索引可以延后。后台策略的设计目标是把有限预算留给用户当前任务，把其余工作变成可批处理、可恢复、可取消的系统托管任务。

145.6 Background Execution 与 Battery、Privacy、User Attention 的关系

后台执行策略本质上是在电池、隐私和用户注意力之间做取舍。Battery 决定后台任务能消耗多少 CPU、网络、GNSS、蓝牙和存储预算；Privacy 决定传感器、位置、相机、麦克风、蓝牙扫描和通知内容能否在用户未看见 App 时继续工作；User Attention 决定系统是否允许通过通知、声音、锁屏状态或前台服务提示打扰用户。

电池维度关注全机成本，而非单个 API 调用。一次后台网络请求可能唤醒 CPU、modem、TLS 栈和存储日志；一次位置更新可能启动 GNSS、传感器融合和地图匹配；一次通知可能点亮屏幕、播放声音并触发用户解锁。系统因此用窗口、配额、低电量模式、数据节省和温控状态限制后台行为。App 只看到请求延迟，系统看到的是全机能耗曲线。

隐私维度关注用户是否理解数据仍在产生。后台位置、麦克风、相机、蓝牙扫描和照片访问都可能在用户注意力离开 App 后继续暴露信息。系统通过权限弹窗、设置页、隐私指示器、使用记录、后台模式声明和审核规则建立可见边界。导航 App 在后台使用位置时，应让用户在系统权限、通知或导航状态中看见该行为；静默采集会在权限、商店审核和用户信任上形成高风险。

用户注意力维度关注打扰是否有明确收益。通知、声音、震动、锁屏控件和前台服务通知都在争夺用户注意力。系统会把通知权限、渠道、类别、专注模式、摘要、静默设置、重要提醒和用户关闭行为纳入后台策略。导航偏航提醒对用户当前行程有直接收益；普通促活推送对当前任务的相关性弱，更容易被用户关闭或被系统降级。

这三个维度经常相互制约。为了提高实时性而持续保持网络连接，会增加电池成本；为了降低打扰而静默处理推送，可能拿不到足够后台执行窗口；为了减少权限提示而降低采样频率，可能让导航体验下降。后台架构的成熟度体现在能明确这些取舍，并为每类任务设置降级路径。

导航 App 可以采用分层策略：行进中导航使用持续位置和音频提示，配合用户可见状态；轻量路况上传按窗口和网络状态批处理；离线地图更新放到 Wi-Fi 与充电条件；促活通知遵循用户授权和渠道设置；设备进入低电量或高温状态时降低上传频率和非关键计算。这样设计后，后台执行不再依赖单点保活，而是由任务价值和系统预算共同决定。

145.7 后台策略对 App 架构和任务设计的约束

后台策略会反向塑造 App 架构。稳定的移动 App 应把后台工作拆成四类：实时任务、可延迟任务、可恢复任务和用户可见任务。实时任务服务当前用户意图，要求低延迟和明确反馈；可延迟任务可以等待系统窗口；可恢复任务要保存进度并接受中断；用户可见任务需要通知、锁屏状态、音频状态或系统 UI 暴露资源使用。

实时任务的设计重点是最小化后台负载。导航路线重算、通话音频、紧急消息提醒属于这一类。代码上应把实时路径保持短链路，只保留当前体验必要的数据处理；历史分析、统计上报、缓存更新等工作应从实时链路剥离。这样在电量低、网络弱或温控收缩时，系统仍有机会保留核心体验。

可延迟任务的设计重点是表达约束。离线地图更新、内容预取、日志上传、相册索引、模型更新都可以等待 Wi-Fi、充电、空闲或系统窗口。任务提交时应把网络类型、电量状态、充电需求、最早执行时间、失败退避和数据大小表达清楚。系统掌握这些约束后，才能把多个任务合并并降低全机唤醒成本。

可恢复任务的设计重点是状态机。后台任务随时可能被系统中断、进程回收、网络断开或权限撤销。架构应把任务拆成可确认的小步骤，每步完成后保存状态。服务端接口要支持幂等请求，本地队列要能去重，回调重复到达时要能合并。对导航 App 来说，历史轨迹上传应以片段为单位确认，而非把整段行程作为一次不可分割任务。

用户可见任务的设计重点是诚实表达资源使用。Foreground Service 通知、锁屏播放控件、导航状态、通话界面、位置指示器和系统权限页都属于用户可见证据。用户看到这些证据后，系统也给出停止、暂停、关闭权限或改变通知设置的控制入口。App 架构应把“继续后台执行”和“用户可停止”放在同一条路径中处理。

后台任务还需要统一失败语义。失败来源至少包括权限撤销、用户关闭后台刷新、系统低电量、温控状态、网络约束未满足、调度窗口未到、配额耗尽、服务端错误和用户主动停止。错误处理不应只写成 retry；它应返回到任务分类：实时任务给用户反馈，可延迟任务等待窗口，可恢复任务保存进度，用户可见任务更新通知或停止状态。

一个可迁移的设计顺序如下。先把用户意图写清楚，再把任务分成实时、可延迟、可恢复、用户可见四类；随后为每类任务写资源需求、权限需求、调度约束和失败恢复；最后把 Android 与 Apple 的具体 API 映射到同一组语义上。这样做可以减少平台差异带来的混乱：Android 的 WorkManager、JobScheduler、Foreground Service、Alarm 和 Push，与 Apple 的 BGTaskScheduler、background modes、background URLSession、remote notification 和生命周期回调，最终都服务于同一个后台任务模型。

最小自检任务

某导航 App 支持三个后台能力：锁屏后继续语音导航，定期上传匿名路况，夜间自动下载离线地图。请把这三个能力分别放入后台执行策略中，写出 App 意图、Framework 入口或系统托管入口、系统检查点、资源边界、失败表现和用户可见结果。

答案要点

• 语音导航属于用户可见长期任务。App 意图是维持当前导航体验，系统入口应连接定位、音频和通知或导航状态，检查点包括后台位置权限、音频会话或焦点、前台可见语义、低电量和温控状态。资源边界是 GNSS、CPU、音频路由和少量网络。失败表现包括位置权限撤销、音频被电话中断、系统停止任务或通知被用户关闭。用户可见结果应是锁屏导航状态、语音播报、位置使用提示和可停止入口。
• 匿名路况上传属于可延迟且可恢复任务。App 意图是把行程片段上报给服务端，系统入口适合使用 Job、WorkManager、BGTask 或后台网络窗口。检查点包括网络可用性、数据节省、Doze 或后台刷新状态、用户近期使用、配额和退避策略。资源边界是网络、CPU、存储队列和少量定位派生数据。失败表现包括延迟到维护窗口、上传中断、退避重试或权限导致数据不可用。用户可见结果可以是同步状态或无打扰的完成状态。
• 夜间离线地图下载属于约束化后台传输。App 意图是预取大数据，系统入口适合用户发起数据传输、background URLSession、WorkManager 或 JobScheduler。检查点包括 Wi-Fi、充电、电量、存储空间、网络策略和用户是否允许后台下载。资源边界是 Wi-Fi、存储写入、CPU 解压和电池预算。失败表现包括等待 Wi-Fi 或充电、空间不足、下载暂停、下次窗口续传。用户可见结果应是下载进度、可取消入口和完成通知。
• 三个能力的共同判断顺序是先看用户当前意图，再看任务是否需要即时完成，随后看资源和隐私边界，最后看系统窗口和失败恢复。语音导航应争取持续执行，路况上传应接受批处理，离线地图应按约束托管给系统。

本章知识点总结

• 后台授权：后台执行是系统对 CPU、网络、定位、蓝牙、音频、通知等资源的策略分配。
• 可见性：App 是否前台可见、是否有用户可见长期任务，会直接影响后台执行资格。
• 任务语义：API 选择应从任务语义出发，区分用户可见长期执行、系统托管任务、推送、定时提醒和约束化 Job。
• 前台服务：Foreground Service 适合中断会破坏当前体验的用户可见任务，并通过通知暴露资源占用。
• 系统托管：WorkManager、JobScheduler、BGTaskScheduler 和 background URLSession 适合可延迟、可恢复、可约束的工作。
• 推送边界：Push 适合传递服务器事件，能否唤醒和展示由优先级、用户设置、预算和系统状态共同决定。
• 硬件差异：Network、Location、Audio、Bluetooth、Camera 的后台边界由功耗、隐私和用户可见性共同决定。
• 调度窗口：系统通过窗口、批处理和退避减少后台唤醒次数，并把任务放到更合适的电源和网络条件下执行。
• 电池约束：后台网络、定位、存储和通知会影响全机功耗，系统因此限制持续后台活动。
• 隐私约束：后台位置、麦克风、相机和蓝牙扫描需要权限、提示、用途声明和可撤销设置支撑。
• 注意力约束：通知、声音、震动和锁屏状态占用用户注意力，系统会把用户设置和专注策略纳入判断。
• 架构分类：后台任务应拆成实时任务、可延迟任务、可恢复任务和用户可见任务。
• 恢复设计：后台任务应保存进度、支持幂等、接受中断，并根据失败来源选择反馈、等待、重试或停止。
• 跨平台映射：Android 和 Apple 的后台 API 名称不同，但都服务于 App 意图、系统检查、资源调度和可见结果这一责任链。