版本記錄

前言

我們做APP很多時(shí)候都需要推送功能找岖，以直播為例嫉晶，如果你關(guān)注的主播開播了骑疆，那么就需要向關(guān)注這個主播的人發(fā)送開播通知，提醒用戶去看播替废，這個只是一個小的方面箍铭，具體應(yīng)用根據(jù)公司的業(yè)務(wù)邏輯而定。前面已經(jīng)花了很多篇幅介紹了極光推送椎镣，其實(shí)極光推送無非就是將我們客戶端和服務(wù)端做的很多東西封裝了一下诈火，節(jié)省了我們很多處理邏輯和流程，這一篇開始状答，我們就利用系統(tǒng)的原生推送類結(jié)合工程實(shí)踐說一下系統(tǒng)推送的集成冷守，希望我的講解能讓大家很清楚的理解它。感興趣的可以看上面幾篇惊科。
1. 系統(tǒng)推送的集成（一） —— 基本集成流程（一）
2. 系統(tǒng)推送的集成（二） —— 推送遇到的幾個坑之BadDeviceToken問題（一）
3. 系統(tǒng)推送的集成（三） —— 本地和遠(yuǎn)程通知編程指南之你的App的通知 - 本地和遠(yuǎn)程通知概覽（一）
4. 系統(tǒng)推送的集成（四） —— 本地和遠(yuǎn)程通知編程指南之你的App的通知 - 管理您的應(yīng)用程序的通知支持（二）
5. 系統(tǒng)推送的集成（五） —— 本地和遠(yuǎn)程通知編程指南之你的App的通知 - 調(diào)度和處理本地通知（三）
6. 系統(tǒng)推送的集成（六） —— 本地和遠(yuǎn)程通知編程指南之你的App的通知 - 配置遠(yuǎn)程通知支持（四）
7. 系統(tǒng)推送的集成（七） —— 本地和遠(yuǎn)程通知編程指南之你的App的通知 - 修改和顯示通知（五）

APNs Overview - APNs概覽

Apple推送通知服務(wù)（APNs）是遠(yuǎn)程通知功能的核心教沾。 它是一種強(qiáng)大，安全且高效的服務(wù)译断，可供應(yīng)用程序開發(fā)人員將信息傳播到iOS（以及間接的watchOS），tvOS和macOS設(shè)備或悲。

在用戶設(shè)備上首次啟動應(yīng)用程序時(shí)孙咪，系統(tǒng)會自動在您的應(yīng)用程序和APNs之間建立經(jīng)過認(rèn)證，加密且持久的IP連接巡语。 此連接允許您的應(yīng)用執(zhí)行設(shè)置以使其能夠接收通知翎蹈，如Configuring Remote Notification Support中所述。

用于發(fā)送通知的另一半連接 - 提供服務(wù)器和APNs之間的持久安全通道 - 需要在您的在線developer account中進(jìn)行配置以及使用Apple提供的加密證書男公。 提供程序是您配置為使用APNs的部署和管理的服務(wù)器荤堪。 圖6-1顯示了遠(yuǎn)程通知的傳遞路徑。

Figure 6-1 Delivering a remote notification from a provider to an app

通過在您的提供者和應(yīng)用程序中完成推送通知設(shè)置枢赔，您的提供商可以向APNs發(fā)送通知請求澄阳。 APN向每個目標(biāo)設(shè)備傳送相應(yīng)的通知有效載荷。 收到通知后踏拜，系統(tǒng)會將有效負(fù)載傳送到設(shè)備上的相應(yīng)應(yīng)用程序碎赢，并管理與用戶的交互。

如果應(yīng)用程序的通知在設(shè)備啟動但應(yīng)用程序未運(yùn)行時(shí)到達(dá)速梗，系統(tǒng)仍可顯示通知肮塞。 如果在APNs發(fā)送通知時(shí)設(shè)備已關(guān)閉襟齿，則APNs會保留通知并稍后再次嘗試（有關(guān)詳細(xì)信息，請參閱 Quality of Service, Store-and-Forward, and Coalesced Notifications）枕赵。

Provider Responsibilities - 提供者責(zé)任

您的提供商服務(wù)器對參與APNs具有以下責(zé)任：

