iOS APNs實戰分享

序言：

由於App的功能須要，最近一直在調研蘋果的APNs推送，開始時以爲超麻煩，如今感受仍是比較easy，「難者不會，會者不難」，本身踩過了這麼多的坑終於會了，不出來吐槽（裝X）一下對不起本身，23333。

在測試發送APNs消息的時候，須要寫服務器代碼給蘋果服務器發消息，本人做爲一個純iOS開發者，對服務器代碼十竅通九竅，還好如今網上不少第三方提供這個功能，由於咱們公司使用的是個推，就直接使用個推提供的功能測試了，不須要我來寫服務端代碼真爽。

準備工做：

一、蘋果開發許可證書，分爲:開發證書 (iOS App Development)、生產證書(App Store and Ad Hoc)等，後面我使用的是開發證書進行測試。

二、蘋果開發者網站上註冊「AppIDs」，我使用的是「com.crazywolf.yewan」， 勾選「Push No-tifications」。

三、真機，須要添加到開發許可設備中。

四、Provisioning Profiles文件，分:開發時使用(iOS App Development)、生產時使用(App Store、Ad Hoc)等，我在後面使用的是「Development」。

五、蘋果APNs推送證書，分：開發環境證書 (Development)、生產環境證書（Production）等，一樣，也是使用「Development」，注意使用個推平臺APNs推送需上傳該推送證書，這裏我將導出的開發環境證書提交個推平臺，關於證書生產和導出能夠查看個推 APNs配置技術文檔（http://docs.getui.com/mobile/...）。

六、Xcode8.2（不一樣版本在配置時有點不一樣），最低支持版本iOS 8.0。

 
一：註冊APNs、獲取DeviceToken

一、建立新項目或修改老項目，配置項目

二、註冊APNs，獲取DeviceToken

三、使用個推的測試一下，測試DeviceToken

是否是很簡單，這樣就能夠獲取到APNs推送消息了，有沒有一種成功感，不過我開始獲取DeviceToken時，一直報（「Error Domain=NSCocoaErrorDomain Code=3000 "未找到應用程序的「aps-environment」的受權字符串" UserInfo={NSLocalizedDescription=未找到應用程序的「aps-environment」的受權字符串}」）錯誤，網上說是證書沒配置好，我從新配置了屢次證書仍是不行，後來問了個推的技術支持才知道Xcode8以上版本須要打開「TARGETS - Capabilities - Push Notifi-cations」，個推的集成文檔中也有寫，本身太粗心了。

四、APNs環境問題

注意保持推送APNs環境和你的App推送環境一致，由於常常有人會把證書環境搞錯，致使推送收不到。

1）直接使用Xcode直接運行到手機上，能夠根據「TARGETS -> General -> Signing」中「Provisioning Profile」和「Signing Certificate」來確認。例以下圖：

分享一下，我在給「Provisioning Profile」文件命名時有個習慣，以「Dev: 」（開發環境）、「In House: 」（企業包環境）、「XC Ad Hoc: 」（分發包環境）、「XC: 」（App Store），其中後面三個都是生產環境。

2）打包成 ipa 包安裝到iPhone上，可能會忘記打包時的配置或者是其餘人發你的包，是否是就不能知道APNs的環境了？ 很早以前個人方法是獲取App的 DeviceToken，使用開發和生產環境APNs證書都推送一下，看看是哪一個能推送到。後來發現了還有其餘方法的，那就是解析ipa包：

1）先解壓ipa包，找到.app文件，顯示包內容

2）找到.mobileprovision文件，使用「Atom」打開.mobileprovision文件

3）查找「aps-environment」，查看「aps-environment」這個key值對應value，「development」表示開發環境，「production」表示生產環境。以下圖：

二：正式推送APNs，推送咱們須要的信息

一、集成個推SDK

二、使用個推網站上的「透傳消息」下發

這樣就能夠推送自定義消息內容到iPhone上了，到這裏APNs的功能已經所有完成了，後面就要看看具體需求了，將個推的服務端集成部分發給大家服務端開發人員，讓他「碼」起來了，若是有問題，讓他們聯繫個推的技術支持，2333。

三、APNs消息統計

