在 WWDC25 的主题演讲上，Apple 提到 iPadOS 26（同时适用于 iOS 26）提供了一个新的后台 API。这个 API 旨在为计算密集型任务提供后台能力，调用时会显示一个实时活动（Live Activity），让用户了解并完全控制当前运行的内容。而到了 iOS 26.1，新的「相册后台备份」API 还允许第三方应用在后台上传照片等资源文件。由此观察，iOS 的后台机制，似乎已经相比于早年那种被称为「墓碑」的假后台发生了很大变化。
在 WWDC25 的主题演讲上，Apple 提到 iPadOS 26（同时适用于 iOS 26）提供了一个新的后台 API。这个 API 旨在为计算密集型任务提供后台能力，调用时会显示一个实时活动（Live Activity），让用户了解并完全控制当前运行的内容。而到了 iOS 26.1，新的「相册后台备份 」API 还允许第三方应用在后台上传照片等资源文件。
由此观察，iOS 的后台机制，似乎已经相比于早年那种被称为「墓碑」的假后台发生了很大变化。
没有后台的 iPhoneOS 时代
如果你还记得 iOS 曾经叫 iPhoneOS 的时候，那么你一定记得那个 iPhone 完全没有后台的年代。在当时，每次按下 Home 键回到主页时，当前正在前台运行的 app 就会被直接终止；再次返回 app 时，一切都需要重新启动——也就是完全不存在后台。
虽然 2008 年时 Symbian 和 Android 系统都已支持多任务形态，但在当年的 WWDC 上，iPhone 软件主管 Scott Forstall 表示：「允许后台运行会耗电、占用 CPU。」作为参考，初代 iPhone 采用的是 412 MHz ARM11 处理器，RAM 仅 128 MB。在这样羸弱的硬件配置下，如果直接开放后台，结果可能与当时的 Android 系统无异。因此，采取「前台单任务、后台不开放」的策略，在当时是不得已的折衷方案。
WWDC 2008 现场，图源 Apple Insider
在应用未运行时，为了仍能与用户保持联系，Apple 推出了至今沿用的 Apple 推送通知服务（Apple Push Notification Service，APNs）。该机制的核心是由第三方应用发起消息请求，统一通过 Apple 服务器中转，再推送至用户的 iPhone。
所以，Apple 依靠集中化的推送服务，在当时就把唤醒设备的控制权牢牢掌握在系统层面。这种模式既避免了应用各自消耗电量，又实现了 Apple 想一直强调的目标：在确保用户能及时收到推送的同时，最大程度降低 app 在后台时的能耗。
墓碑后台时期
随着 iOS 4 的发布，iOS 总算有了某种程度上的「多任务」。但是，和桌面系统那种完全无限制的多任务机制不同，iOS 4 上的后台是一套极其有限的「能力集合」，只包括：
在应用间快速切换；
始终允许特定任务；及
短时允许部分任务。
在应用间快速切换
这是使用手机时最常见的操作之一。无论是回到主屏，还是从一个应用切换到另一个应用，实质上都是在应用之间快速切换。
iOS 4 多任务宣传图，图源 Apple
在 iOS 4 中，当我们离开一个应用时，系统不再直接终止应用，而是让其进入「暂停」状态：应用在内存里被「冻结」，不再消耗任何计算资源。当我们需要返回应用时，iOS 会自动「解冻」相关数据，恢复到离开时的状态。这是过去 iOS 系统流畅的原因之一，也就是所谓的「墓碑后台」。
App 在不同的状态间切换，图源 Apple
不过，受限于 iPhone 一向紧张的内存，冻结状态并不能保证应用完全不会被关闭。如果 iOS 发现内存压力过高，会根据从旧到新的顺序依次清理处于冻结状态的应用。这一点在许多旧款 iPhone 上尤为明显：在使用完大型 app 或相机 app 后，回到其他应用（特别是游戏）时，会发现它们已经丢失了冻结前的状态，需要重新加载。
始终允许特定任务
iOS 4 开放了部分场景下「真后台」运行的能力，但严格限定在音频播放、定位服务和 VoIP 这三类场景。
例如，用户可以在使用第三方软件听歌时切换到其他应用；运动与导航类 app 即使在锁屏后也能持续记录位置；支持 VoIP 的应用能够在后台接听来电。这都不需要对应的应用在前台保持活跃。
从今天的角度看，这种只允许特定场景始终保持后台的策略虽然保守，但在当时性能、内存和电池受限的情况下，确实显著提升了用户体验。
短时允许部分任务
除了上述常见后台活动，用户对许多操作同样具有「能顺利完成」的基本预期，例如将文件上传到云端或同步 app 数据。
这类功能不能因为按下 Home 键回到主屏、或短暂切换到另一款应用，就直接停止，否则用户会抱怨 iOS「连最基础的功能都不支持」。但是，当时的电池容量和处理器性能无法支撑多个活跃任务并行，内存规模也远低于桌面环境。如果直接允许 app 在后台长期运行并保持活跃，手机的续航和发热控制将面临巨大挑战。
Apple 给出的方案是允许部分后台短时运行，但依然由 iOS 决定后台可用的时间长度（通常固定为 10 分钟）。一旦超时，iOS 就会强制停止这部分后台任务。
总之，iOS 4 时代的「多任务处理」更像是一组权衡过的「能力」。iOS 首先确保前台交互的流畅性与续航，再保证少数对用户价值极高的场景（音频、定位、VoIP）能持续运行，最后对其他后台任务短暂放行，并由系统综合各项条件随时收回。
更加见机行事的后台机制
随着 iPhone SoC 性能和屏幕素质的提升，应用为了充分发挥硬件能力、支撑更频繁的数据更新与更多元的前台体验，对后台活动的需求也日益增加。从 iOS 7 开始，Apple 逐渐转向了更加见机行事的后台机制。
智能后台刷新
所谓的更加见机行事，本质上是从固定、可预测的后台执行窗口，转向一个由 iOS 本身主导、以预测式调度为核心的智能后台刷新模型。
在这一模型中，app 是否能在后台获得执行时间，不再由应用自行请求决定，而是由 iOS 根据一系列动态信号来判断是否值得在此时唤醒应用。虽然 Apple 未公布具体实现细节，但在当年的 WWDC 上表示：「iOS 会利用系统级的行为模式学习与资源状态评估，对多种信息建模。」
FG 表示前台，较暗淡的颜色表示 iOS 会让 app 发起后台刷新，图源 Apple
根据后续的逆向分析，iOS 首先会「学习」用户打开应用的频率和时间分布，并在此基础上推断用户何时可能会再次打开应用。例如，如果用户早上经常打开一款新闻应用，iOS 就会在用户起床前的某个时间段，提前为该 app 安排后台刷新。
影响后台刷新的多个原因，图源 Apple
除了学习使用频率，iOS 还会综合考虑 iPhone 的电量、机身温度、网络质量、SoC 负载和内存压力等因素。正常情况下，当 iPhone 处于闲置状态时，app 既能刷新内容，又不会对续航产生显著影响。反之，当网络质量变差或电量偏低时，后台刷新就会被延后或暂停。
此外，iOS 还会根据 app 后台执行的成功率、耗时、能耗表现等指标给出一个评分。如果一个 app 总是能在预期内高效地获取数据，其评分就会变高，iOS 便会提高该 app 的后台调度优先级——分配更多刷新机会，并在同一刷新时机优先处理。
当然，iOS 的后台刷新是统一唤醒、统一执行的。系统倾向于集中安排后台任务，从而减少碎片化、频繁的后台唤醒，降低待机能耗。值得注意的是，如果用户在后台切换器中将 app 向上滑动关闭，该 app 将不会进行刷新。
