Silent Push — 本质、后台任务与交付配置

什么是 Silent Push — 本质与目的

Silent Push（静默推送通知）是一种 iOS 机制，可将数据传送到设备而无需向用户显示任何视觉通知。与显示横幅、播放声音并出现在通知中心的标准推送不同，silent push 在后台 \\唤醒\\ 应用程序并将数据传递给它进行处理。用户永远不知道此类通知的送达 — 结果是下次打开时内容已更新。

与普通推送通知的区别

关键区别在于 JSON 载荷：silent push 包含 content-available: 1 标志，并且不包含 alert、sound 或 badge。带 alert 的标准通知始终显示给用户，无论 content-available 如何。Silent Push 仅与 content-available: 1 配合使用且不带 alert — 如果添加了 alert，即使存在后台传送标志，系统也会显示通知。

何时使用 Silent Push

静默通知对于数据在打开应用时须为最新但不应打扰用户的场景至关重要。示例：后台更新新闻推送、同步订阅、下载新内容供离线访问、更新小部件、清除缓存。Silent Push 还用于在用户预期操作前 \\预热\\ 应用程序。

静默通知的传送机制

Silent Push 的传送与普通通知有显著不同，并遵循电源优化规则。iOS 系统从 APNS 接收推送请求，确定其为 silent push（content-available: 1），并根据多种因素决定是否传送：电池电量、省电模式、先前 silent push 的频率、应用程序活动以及当前 CPU 负载。

Power Nap 与后台模式的作用

在配备 Apple M 芯片和 iOS 15+ 的设备上，silent push 与 Power Nap 机制集成，该机制定期唤醒设备执行后台任务。Power Nap 将多个 silent push 合并到一个活动时段，从而降低总能耗。开发者无法直接管理 Power Nap — 系统会根据用户行为和应用使用历史自动做出决定。

30 秒处理窗口

当系统传送 silent push 时，AppDelegate 中的 application(_:didReceiveRemoteNotification:fetchCompletionHandler:) 被调用。开发者必须在 30 秒内调用 completion handler，并传递正确的结果（UIBackgroundFetchResult）。如果处理未及时完成，系统可能会限制此应用的 silent push 频率或完全停止传送。

// 在 AppDelegate 中处理 Silent Push
func application(
    _ application: UIApplication,
    didReceiveRemoteNotification userInfo: [AnyHashable: Any],
    fetchCompletionHandler completionHandler:
    @escaping (UIBackgroundFetchResult) -> Void
) {
    guard let type = userInfo["sync-type"] as? String
    else {
        completionHandler(.failed)
        return
    }

    if type == "news-feed" {
        NewsFeedSyncService().sync { success in
            completionHandler(success ? .newData : .failed)
        }
    } else if type == "cache-invalidate" {
        CacheManager.shared.invalidateAll()
        completionHandler(.newData)
    } else {
        completionHandler(.noData)
    }
}

传送间隔

Apple 未公布 silent push 之间的精确间隔，但根据测试和文档建议，每台设备每小时发送不超过 2–3 条静默通知。如果发送过于频繁，系统将开始忽略 silent push，数据将停止传送。如果需要更频繁的同步，请考虑使用带后台配置的 URLSession 或 VoIP 推送。

Silent Push 使用场景

Silent Push 应用于广泛的任务场景，其中数据必须保持最新而无需用户主动参与。让我们看看这一机制在实际 iOS 应用中最有效的使用场景。

离线访问内容更新

新闻应用、阅读器和旅行应用使用 Silent Push 在后台下载新内容。当用户打开应用时，数据已下载完毕，即使没有网络也可使用。这种方法从根本上改善了用户体验 — 空白加载屏幕消失，内容立即显示。服务器在有新文章时发送 silent push，应用在后台下载以供离线阅读。

小部件状态同步

iOS WidgetKit 按计划更新小部件，但对于服务器数据更改后的即时更新，使用 Silent Push。后台应用处理 silent push，更新小部件的本地数据存储，并通过 WidgetCenter 强制更新时间线。用户无需打开应用即可在小部件上看到最新信息 — 汇率、天气预报、配送状态。

