背景
iOS 系统下，APP 退到后台一段时间后，系统会杀死APP 以获得更优的性能体验。在此背景下，APPLE 推送 Remote Notifications 功能帮助开发者在 APP 未开启情况下接收消息（例 ：收到聊天消息）。
概述
简单来说 Remote Notifications 分为两个核心部分，生成通知 和 推送通知到用户的设备。实现相关功能主要涉及以下几个关键点：
- 公司的后端（provider server）
- 苹果推送通知服务（APNs）
- 用户的设备
- 你的APP 运行在用户的设备上
总的远程通知流程 如下：
其中，我们开发者负责提供 Provider server 和 客户端相关配置及通知处理，苹果管理所有中间的交互且包括客户端。
针对上图的Remote Notifications 核心流程，下文主要简述客户端、业务服务端需要做的工作以及 APNs 的工作内容。
注册 APNs (客户端)
首先需要在开发者账号及Xcode 项目配置中打开 Push Notifications 的相关功能。
其次，每次APP启动后，需要先同APNs进行交互，获得一个唯一的device token,把这个唯一标识上报给后端。
Device token 其实是我们的APP 在当前设备上的有效地址。
注册的方法：registerForRemoteNotifications,在application的代理方法：application:didRegisterForRemoteNotificationsWithDeviceToken:中接收device token。
此外可在 application:didFailToRegisterForRemoteNotificationsWithError:处理注册失败的场景，当遇到注册失败时，应该进行标记且过一段时间后进行重试。
注意：苹果不推荐缓存device token，当遇到用户设备启用系统备份，重装系统，新设备安装app 场景会下发新的device token。同时，对于APP来说，一个用户可能对应多台设备，多个device token。
关于如何配置APP去处理通知，可以查阅Registering Your App with APNs。
如何构建自定义的远程通知 基础架构（服务端）
构建 Provider server 远程通知相关的基础架构 关键任务如下：
获取device token且绑定到自己的账号系统上。
生成payload notifications，选择合适的时机发送给APNs。
使用 HTTP/2 和 TLS 建立与APNs的连接。（Sending Notification Requests to APNs）
定期的更新认证token。（ Establishing a Token-Based Connection to APNs）
如何生成一个远程通知
远程通知携带一个Payload json，可以指定四种用户交互类型：Alert、Sound、Badge、Silent。(VoIP 类型不同于普通推送，需要单独引入PuskKit)
需要注意的是 携带的JSON 既有苹果定义的key 也可以有自定义的key，且JSON 大小有严格的上限，超过上限苹果会拒绝推送。
VoIP类型的通知上限为5KB
远程通知的上限为4KB
此外，通过Notification Extension 处理多媒体文件时也有上限，音频5M，图片10M，视频50M，并且文件的格式必须是支持的类型
payload json 示例（全部可用字段参考官方文档：如何生成一个远程通知）：
// alert
{
"aps" : {
"alert" : {
"title" : "Game Request",
"subtitle" : "Five Card Draw",
"body" : "Bob wants to play poker"
},
"category" : "GAME_INVITATION"
},
"gameID" : "12345678"
}
// sound
{
"aps" : {
"badge" : 9,
"sound" : "bingbong.aiff"
},
"messageID" : "ABCDEFGHIJ"
}
// Background Notification
{
"aps" : {
"content-available" : 1
},
"acme1" : "bar",
"acme2" : 42
}
// 注意： 针对Background Notification (静默通知)
// 客户端需要在info.plist Background Modes 中开启 Remote notifications
// 客户端的单独回调：application:didReceiveRemoteNotification:fetchCompletionHandler:
// 服务端需要在请求头中设置 `apns-push-type`为`background`,`apns-priority`为`5`
需要注意的是不要在数据里面添加敏感数据，如果一定要携带敏感数据，应该在发送前主动加密，在notification extension 中进行解密。详细信息可参考：Modifying Content in Newly Delivered Notifications
补充下客户端处理通知的细节知识点：
1、payload 也支持 本地化（一般情况下会选择发送之前直接选择那种语言）
2、alert通知 可以设置 launch-image,用户通过通知 打开APP时，会启用这张特定的启动图
3、alert 通知的UI样式是可以自定义的。通过notification extension 自定义外观
自定义外观通过notification extension 中的view controller进行替换系统默认样式，主要包括以下自定义功能：
（1）自定义位置，包括 alert 的标题、副标题和正文。
（2）为界面元素替换不同的字体或样式。
（3）显示特定于应用程序的数据——例如，存储在通知有效负载的特定于应用程序键中的数据。
（4）自定义图像或品牌。
（5）音视频播放
（6）iOS12 之后 支持可交互的控件
使用的资源文件应当在notification extension的 bundle中，如果开启了app group，也可使用主APP共享数据中的文件。在notification extension 中 不推荐执行耗时任务。
Tips: 我们可以添加多个notification extension，多个extension 通过notification categories 来区分。详见：Declare the Supported Notification Types
与APNs 建立可信的连接
服务端需要安装： GeoTrust Global CA root certificate(until March 29, 2021) and the AAA Certificate Services root certificate(starting March 29, 2021)
服务端需要使用 HTTP/2 and TLS 与APNs 建立 基于token 或 基于证书的 可信连接。
Token-based: Establishing a Token-Based Connection to APNs.
Certificate-based: Establishing a Certificate-Based Connection to APNs.
APNs 提供的能力
- APNs 管理与用户设备的认证、加密和持久的 IP 连接。
- APNs 可以为当前离线的设备存储通知。当设备上线后，APNs会转发存储的通知。
- APNs 可以合并相同bundleID的通知。
总结：
Remote Notifications 为开发者提供 离线接收消息的能力，根据不同的应用场景分为VoIP,远程通知 和 本地通知。其中本地通知 不依赖于 服务端和 APNs。远程通知和VoIP 的实现流程基本一致（基于APNs）：客户端与APNs 交互后，获得通知相关的唯一标识符 device token，随后客户端发送device token 到服务端，服务端根据规则生成 payload json后 再与APNs 建立连接，并且把payload json 和 需要推送的device token 转发给APNs，最后APNs 再根据device token 把通知 转发给用户的设备上，客户端在application 指定的delegate 方法中实现通知的逻辑处理。
