iOS 消息推送那些事儿

上面这张图是在 iOS 7 设备上，首次安装时，拒绝了授权，进入系统设置看到如上图所示。从上面的图我们得到什么信息呢？

一个很重要的点，就是 「 在通知中心 」 中显示 和 在锁定屏幕上显示 不是影响获取 devicetoken 的关键因素。

另外测试中发现，基于上面图中作为当前状态

• 如果用户打开 图标标记 或者 声音 ，这时候再启动 APP，就能拿到 devicetoken；但由于最上面的展示样式是选择了无，所以并不会展示出来给用户看到

• 如果用户把样式选择了 「横幅」 或 「提醒」 （图标标记或者声音都是未打开状态），这时候再启动 APP，也能拿到 devicetoken；这时候服务端下发通知，是能展示出来给用户看到的，但没有提示音跟图标红点数而已

• 如果用户只开 「标记」 跟 「声音」 ，而展示样式 「 无 」 ，那么就会只听到声音，而没任何通知展示。

• 如果用户全打开了，那就跟允许授权时一样的设置了

1.3 远程推送之静默推送

说到 iOS 的远程推送，静默推送就不得不讲。

静默推送是在 iOS 7 出现的，官方也叫 Background Update Notification ，也就是用于 APP 在处于 非 Kill 状态下，收到通知之后，可以预先处理一些数据用于用户展示，优化体验的。这一切都是在后台执行的，也不会展示通知，用户是无感知的。

静默推送的使用限制

但苹果为了不让开发者滥用这个功能，而导致耗费手机设备上更多的资源（CPU、电量等等），对静默推送也做了限制，但这具体的限制是由苹果的 APNS 服务器定的。

下面引用官方文档的一段话

(https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CreatingtheNotificationPayload.html#//apple_ref/doc/uid/TP40008194-CH10-SW1)

IMPORTANT

Background update notifications are not meant as a way to keep your app awake in the background beyond quick refresh operations, nor are they meant for high priority updates. APNs treats background update notifications as low priority and may throttle their delivery altogether if the total number becomes excessive. The actual limits are dynamic and can change based on conditions, but try not to send more than a few notifications per hour .

静默推送的参数控制

原则上，静默推送就是在后台用户不感知的，但根据官方文档说的，你在 aps 那个 dictionary 加入 alert 、 sound 也是允许的，这时候是会展示出来给用户看到的。

To support a background update notification, make sure that the payload’s aps dictionary includes the content-available key with a value of 1. If there are user-visible updates that go along with the background update, you can set the alert, sound, or badge keys in the aps dictionary, as appropriate.

不过要注意，虽然加了 alert 、 sound 会让通知展示出来，但同时也把 静默推送 变成 普通推送 ，也就失去了原本静默推送的作用，也就是上面描述的 「 APP 处于后台，收到通知能后台执行代码处理展示数据，提升体验 」 。

所以还是建议，如果想展示通知，就使用普通推送类型即可；

如果想使用静默推送做些事情，就不加 alert、sound、badge 等这些字段

1.3 从推送授权状态、推送类型、App生命周期状态三个维度总结表象

上面只是简单的宏观描述了下，远程推送这个功能的大体流程，但实际上，在远程推送这条链路上，会有多个可变因素导致了多种组合，最终也导致了不同的表象。

首先，先解释列举下可变因素：

• APP 的前后台状态

• 用户是否允许授权弹出通知

• 推送分为普通推送以及静默推送

另外在表象上，又分为两种，一种是用户直观上，也就是通知在手机上的展示；第二种就是对于开发者来说，也就是收到系统的回调。

我们假设

:white_check_mark:：代表用户能看到通知 :negative_squared_cross_mark:：代表用户看不到通知

:heavy_check_mark:：代表代码上通知到达时能收到系统的回调 :x:：代表代码通知到达时收不到系统回调

要注意下，这里所讲的能否收到回调，是指通知到达的时候