• 通過APNs從用戶設(shè)備上的應(yīng)用實(shí)例接收全球唯一的應(yīng)用專用device token和其他相關(guān)數(shù)據(jù)猜欺。這允許提供者了解您的應(yīng)用程序的每個運(yùn)行實(shí)例。
• 根據(jù)通知系統(tǒng)的設(shè)計(jì)確定何時(shí)需要將遠(yuǎn)程通知發(fā)送到每個設(shè)備拷窜。
• 建立并向APNs發(fā)送通知請求开皿，每個請求包含通知有效載荷和傳遞信息；然后装黑，APNs代表您向目標(biāo)設(shè)備發(fā)送相應(yīng)的通知副瀑。

對于提供者發(fā)送的每個遠(yuǎn)程通知請求，它必須：

• 構(gòu)造包含通知有效負(fù)載的JSON字典恋谭，如Creating the Remote Notification Payload中所述糠睡。
• 將有效負(fù)載，全局唯一設(shè)備令牌和其他傳遞信息添加到HTTP / 2請求疚颊。有關(guān)設(shè)備令牌的信息狈孔，請參閱APNs-to-Device Connection Trust and Device Tokens。有關(guān)HTTP / 2請求格式以及APNs可能的響應(yīng)和錯誤的信息材义，請參閱Communicating with APNs均抽。
• 通過持久的安全通道將HTTP / 2請求發(fā)送到APNs，包括令牌或證書形式的加密憑證其掂。 Security Architecture中描述了建立此安全通道油挥。

Using Multiple Providers - 使用多個提供者

圖6-2描述了APNs為運(yùn)行應(yīng)用程序的設(shè)備啟用的虛擬網(wǎng)絡(luò)類型。 要處理通知負(fù)載款熬，您通常會部署多個提供者深寥，每個提供者都有自己的與APNs持久且安全的連接。 然后贤牛，每個提供者可以發(fā)送針對提供者具有有效device token的任何設(shè)備的通知請求惋鹅。

Figure 6-2 Pushing remote notifications from multiple providers to multiple devices

Quality of Service, Store-and-Forward, and Coalesced Notifications - 服務(wù)質(zhì)量，存儲轉(zhuǎn)發(fā)和合并通知

Apple推送通知服務(wù)包括執(zhí)行存儲轉(zhuǎn)發(fā)功能的服務(wù)質(zhì)量（QoS）組件殉簸。如果APNs嘗試發(fā)送通知并且目標(biāo)設(shè)備處于脫機(jī)狀態(tài)闰集，則APNs會將通知存儲一段有限的時(shí)間，并在設(shè)備再次可用時(shí)將其發(fā)送般卑。此組件僅存儲每個設(shè)備和每個應(yīng)用程序的最新通知武鲁。如果設(shè)備處于脫機(jī)狀態(tài)，則發(fā)送針對該設(shè)備的通知請求會導(dǎo)致先前的請求被丟棄蝠检。如果設(shè)備長時(shí)間保持脫機(jī)狀態(tài)洞坑，則會丟棄其在APNs中存儲的所有通知。

要允許合并類似通知蝇率，您可以在通知請求中包含折疊標(biāo)識符collapse identifier迟杂。通常刽沾，當(dāng)設(shè)備在線時(shí)，您發(fā)送到APNs的每個通知請求都會導(dǎo)致向設(shè)備發(fā)送通知排拷。但是侧漓，當(dāng)HTTP / 2請求標(biāo)頭中存在apns-collapse-id密鑰時(shí)，APNs會合并其密鑰值相同的請求监氢。例如布蔗，兩次發(fā)送相同標(biāo)題的新聞服務(wù)可以對兩個請求使用相同的折疊標(biāo)識符值。然后浪腐，APNs將這兩個請求合并為一個通知纵揍，以便傳送到設(shè)備。有關(guān)apns-collapse-id密鑰的詳細(xì)信息议街，請參見Table 8-2泽谨。

Security Architecture - 安全架構(gòu)

APNs使用兩個信任級別強(qiáng)制執(zhí)行端到端加密驗(yàn)證和身份驗(yàn)證：連接信任和設(shè)備令牌信任connection trust and device token trust。

連接信任在提供者和APNs之間以及APNs和設(shè)備之間起作用特漩。