缓存失效与过期数据清理

当服务器更新关键数据（例如定价规则、高级用户可用功能列表）时，Silent Push 允许立即使本地缓存失效。下次打开时应用将从服务器加载最新数据，而不是使用过时的缓存。这对具有付费内容或订阅的应用尤其重要。

无可见通知的徽标更新

在某些场景下，需要更新应用图标上的徽标而不显示通知。带 badge 字段的 Silent Push 载荷允许设置所需的计数器值，而无需用横幅打扰用户。例如，聊天应用可以更新未读消息数量的徽标，而无需将每条新消息显示为通知（如果用户已在应用内）。

配置 silent push：载荷与功能

要使 Silent Push 正常工作，需要在三个层面进行配置：Xcode 项目、服务器上的 JSON 载荷以及应用中的处理代码。每个层面都至关重要：跳过任何步骤都会导致通知被当作普通通知送达或根本无法送达。

在 Xcode 中配置功能

在 Xcode 中，需要启用 Push Notifications 功能和 Background Modes（勾选 Remote notifications）。Push Notifications 会生成 APNS 证书，而 Background Modes 中的 Remote notifications 允许系统在收到 silent push 时唤醒应用。没有 Remote notifications，silent push 会被送达但应用不会在后台激活，数据也不会被处理。

JSON 载荷结构

Silent Push 载荷必须包含 content-available: 1 的 aps 键，并且不能包含 alert、sound 或 badge。自定义字段与 aps 在同一层级上传送，包含待处理数据：操作类型、对象标识符、元数据。没有 content-available 的载荷将被作为普通通知处理；带 alert 的即使有 content-available 也会被作为普通通知。

{
    "aps": {
        "content-available": 1
    },
    "sync-type": "news-feed",
    "last-article-id": "article_8521",
    "priority": "high"
}

客户端处理

收到 silent push 后，iOS 会在应用变为可见之前调用 application(_:didReceiveRemoteNotification:fetchCompletionHandler:)。在此方法中需要解析 userInfo，执行必要的工作（网络请求、Core Data 写入、缓存更新），并务必在 30 秒内使用正确结果调用 completionHandler。不调用 completionHandler 会被系统视为错误，并影响未来 silent push 的频率。

限制与最佳实践

Silent Push 不是关键操作数据的可靠传送通道 — 它是一种优化机制，而非保证同步。开发者必须了解其限制，并设计系统使其无论有无 silent push 都能正常工作。

传送限制

iOS 不保证每个 silent push 都能送达。系统可能在电池电量低（低于 20%）、处于低电量模式、先前 silent push 频率过高或应用长时间未使用时延迟或取消传送。根据 Apple 数据，平均传送统计：约 70–80% 的 silent push 在 5 分钟内送达，其余可能被延迟或丢失。

Apple 关于 silent push 的建议

Apple 建议遵循几条规则以有效使用 silent push。每台设备每小时发送不要超过 2–3 个 silent push — 超出限制会导致封锁。使用紧凑的载荷：最小载荷大小可加快处理速度并减少网络负载。始终尽快调用 completionHandler：处理时间越长，系统未来限制 silent push 的可能性就越大。

Silent Push 的替代方案

对于需要保证传送或更多处理时间的场景，请考虑替代方案。VoIP 推送（PushKit）保证传送并给予更多时间，但仅适用于 VoIP 应用。Background fetch（UIApplication background fetch）由系统按计划启动，但不能由服务器触发。WebSocket 保持持久连接，但消耗更多电池，不适用于所有类型的应用。

监控与调试

要调试 Silent Push，请在 Mac 上使用 Console.app 并按应用名称过滤。系统会记录每个 silent push，标记为 \\background task\\，并指示处理是否成功。在设备上，通过 Settings → Developer → Background Modes Logging 进行检查。服务器端通过 APNS Feedback Service 监控以识别未送达的通知。