iOS应用不同状态下App Delegate运行机制及推送徽章问询

核心问题解答 #

1. 应用被杀死（未被RAM回收前）App Delegate代码是否运行？ #

当用户主动划掉应用（杀死）后，App进程已被终止，App Delegate的代码不会运行。你遇到的“有时正常”，是因为如果推送的payload里直接带了badge字段，APNs会直接在系统层面设置徽章，完全不需要App代码参与。但如果你的徽章计数依赖App Delegate里的自定义逻辑（比如累加未读数、从服务器拉取实时数据），这时App没启动，代码执行不了，徽章就会异常。

2. 设备重启后App Delegate代码是否完全不运行？ #

设备重启后，应用处于未启动状态，App Delegate的代码不会自动运行。这就是重启后通知正常但无徽章的原因：通知是APNs直接推给系统，由系统展示；但如果徽章需要App代码计算（比如同步服务器未读计数），App没启动就没法执行这段逻辑，自然显示不了徽章。

结合你的场景差异分析 #

• 前台/后台：App处于活跃或挂起状态，App Delegate的didReceiveRemoteNotification等相关方法会被触发，徽章的自定义逻辑能正常执行，所以通知和徽章都没问题。
• 应用被杀死：徽章时好时坏，本质是两种推送情况的区别——payload带badge字段时系统直接处理，徽章正常；payload不带或需要App计算时，因为App进程已死，代码跑不起来，徽章就异常。
• 设备重启：通知由系统直接展示，但App没启动，徽章的自定义逻辑无法执行，所以只有通知没徽章。

可行的解决办法 #

• 直接在推送payload中携带正确的badge值：这种方式最可靠，不管App处于什么状态（前台、后台、杀死、重启），APNs都会直接让系统设置徽章，不需要App代码介入。
• 依赖App自定义计算的话，用静默通知补充：给推送加上content-available: 1（需开启后台远程通知权限），应用被杀死时，静默通知能短暂唤醒App后台运行，此时可以在didReceiveRemoteNotification:fetchCompletionHandler里执行徽章计数逻辑并设置。但设备重启后，静默通知也唤醒不了App，只能等用户手动打开App后，再拉取数据同步徽章。

内容的提问来源于stack exchange，提问作者Raymond Dillon