• Provider-to-APNs connection trust - 提供者到APNs的連接信任吧雹。提供者到APNs的連接信任確定了提供者和APNs之間的連接只能由授權(quán)提供者實(shí)現(xiàn)，該授權(quán)提供商由與Apple達(dá)成推送通知傳送協(xié)議的公司所有涂身。您必須采取措施確保提供者服務(wù)器和APNs之間存在連接信任雄卷，如本節(jié)所述。

• APNs-to-device connection trust - APNs到設(shè)備的連接信任 蛤售。APNs到設(shè)備的連接信任確保只有授權(quán)設(shè)備才能連接到APNs以接收通知丁鹉。 APNs自動強(qiáng)制與每個設(shè)備建立連接信任，以確保設(shè)備的合法性悴能。

對于提供者與APNs進(jìn)行通信揣钦，它必須使用有效的身份驗(yàn)證密鑰證書（用于基于token的連接信任）或SSL證書（用于基于證書的連接信任）。您可以從在線developer account中獲取這些證書中的任何一個搜骡，如Xcode幫助中的Configure push notifications中所述。要在兩種證書類型之間進(jìn)行選擇佑女，請閱讀Provider-to-APNs Connection Trust.记靡。無論您選擇哪種證書類型，提供者連接信任都是提供者向APNs發(fā)送推送通知請求的先決條件团驱。

Device token信任對每個遠(yuǎn)程通知都是端到端的摸吠。它確保僅在正確的開始（提供者）和結(jié)束（設(shè)備）點(diǎn)之間路由通知。

device token是一個不透明的NSData實(shí)例嚎花，其中包含Apple為特定設(shè)備上的特定應(yīng)用程序分配的唯一標(biāo)識符寸痢。 只有APNs可以解碼和讀取設(shè)備令牌的內(nèi)容。 每個應(yīng)用程序?qū)嵗谙駻PNs注冊時(shí)都會收到其唯一的device token紊选，然后必須將令牌轉(zhuǎn)發(fā)給其提供者啼止，如Configuring Remote Notification Support中所述道逗。 提供者必須在每個推送通知請求中包含設(shè)備令牌，該請求以相關(guān)設(shè)備為目標(biāo)献烦；APNs使用設(shè)備令牌來確保通知僅傳遞給其預(yù)期的唯一應(yīng)用程序設(shè)備組合蚊锹。

APNs可以出于各種原因發(fā)布新的device token：

• 用戶在新設(shè)備上安裝您的應(yīng)用
• 用戶從備份恢復(fù)設(shè)備
• 用戶重新安裝操作系統(tǒng)
• 其他系統(tǒng)定義的事件

因此钳垮，應(yīng)用程序必須在啟動時(shí)請求設(shè)備令牌，如APNs-to-Device Connection Trust and Device Tokens中所述。 有關(guān)代碼示例掸刊，請參閱Registering to Receive Remote Notifications。

重要：為保護(hù)用戶隱私挤渐，請勿使用device token來識別用戶設(shè)備阵翎。

1. Provider-to-APNs Connection Trust - 提供者和APNs連接信任

有兩種方案可用于協(xié)商提供者服務(wù)器與Apple推送通知服務(wù)之間的連接信任：

• Token-based provider connection trust - 基于令牌的提供者連接信任《簦基于令牌的提供者連接信任：使用基于HTTP / 2的API的提供者可以使用JSON web tokens （JWT）來提供與APNs連接的驗(yàn)證憑據(jù)跺嗽。在此方案中，您可以配置Apple保留的公鑰以及您保留和保護(hù)的私鑰舔庶。然后抛蚁，您的提供者使用您的私鑰生成并簽署JWT provider authentication tokens。每個推送通知請求都必須包含提供者身份驗(yàn)證令牌惕橙。

您可以在提供者和APNs之間使用單個基于令牌的連接瞧甩，以便向您的在線developer account中列出其bundle ID的所有應(yīng)用發(fā)送推送通知請求。

每個推送通知請求都會產(chǎn)生來自APNs的HTTP / 2響應(yīng)弥鹦，并向您的提供者返回成功或失敗的詳細(xì)信息肚逸。