個推最新版本1.5.3 iOS SDK添加了「iOS 10 APNs展現統計」功能，該功能使用到了iOS10 新特性須要添加NotificationService 擴展模塊，能準確統計到 iOS10 以上 APNs 展現信息，這個功能太爽了，APNs 展現數據沒法統計是多少開發者及運營的痛啊，相信有了這個功能能更好的跟蹤APNs推送到達狀況。具體集成步驟能夠查看「http://docs.getui.com/mobile/...」。
推送成功後能夠在個推後臺進行查看推送狀況， 如圖：

個推渠道下發仍是區分蠻清晰的， 個推成功下發爲經過個推通道進行下發， APNs成功下發模塊爲離線後，走APNs通道下發， 其中上面說的展現統計數據就是 APNs模塊中的展現數了。 用戶量有點小，別介意哈 zZZ。

四、回調方法區別

APNs的消息在App不一樣狀態、APNs消息內容、通知操做不一樣、iOS系統版本不一樣，回調方法也不一樣，下面這張圖片是上次諮詢個推時，個推的技術人員發個人，能夠參考看看，注意使用時要測試一下，防止蘋果系統又變化了：

個推的透傳消息能夠經過方法（「GeTuiSdkDidReceivePayloadData: andTaskId: andMsgId: andOffLine: fromGtAppId: 」）回調獲取，由於蘋果的APNs推送不保證是否到達和到達時間，因此就可能會丟失，使用個推的透傳方法相對APNs更能保證消息的到達率。

說到這裏不得不說一下個推的推送機制了，在咱們服務端給個推服務器推送消息時，個推服務器會檢查推送對象是否在線（應該是根據個推SDK和個推服務器心跳包和網絡鏈接判斷的，超過必定時間沒有收到心跳包就是「不在線」，不過這種作法可能會出現假在線狀況，就是突然斷網，在服務器下次檢測心跳包的期間，服務器會認爲對象在線）：

1）對象在線：下發個推的透傳消息，不發送APNs推送消息。
2）對象離線：下發個推的透傳消息，發送APNs推送消息。
從上面能夠看得出，個推的透傳消息是每次都下發的，這樣也保證的個推的消息到達率，不過這種作法會出現消息重複，例如是收到消息彈框提醒用戶操做，個推透傳消息和APNs推送消息都收到了，處理很差的話會提醒用戶二次同樣的消息。

這裏比較好的是個推在透傳消息方法中提供了「offLine」字段，這個值是「YES」時，表示這是一條離線消息，在下發個推透傳消息時，也發送了APNs推送消息，在處理消息時能夠忽略，若是消息的重要性不是很高，能夠這麼作，由於在忽略個推的透傳消息後APNs消息也沒有收到，就致使該條消息丟失。
另一種處理方式：參照網上的一些解決方法，我創建一個配置表，處理過的數據在表中標註，防止APNs和個推的透傳方法消息重複操做。
五、個推透傳消息注意點

圖一

圖二

上面二張圖，第一張是個推網站下發透傳消息時的界面，第二張是個推透傳消息回調方法。須要特別注意的是第一張圖中最下面的「payload」和個推透傳方法中「payloadData」，這二箇中不是同一個概念。

「payload」 是個推自定義字段，添加在APNs的消息內容中，不是蘋果原生字段，會經過APNs推送消息一併下發到iPhone客戶端，結構如上圖中代碼塊展現，這個字段通常是在APNs消息中添加附帶消息，例如附帶一個酒吧網站url，在收到通知消息是，發現是url，App直接打開這個網址。
「payloadData」是該條透傳消息內容，對應圖上的「消息內容」，這個字段不會經過APNs推送到iPhone客戶端，是經過個推服務器直接下發給個推SDK的。固然你也能夠將「消息內容」和「payload」設置成同樣的，這個就看大家的具體使用狀況來定了。

再說說第一張中「*拆分Android和iOS推送任務」，選擇「是」的話，會拆分Android和iOS推送任務後，將生成兩個taskid，分別對android和ios推送數據進行統計和展現，方便以後查詢推送數據統計。

最後一個比較實用的就是個推的「高級通知」，以下圖，將APNs推送中的字段都列舉出來了，不要開發者特地記APNs中有哪些字段，方便一些對APNs還不是很熟悉的初學者使用，固然不包括我了，哈哈哈哈。

六、發佈到AppStore注意點

