版本记录
| 版本号 | 时间 |
|---|---|
| V1.0 | 2018.07.12 |
前言
我们做APP很多时候都需要推送功能，以直播为例，如果你关注的主播开播了，那么就需要向关注这个主播的人发送开播通知，提醒用户去看播，这个只是一个小的方面，具体应用根据公司的业务逻辑而定。前面已经花了很多篇幅介绍了极光推送，其实极光推送无非就是将我们客户端和服务端做的很多东西封装了一下，节省了我们很多处理逻辑和流程，这一篇开始，我们就利用系统的原生推送类结合工程实践说一下系统推送的集成，希望我的讲解能让大家很清楚的理解它。感兴趣的可以看上面几篇。
1. 系统推送的集成（一） —— 基本集成流程（一）
2. 系统推送的集成（二） —— 推送遇到的几个坑之BadDeviceToken问题（一）
3. 系统推送的集成（三） —— 本地和远程通知编程指南之你的App的通知 - 本地和远程通知概览（一）
4. 系统推送的集成（四） —— 本地和远程通知编程指南之你的App的通知 - 管理您的应用程序的通知支持（二）
5. 系统推送的集成（五） —— 本地和远程通知编程指南之你的App的通知 - 调度和处理本地通知（三）
6. 系统推送的集成（六） —— 本地和远程通知编程指南之你的App的通知 - 配置远程通知支持（四）
7. 系统推送的集成（七） —— 本地和远程通知编程指南之你的App的通知 - 修改和显示通知（五）
APNs Overview - APNs概览
Apple推送通知服务（APNs）是远程通知功能的核心。 它是一种强大，安全且高效的服务，可供应用程序开发人员将信息传播到iOS（以及间接的watchOS），tvOS和macOS设备。
在用户设备上首次启动应用程序时，系统会自动在您的应用程序和APNs之间建立经过认证，加密且持久的IP连接。 此连接允许您的应用执行设置以使其能够接收通知，如Configuring Remote Notification Support中所述。
用于发送通知的另一半连接 - 提供服务器和APNs之间的持久安全通道 - 需要在您的在线developer account中进行配置以及使用Apple提供的加密证书。 提供程序是您配置为使用APNs的部署和管理的服务器。 图6-1显示了远程通知的传递路径。
通过在您的提供者和应用程序中完成推送通知设置，您的提供商可以向APNs发送通知请求。 APN向每个目标设备传送相应的通知有效载荷。 收到通知后，系统会将有效负载传送到设备上的相应应用程序，并管理与用户的交互。
如果应用程序的通知在设备启动但应用程序未运行时到达，系统仍可显示通知。 如果在APNs发送通知时设备已关闭，则APNs会保留通知并稍后再次尝试（有关详细信息，请参阅 Quality of Service, Store-and-Forward, and Coalesced Notifications）。
Provider Responsibilities - 提供者责任
您的提供商服务器对参与APNs具有以下责任：
- 通过APNs从用户设备上的应用实例接收全球唯一的应用专用
device token和其他相关数据。这允许提供者了解您的应用程序的每个运行实例。 - 根据通知系统的设计确定何时需要将远程通知发送到每个设备。
- 建立并向APNs发送通知请求，每个请求包含通知有效载荷和传递信息；然后，APNs代表您向目标设备发送相应的通知。
对于提供者发送的每个远程通知请求，它必须：
- 构造包含通知有效负载的JSON字典，如Creating the Remote Notification Payload中所述。
- 将有效负载，全局唯一设备令牌和其他传递信息添加到
HTTP / 2请求。有关设备令牌的信息，请参阅APNs-to-Device Connection Trust and Device Tokens。有关HTTP / 2请求格式以及APNs可能的响应和错误的信息，请参阅Communicating with APNs。 - 通过持久的安全通道将
HTTP / 2请求发送到APNs，包括令牌或证书形式的加密凭证。 Security Architecture中描述了建立此安全通道。
Using Multiple Providers - 使用多个提供者
图6-2描述了APNs为运行应用程序的设备启用的虚拟网络类型。 要处理通知负载，您通常会部署多个提供者，每个提供者都有自己的与APNs持久且安全的连接。 然后，每个提供者可以发送针对提供者具有有效device token的任何设备的通知请求。
Quality of Service, Store-and-Forward, and Coalesced Notifications - 服务质量，存储转发和合并通知
Apple推送通知服务包括执行存储转发功能的服务质量（QoS）组件。如果APNs尝试发送通知并且目标设备处于脱机状态，则APNs会将通知存储一段有限的时间，并在设备再次可用时将其发送。此组件仅存储每个设备和每个应用程序的最新通知。如果设备处于脱机状态，则发送针对该设备的通知请求会导致先前的请求被丢弃。如果设备长时间保持脱机状态，则会丢弃其在APNs中存储的所有通知。
要允许合并类似通知，您可以在通知请求中包含折叠标识符collapse identifier。通常，当设备在线时，您发送到APNs的每个通知请求都会导致向设备发送通知。但是，当HTTP / 2请求标头中存在apns-collapse-id密钥时，APNs会合并其密钥值相同的请求。例如，两次发送相同标题的新闻服务可以对两个请求使用相同的折叠标识符值。然后，APNs将这两个请求合并为一个通知，以便传送到设备。有关apns-collapse-id密钥的详细信息，请参见Table 8-2。
Security Architecture - 安全架构
APNs使用两个信任级别强制执行端到端加密验证和身份验证：连接信任和设备令牌信任connection trust and device token trust。
连接信任在提供者和APNs之间以及APNs和设备之间起作用。
Provider-to-APNs connection trust - 提供者到APNs的连接信任。提供者到APNs的连接信任确定了提供者和APNs之间的连接只能由授权提供者实现，该授权提供商由与Apple达成推送通知传送协议的公司所有。您必须采取措施确保提供者服务器和APNs之间存在连接信任，如本节所述。
APNs-to-device connection trust - APNs到设备的连接信任 。APNs到设备的连接信任确保只有授权设备才能连接到APNs以接收通知。 APNs自动强制与每个设备建立连接信任，以确保设备的合法性。
对于提供者与APNs进行通信，它必须使用有效的身份验证密钥证书（用于基于token的连接信任）或SSL证书（用于基于证书的连接信任）。您可以从在线developer account中获取这些证书中的任何一个，如Xcode帮助中的Configure push notifications中所述。要在两种证书类型之间进行选择，请阅读Provider-to-APNs Connection Trust.。无论您选择哪种证书类型，提供者连接信任都是提供者向APNs发送推送通知请求的先决条件。
Device token信任对每个远程通知都是端到端的。它确保仅在正确的开始（提供者）和结束（设备）点之间路由通知。
device token是一个不透明的NSData实例，其中包含Apple为特定设备上的特定应用程序分配的唯一标识符。 只有APNs可以解码和读取设备令牌的内容。 每个应用程序实例在向APNs注册时都会收到其唯一的device token，然后必须将令牌转发给其提供者，如Configuring Remote Notification Support中所述。 提供者必须在每个推送通知请求中包含设备令牌，该请求以相关设备为目标；APNs使用设备令牌来确保通知仅传递给其预期的唯一应用程序设备组合。
APNs可以出于各种原因发布新的device token：
- 用户在新设备上安装您的应用
- 用户从备份恢复设备
- 用户重新安装操作系统
- 其他系统定义的事件
因此，应用程序必须在启动时请求设备令牌，如APNs-to-Device Connection Trust and Device Tokens中所述。 有关代码示例，请参阅Registering to Receive Remote Notifications。
重要：为保护用户隐私，请勿使用
device token来识别用户设备。
1. Provider-to-APNs Connection Trust - 提供者和APNs连接信任
有两种方案可用于协商提供者服务器与Apple推送通知服务之间的连接信任：
-
Token-based provider connection trust - 基于令牌的提供者连接信任。基于令牌的提供者连接信任：使用基于HTTP / 2的API的提供者可以使用
JSON web tokens （JWT）来提供与APNs连接的验证凭据。在此方案中，您可以配置Apple保留的公钥以及您保留和保护的私钥。然后，您的提供者使用您的私钥生成并签署JWT provider authentication tokens。每个推送通知请求都必须包含提供者身份验证令牌。
您可以在提供者和APNs之间使用单个基于令牌的连接，以便向您的在线developer account中列出其bundle ID的所有应用发送推送通知请求。
每个推送通知请求都会产生来自APNs的HTTP / 2响应，并向您的提供者返回成功或失败的详细信息。
-
Certificate-based provider connection trust - 基于证书的提供者连接信任。提供者可以使用唯一的提供者证书和私有加密密钥
provider certificate and private cryptographic key。 Apple在您的在线开发者帐户中建立推送服务时提供的提供者证书可识别一个topic，即您的某个应用的bundle ID。
您可以使用提供者和APNs之间基于证书的连接，将推送通知请求发送到您在在线开发人员帐户中配置证书时指定的一个应用程序。
重要：要使用APNs建立基于
HTTP / 2的TLS会话，必须确保在每个提供者上安装GeoTrust Global CA root certificate。 如果提供者正在运行macOS，则默认情况下此根证书位于密钥链中。 在其他系统上，此证书可能需要显式安装。 您可以从GeoTrust Root Certificates website下载此证书。 这是证书的直接链接direct link to the certificate。如果您使用旧版二进制接口到APNs，则必须确保每个提供者都有Entrust Certification Authority (2048)根证书，可从Entrust SSL Certificates website中获得。
(a) Token-Based Provider-to-APNs Trust - 基于token的提供者到APNs的信任
基于token的提供者信任使用“Apple推送通知身份验证密钥（沙箱和生产）Apple Push Notification Authentication Key (Sandbox & Production)”类型的证书。您使用在线开发人员帐户配置和获取此证书，如Xcode帮助中的Generate a universal provider token signing key中所述。该证书具有以下特征：
- 一个证书适用于为与您的帐户关联的每个应用发送推送通知请求。
该证书还适用于与您的应用程序的Apple Watch复杂功能的连接，以及适用于您的应用程序的互联网协议语音（VoIP）状态通知。即使这些项目在后台运行，APNs也会发送这些通知。有关详细信息，请参阅APNs Provider Certificates，并参考Energy Efficiency Guide for iOS Apps中的Voice Over IP (VoIP) Best Practices。
通过基于
JWT token的APNs连接发送推送通知请求时，必须包含提供者身份验证令牌。APNs身份验证密钥证书永不过期，但您可以使用在线开发者帐户永久撤消
revoked它；一旦撤销，证书永远不会再次使用
图6-3说明了使用基于HTTP / 2的APNs提供者API建立信任，以及使用JWT提供程序身份验证令牌发送通知。
如图6-3所示，基于令牌的提供者信任的工作原理如下：
您的提供者要求使用传输层安全性（TLS）与APNs进行安全连接，在图中标记为
TLS initiation的箭头。然后，APNs会向您的提供商提供APNs证书，该证书由图中的下一个箭头（标记为
APNs certificate）表示，然后您的提供商将对其进行验证。
此时，建立连接信任，并且您的提供程序服务器已启用，以向APNs发送基于令牌的远程推送通知请求。
您的提供商发送的每个通知请求必须附有JWT身份验证令牌，在图中表示为标记为Notification push的箭头。
- APNs回复每次推送，在图中表示为标记为
HTTP/2 response的箭头。
有关您的提供者可以在此步骤中收到的响应的详细信息，请参阅 HTTP/2 Response from APNs。
(b) Certificate-Based Provider-to-APNs Trust - 基于证书的提供者到APNs的信任
基于证书的提供程序连接对于传递到一个特定应用程序有效，该应用程序由提供程序证书中指定的topic（bundle ID）标识，（您必须先前已创建该证书，如在Xcode帮助中Generate a universal APNs client SSL certificate中所述））。根据您配置和配置证书的方式，可信连接也可用于将远程通知传递到与您的应用关联的其他项目，包括Apple Watch针对您的应用程序的复杂性以及用于互联网协议语音（VoIP）您的应用状态通知。即使这些项目在后台运行，APN也会发送这些通知。有关详细信息，请参阅Communicating with APNs，并参阅Energy Efficiency Guide for iOS Apps中的 Voice Over IP (VoIP) Best Practices。
通过基于证书的信任，APNs维护证书撤销列表；如果提供者的证书在撤销列表中，则APNs可以撤销提供者信任（即，APNs可以拒绝TLS发起连接）。
图6-4说明了使用Apple颁发的SSL证书在提供者和APNs之间建立信任。与图6-3不同，此图不显示通知推送本身，但在建立传输层安全性（TLS）连接时停止。在基于证书的信任方案中，推送通知请求未经过身份验证，但使用随附的device token对其进行验证。
如图6-4所示，基于证书的Provider-to-APNs信任的工作原理如下：
您的
provider要求使用传输层安全性（TLS）与APNs进行安全连接，在图中标记为TLS initiation的箭头。然后，APNs会向您的
provider提供APNs证书，该证书由图中的下一个箭头（标记为APNs certificate）表示，然后您的provider将对其进行验证。然后，您的
provider必须将其Apple配置的provider证书（您之前从在线开发者帐户获得的证书，如Xcode帮助中Generate a universal APNs client SSL certificate所述）发送回APNs，表示为标记为“提供商”的箭头证书。”然后，APN验证您的
provider证书，从而确认连接请求来自合法provider，并建立您的TLS连接。
此时，建立连接信任并启用provider服务器以向APNs发送基于证书的远程推送通知请求。
2. APNs-to-Device Connection Trust and Device Tokens - APNs-to-Device连接信任和Device Token
APNs和每个设备之间的信任是自动建立的，没有您的应用程序参与，如本节所述。
每个设备都有一个加密证书和一个私人加密密钥，由操作系统在初始设备激活时提供，并存储在设备的钥匙串中。 在激活过程中，APNs根据证书和密钥对设备的连接进行身份验证和验证，如图6-5所示。
如图6-5所示， APNs-to-device信任的工作原理如下：
- 当设备启动与APNs的TLS连接时，信任协商开始，如图中的顶部箭头所示。
- APNs将APNs证书返回给设备。
- 操作系统验证此证书，然后如
Device certificate箭头所示，将设备证书发送到APNs。 - 最后，如图中的下箭头所示，APNs验证设备证书，建立信任。
通过在APNs和设备之间建立TLS连接，设备上的应用程序可以向APNs注册以接收其特定于应用程序的device token以进行远程通知。有关详细信息和代码示例，请参阅Configuring Remote Notification Support中的Registering to Receive Remote Notifications。
收到device token后，应用程序必须连接到应用程序的关联提供程序并将token转发给它。此步骤是必需的，因为提供商必须在以后向APNs发送通知请求时包含device token，并定位设备。您为转发token而编写的代码也显示在Registering to Receive Remote Notifications中。
无论用户是第一次激活设备，还是APNs是否已发出新的device token，该过程都类似，如图6-6所示。
获取和处理特定于应用程序的device token的工作方式如下：
- 1）您的应用程序向APNs注册以进行远程通知，如上箭头所示。如果应用程序已注册且特定于应用程序的设备令牌未更改，则系统会将现有令牌快速返回到应用程序，此过程将跳至步骤4。
- 2）当需要新的设备令牌时，APNs使用设备证书中包含的信息生成一个令牌。它使用令牌密钥加密令牌并将其返回到设备，如中间的右箭头所示。
- 3）系统通过调用您的application:didRegisterForRemoteNotificationsWithDeviceToken:方法将
device token传递给你的App。 - 4）收到token后，您的应用程序（在委托方法中）必须以二进制或十六进制格式将其转发给您的提供程序。如果没有此令牌，您的提供商无法向设备发送通知。有关详细信息，请参阅 Configuring Remote Notification Support中的 Registering to Receive Remote Notifications。
重要：APNs设备令牌的长度可变。 不要硬编码他们的大小。
当您的提供者向APNs发送推送通知请求时，它包含一个设备令牌，用于标识唯一的应用设备组合。 此步骤显示在图6-7中provider和APNs之间的Token, Payload箭头中。 APNs解密令牌以确保请求的有效性并确定目标设备。 如果APNs确定发件人和收件人是合法的，则它会将通知发送到所标识的设备。
设备收到通知后（在图6-7中显示的最后一步之后），系统会将远程通知转发给您的应用。
Provisioning Procedures - Provisioning程序
APNs适用于通过iOS App Store，tvOS App Store和Mac App Store分发的应用程序，以及企业应用程序。 您的应用必须配置并进行代码签名才能使用APNs。 如果您是作为团队的一员开发的，那么大多数配置步骤只能由团队代理或管理员执行。
有关如何在Xcode和在线developer account帐户中配置推送通知支持的信息，请阅读Xcode帮助中的Configure push notifications。
后记
本篇主要讲述了APNs概览，感兴趣的给个赞或者关注~~~~