• Certificate-based provider connection trust - 基于證書的提供者連接信任。提供者可以使用唯一的提供者證書和私有加密密鑰provider certificate and private cryptographic key彬坏。 Apple在您的在線開發(fā)者帳戶中建立推送服務(wù)時(shí)提供的提供者證書可識別一個topic朦促，即您的某個應(yīng)用的bundle ID。

您可以使用提供者和APNs之間基于證書的連接栓始，將推送通知請求發(fā)送到您在在線開發(fā)人員帳戶中配置證書時(shí)指定的一個應(yīng)用程序务冕。

重要：要使用APNs建立基于HTTP / 2的TLS會話，必須確保在每個提供者上安裝GeoTrust Global CA root certificate幻赚。 如果提供者正在運(yùn)行macOS禀忆，則默認(rèn)情況下此根證書位于密鑰鏈中。 在其他系統(tǒng)上落恼，此證書可能需要顯式安裝箩退。 您可以從GeoTrust Root Certificates website下載此證書。 這是證書的直接鏈接direct link to the certificate佳谦。如果您使用舊版二進(jìn)制接口到APNs戴涝，則必須確保每個提供者都有Entrust Certification Authority (2048)根證書，可從Entrust SSL Certificates website中獲得。

(a) Token-Based Provider-to-APNs Trust - 基于token的提供者到APNs的信任

基于token的提供者信任使用“Apple推送通知身份驗(yàn)證密鑰（沙箱和生產(chǎn)）Apple Push Notification Authentication Key (Sandbox & Production)”類型的證書啥刻。您使用在線開發(fā)人員帳戶配置和獲取此證書奸鸯，如Xcode幫助中的Generate a universal provider token signing key中所述。該證書具有以下特征：

• 一個證書適用于為與您的帳戶關(guān)聯(lián)的每個應(yīng)用發(fā)送推送通知請求郑什。

該證書還適用于與您的應(yīng)用程序的Apple Watch復(fù)雜功能的連接府喳，以及適用于您的應(yīng)用程序的互聯(lián)網(wǎng)協(xié)議語音（VoIP）狀態(tài)通知。即使這些項(xiàng)目在后臺運(yùn)行蘑拯，APNs也會發(fā)送這些通知钝满。有關(guān)詳細(xì)信息，請參閱APNs Provider Certificates申窘，并參考Energy Efficiency Guide for iOS Apps中的Voice Over IP (VoIP) Best Practices弯蚜。

• 通過基于JWT token的APNs連接發(fā)送推送通知請求時(shí)，必須包含提供者身份驗(yàn)證令牌剃法。

• APNs身份驗(yàn)證密鑰證書永不過期碎捺，但您可以使用在線開發(fā)者帳戶永久撤消revoked它；一旦撤銷贷洲，證書永遠(yuǎn)不會再次使用

圖6-3說明了使用基于HTTP / 2的APNs提供者API建立信任收厨，以及使用JWT提供程序身份驗(yàn)證令牌發(fā)送通知。

Figure 6-3 Establishing and using token-based provider connection trust

如圖6-3所示优构，基于令牌的提供者信任的工作原理如下：

• 您的提供者要求使用傳輸層安全性（TLS）與APNs進(jìn)行安全連接诵叁，在圖中標(biāo)記為TLS initiation的箭頭。

• 然后钦椭，APNs會向您的提供商提供APNs證書拧额，該證書由圖中的下一個箭頭（標(biāo)記為APNs certificate）表示，然后您的提供商將對其進(jìn)行驗(yàn)證彪腔。

此時(shí)侥锦，建立連接信任，并且您的提供程序服務(wù)器已啟用德挣，以向APNs發(fā)送基于令牌的遠(yuǎn)程推送通知請求恭垦。

您的提供商發(fā)送的每個通知請求必須附有JWT身份驗(yàn)證令牌，在圖中表示為標(biāo)記為Notification push的箭頭格嗅。

• APNs回復(fù)每次推送番挺，在圖中表示為標(biāo)記為HTTP/2 response的箭頭。

有關(guān)您的提供者可以在此步驟中收到的響應(yīng)的詳細(xì)信息吗浩，請參閱 HTTP/2 Response from APNs建芙。

(b) Certificate-Based Provider-to-APNs Trust - 基于證書的提供者到APNs的信任