App發佈到AppStore時，須要更換APNs證書或者更換App中個推AppId，由於個推的網站中只能上傳一個證書，開發時上傳的都是開發APNs證書，當開發測試完成後，準備發佈時，App須要生產環境的APNs證書，這時有二種方案可使用：

1）建立二套個推AppId：這種方案是在個推網站中添加二個應用，一個用於開發、一個用於發佈，在開發測試期間使用開發的個推AppId，在發佈時使用發佈的個推AppId，這種方案須要注意發佈時切換AppId，忘記換就GG，第一次發佈還好，兩個個推AppId的做用互換一下就能夠了，若是是更新發布，那隻能從新提交蘋果審覈了。

2）更換APNs證書：這種方案是在發佈時從新上傳生產APNs證書，注意個推的證書更換後須要10分鐘左右生效，這種方案須要注意在以後版本更新開發時，須要申請新的個推AppId，否則會影響在線的客戶。

我使用的是第一種方案，使用二套個推AppId，個推的文檔中也是推薦使用第一種方案。

三：公司服務器本身推送和使用個推推送的流程差別

一、公司服務器本身推送（簡稱：本身推送）流程

1）註冊APNs，獲取DeviceToken

2）將DeviceToken和用戶ID綁定，保存服務器

3）推送時，根據用戶ID獲取到DeviceToken，將消息內容、DeviceToken和APNs推送證書發送給蘋果服務器

二、使用個推推送流程

1）註冊APNs，獲取DeviceToken

2）集成個推SDK，獲取ClientId，綁定ClientId和DeviceToken

3）將ClientId和用戶ID綁定，保存服務器

4）推送時，根據用戶ID獲取到ClientId, 將消息內容和ClientId發送給個推服務器

四：本身推送和第三方對比

一、成本：本身推送須要專人進行開發，而且須要必定數量的服務器和帶寬支持，在開發完成後的使用過程當中還須要有專人進行維護。使用第三方推送，只須要集成SDK就能夠實現功能，不只減少了開發成本與維護成本，甚至在推送穩定性上第三方也會比本身作的推送更好一些。

二、精準推送：能夠將針對內容及標籤等信息進行精準推送，好比將杭州的新聞推送給杭州用戶，本身推送須要額外開發，而第三方大部分已經支持這樣的功能。

三、推送統計：本身推送仍是須要額外開發該功能，而第三方基本都必備該功能，相對來講就我如今使用的個推統計效果仍是使人滿意的，區分在線下發和APNs下發統計功能，支持通知的展現統計和點擊統計，能夠知道真實的下發量，下發後有多少被展現了，有多少被點擊了。

四、可控性：使用第三方推送可控性過低，想一想，若是第三方推送廠商宕機、或者被黑客攻擊了，你服務無法推送了，須要等待第三方廠商響應，或者第三方廠商出問題了，也會影響你的推送。因此那些痛的經驗告訴咱們要選擇家專業作推送，好比個推，至少人家也是百億級用戶量，服務器掛了懟他去，哈哈。

總結一下：本身推送成本高、服務相對更可控，使用第三方推送成本低、功能更多。建議若是公司特別大，對成本不在意又要求服務可把控，能夠本身搭建推送服務，若是是小公司或者才創業的公司，使用第三方廠商更加合適，沒有統一答案，要根據自身產品特色、公司狀況不斷權衡和調整。

五：使用個推後的感覺

一、在開發測試時，更換了推送證書，證書更換後須要10分鐘左右生效，測試時感受好麻煩，不能當即生效麼。

二、推送時，能夠角標自動增長，產品的需求，做爲一個開發人員不知道有什麼好，不過產品這樣要求，只能作了，還好個推支持。

三、能夠統計通知的展現率和點擊率，運營同窗能夠在推送活動通知後，知道用戶對什麼樣的活動比較感興趣，更方便他們運營。

四、能夠對指定人羣推送，例如咱們活動在上海，能夠指定給上海用戶大力推送。這個比較好，不用所有用戶都發送，保證不相關的用戶不被打擾。

五、個推的透傳方法能夠保證數據的到達，由於蘋果的APNs推送不保證是否到達和到達時間，因此就可能會丟失，使用個推的透傳方法能夠保證能收到消息。

六、在發送透傳消息時，「iOS高級通知」中「代碼塊」功能比較贊，我我的超喜歡，能夠提早預覽客戶端收到APNs通知消息的數據格式。