基于證書的提供程序連接對于傳遞到一個特定應(yīng)用程序有效没隘，該應(yīng)用程序由提供程序證書中指定的topic（bundle ID）標(biāo)識懂扼，（您必須先前已創(chuàng)建該證書，如在Xcode幫助中Generate a universal APNs client SSL certificate中所述））。根據(jù)您配置和配置證書的方式阀湿，可信連接也可用于將遠(yuǎn)程通知傳遞到與您的應(yīng)用關(guān)聯(lián)的其他項(xiàng)目赶熟，包括Apple Watch針對您的應(yīng)用程序的復(fù)雜性以及用于互聯(lián)網(wǎng)協(xié)議語音（VoIP）您的應(yīng)用狀態(tài)通知。即使這些項(xiàng)目在后臺運(yùn)行陷嘴，APN也會發(fā)送這些通知映砖。有關(guān)詳細(xì)信息，請參閱Communicating with APNs灾挨，并參閱Energy Efficiency Guide for iOS Apps中的 Voice Over IP (VoIP) Best Practices邑退。

通過基于證書的信任，APNs維護(hù)證書撤銷列表劳澄；如果提供者的證書在撤銷列表中地技，則APNs可以撤銷提供者信任（即，APNs可以拒絕TLS發(fā)起連接）秒拔。

圖6-4說明了使用Apple頒發(fā)的SSL證書在提供者和APNs之間建立信任莫矗。與圖6-3不同，此圖不顯示通知推送本身砂缩，但在建立傳輸層安全性（TLS）連接時(shí)停止作谚。在基于證書的信任方案中，推送通知請求未經(jīng)過身份驗(yàn)證庵芭，但使用隨附的device token對其進(jìn)行驗(yàn)證妹懒。

Figure 6-4 Establishing certificate-based provider connection trust

如圖6-4所示，基于證書的Provider-to-APNs信任的工作原理如下：

• 您的provider要求使用傳輸層安全性（TLS）與APNs進(jìn)行安全連接喳挑，在圖中標(biāo)記為TLS initiation的箭頭彬伦。

• 然后，APNs會向您的provider提供APNs證書伊诵，該證書由圖中的下一個箭頭（標(biāo)記為APNs certificate）表示单绑，然后您的provider將對其進(jìn)行驗(yàn)證。

• 然后曹宴，您的provider必須將其Apple配置的provider證書（您之前從在線開發(fā)者帳戶獲得的證書搂橙，如Xcode幫助中Generate a universal APNs client SSL certificate所述）發(fā)送回APNs，表示為標(biāo)記為“提供商”的箭頭證書笛坦∏”

• 然后，APN驗(yàn)證您的provider證書版扩，從而確認(rèn)連接請求來自合法provider废离，并建立您的TLS連接。

此時(shí)礁芦，建立連接信任并啟用provider服務(wù)器以向APNs發(fā)送基于證書的遠(yuǎn)程推送通知請求蜻韭。

2. APNs-to-Device Connection Trust and Device Tokens - APNs-to-Device連接信任和Device Token

APNs和每個設(shè)備之間的信任是自動建立的悼尾，沒有您的應(yīng)用程序參與，如本節(jié)所述肖方。

每個設(shè)備都有一個加密證書和一個私人加密密鑰闺魏，由操作系統(tǒng)在初始設(shè)備激活時(shí)提供，并存儲在設(shè)備的鑰匙串中俯画。 在激活過程中析桥，APNs根據(jù)證書和密鑰對設(shè)備的連接進(jìn)行身份驗(yàn)證和驗(yàn)證，如圖6-5所示艰垂。

Figure 6-5 Establishing connection trust between a device and APNs

如圖6-5所示泡仗， APNs-to-device信任的工作原理如下：

• 當(dāng)設(shè)備啟動與APNs的TLS連接時(shí)，信任協(xié)商開始猜憎，如圖中的頂部箭頭所示沮焕。
• APNs將APNs證書返回給設(shè)備。
• 操作系統(tǒng)驗(yàn)證此證書拉宗，然后如Device certificate箭頭所示峦树，將設(shè)備證書發(fā)送到APNs。
• 最后旦事，如圖中的下箭頭所示魁巩，APNs驗(yàn)證設(shè)備證書，建立信任姐浮。

通過在APNs和設(shè)備之間建立TLS連接谷遂，設(shè)備上的應(yīng)用程序可以向APNs注冊以接收其特定于應(yīng)用程序的device token以進(jìn)行遠(yuǎn)程通知。有關(guān)詳細(xì)信息和代碼示例卖鲤，請參閱Configuring Remote Notification Support中的Registering to Receive Remote Notifications肾扰。

收到device token后，應(yīng)用程序必須連接到應(yīng)用程序的關(guān)聯(lián)提供程序并將token轉(zhuǎn)發(fā)給它蛋逾。此步驟是必需的集晚，因?yàn)樘峁┥瘫仨氃谝院笙駻PNs發(fā)送通知請求時(shí)包含device token，并定位設(shè)備区匣。您為轉(zhuǎn)發(fā)token而編寫的代碼也顯示在Registering to Receive Remote Notifications中偷拔。

無論用戶是第一次激活設(shè)備，還是APNs是否已發(fā)出新的device token亏钩，該過程都類似莲绰，如圖6-6所示。

Figure 6-6 Managing the device token

獲取和處理特定于應(yīng)用程序的device token的工作方式如下：

• 1）您的應(yīng)用程序向APNs注冊以進(jìn)行遠(yuǎn)程通知姑丑，如上箭頭所示蛤签。如果應(yīng)用程序已注冊且特定于應(yīng)用程序的設(shè)備令牌未更改，則系統(tǒng)會將現(xiàn)有令牌快速返回到應(yīng)用程序栅哀，此過程將跳至步驟4震肮。
• 2）當(dāng)需要新的設(shè)備令牌時(shí)踏枣，APNs使用設(shè)備證書中包含的信息生成一個令牌。它使用令牌密鑰加密令牌并將其返回到設(shè)備钙蒙，如中間的右箭頭所示。
• 3）系統(tǒng)通過調(diào)用您的application:didRegisterForRemoteNotificationsWithDeviceToken:方法將device token傳遞給你的App间驮。
• 4）收到token后躬厌，您的應(yīng)用程序（在委托方法中）必須以二進(jìn)制或十六進(jìn)制格式將其轉(zhuǎn)發(fā)給您的提供程序。如果沒有此令牌竞帽，您的提供商無法向設(shè)備發(fā)送通知扛施。有關(guān)詳細(xì)信息，請參閱 Configuring Remote Notification Support中的 Registering to Receive Remote Notifications屹篓。

重要：APNs設(shè)備令牌的長度可變疙渣。 不要硬編碼他們的大小。

當(dāng)您的提供者向APNs發(fā)送推送通知請求時(shí)堆巧，它包含一個設(shè)備令牌妄荔，用于標(biāo)識唯一的應(yīng)用設(shè)備組合。 此步驟顯示在圖6-7中provider和APNs之間的Token, Payload箭頭中谍肤。 APNs解密令牌以確保請求的有效性并確定目標(biāo)設(shè)備啦租。 如果APNs確定發(fā)件人和收件人是合法的，則它會將通知發(fā)送到所標(biāo)識的設(shè)備荒揣。

Figure 6-7 Remote notification path from provider to device

設(shè)備收到通知后（在圖6-7中顯示的最后一步之后）篷角，系統(tǒng)會將遠(yuǎn)程通知轉(zhuǎn)發(fā)給您的應(yīng)用。

Provisioning Procedures - Provisioning程序

APNs適用于通過iOS App Store系任，tvOS App Store和Mac App Store分發(fā)的應(yīng)用程序恳蹲，以及企業(yè)應(yīng)用程序。 您的應(yīng)用必須配置并進(jìn)行代碼簽名才能使用APNs俩滥。 如果您是作為團(tuán)隊(duì)的一員開發(fā)的嘉蕾，那么大多數(shù)配置步驟只能由團(tuán)隊(duì)代理或管理員執(zhí)行。

有關(guān)如何在Xcode和在線developer account帳戶中配置推送通知支持的信息霜旧，請閱讀Xcode幫助中的Configure push notifications荆针。

后記

本篇主要講述了APNs概覽，感興趣的給個贊或者關(guān)注~~~~