序言：

因為App的功能需要，最近一直在調研蘋果的APNs推送，開始時覺得超麻煩，現在感覺還是比較easy，“難者不會，會者不難”，自己踩過了這麽多的坑終於會了，不出來吐槽（裝X）一下對不起自己，23333。

先給大家來一個小小福利，因為APNs只能在真機上測試，模擬器上用不了的，如果還沒有iPhone的同學，可以借這個機會找老板申請一臺iPhone，能不能申請下來就看本事了，我就是沒有iPhone，然後用這種方式讓公司幫配的iPhone。

然後就是需要寫服務代碼，在測試發送APNs消息的時候，需要寫服務器代碼給蘋果服務器發消息，本人作為一個純iOS開發者，對服務器代碼十竅通九竅，還好現在網上很多第三方提供這個功能，因為我們公司使用的是個推，就直接使用個推提供的功能測試了，不需要我來寫服務端代碼真爽。

準備工作：

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

2、蘋果開發者網站上註冊“AppIDs”，我使用的是“com.crazywolf.yewan”，勾選“Push Notifications”。

3、真機（加油，iPhone在等著你），需要添加到開發許可設備中。

4、Provisioning

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

5、蘋果APNs推送證書，分：開發環境證書(Development)、生產環境證書（Production）等，同樣，也是使用“Development”，註意使用個推平臺APNs推送需上傳該推送證書，這裏我將導出的開發環境證書提交個推平臺，關於證書生產和導出可以查看個推APNs配置技術文檔（docs.getui.com/mobile/ios/…）。

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

一：註冊APNs、獲取DeviceToken

1、創建新項目或修改老項目，配置項目

2、註冊APNs，獲取DeviceToken

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

是不是很簡單，這樣就可以獲取到APNs推送消息了，有沒有一種成功感，不過我開始獲取DeviceToken時，一直報（“Error Domain=NSCocoaErrorDomain Code=3000

"未找到應用程序的“aps-environment”的授權字符串" UserInfo={NSLocalizedDescription=未找到應用程序的“aps-environment”的授權字符串}”）錯誤，網上說是證書沒配置好，我重新配置了多次證書還是不行，後來問了個推的技術支持才知道Xcode8以上版本需要打開“TARGETS -

Capabilities - Push Notifications”，個推的集成文檔中也有寫，自己太粗心了。

4、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，推送我們需要的信息

1、集成個推SDK

怎麽配置個推，可以去看“docs.getui.com/mobile/ios/…/”，配置成功後運行獲取個推的“clientId”。

2、使用個推網站上的“透傳消息”下發

這樣就可以推送自定義消息內容到iPhone上了，到這裏APNs的功能已經全部完成了，後面就要看看具體需求了，將個推的服務端集成部分發給你們服務端開發人員，讓他“碼”起來了，如果有問題，讓他們聯系個推的技術支持，2333。

3、APNs消息統計

個推最新版本1.5.3 iOS SDK添加了“iOS 10 APNs展示統計”功能，該功能使用到了iOS10新特性需要添加NotificationService擴展模塊，能準確統計到iOS10以上APNs展示信息，這個功能太爽了，APNs展示數據無法統計是多少開發者及運營的痛啊，相信有了這個功能能更好的跟蹤APNs推送到達情況。具體集成步驟可以查看“http://docs.getui.com/mobile/ios/xcode/#6-ios-10-apns”。

推送成功後可以在個推後臺進行查看推送情況，如圖：

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

4、回調方法區別

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

個推的透傳消息可以通過方法（“GeTuiSdkDidReceivePayloadData: andTaskId: andMsgId: andOffLine:

fromGtAppId: ”）回調獲取，因為蘋果的APNs推送不保證是否到達和到達時間，所以就可能會丟失，使用個推的透傳方法相對APNs更能保證消息的到達率。

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

1）對象在線：下發個推的透傳消息，不發送APNs推送消息。

2）對象離線：下發個推的透傳消息，發送APNs推送消息。

從上面可以看得出，個推的透傳消息是每次都下發的，這樣也保證的個推的消息到達率，不過這種做法會出現消息重復，例如是收到消息彈框提醒用戶操作，個推透傳消息和APNs推送消息都收到了，處理不好的話會提醒用戶二次一樣的消息。

這裏比較好的是個推在透傳消息方法中提供了“offLine”字段，這個值是“YES”時，表示這是一條離線消息，在下發個推透傳消息時，也發送了APNs推送消息，在處理消息時可以忽略，如果消息的重要性不是很高，可以這麽做，因為在忽略個推的透傳消息後APNs消息也沒有收到，就導致該條消息丟失。

另外一種處理方式：參照網上的一些解決方法，我建立一個配置表，處理過的數據在表中標註，防止APNs和個推的透傳方法消息重復操作。

5、個推透傳消息註意點

圖1

圖2

上面二張圖，第一張是個推網站下發透傳消息時的界面，第二張是個推透傳消息回調方法。需要特別註意的是第一張圖中最下面的“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還不是很熟悉的初學者使用，當然不包括我了，哈哈哈哈。

6、發布到AppStore註意點

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

1）創建二套個推AppId：這種方案是在個推網站中添加二個應用，一個用於開發、一個用於發布，在開發測試期間使用開發的個推AppId，在發布時使用發布的個推AppId，這種方案需要註意發布時切換AppId，忘記換就GG，第一次發布還好，兩個個推AppId的作用互換一下就可以了，如果是更新發布，那只能重新提交蘋果審核了。

2）更換APNs證書：這種方案是在發布時重新上傳生產APNs證書，註意個推的證書更換後需要10分鐘左右生效，這種方案需要註意在之後版本更新開發時，需要申請新的個推AppId，不然會影響在線的客戶。

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

三：公司服務器自己推送和使用個推推送的流程差異

1、公司服務器自己推送（簡稱：自己推送）流程

1）註冊APNs，獲取DeviceToken

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

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

2、使用個推推送流程

1）註冊APNs，獲取DeviceToken

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

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

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

四：自己推送和第三方對比

1、成本：自己推送需要專人進行開發，並且需要一定數量的服務器和帶寬支持，在開發完成後的使用過程中還需要有專人進行維護。使用第三方推送，只需要集成SDK就可以實現功能，不僅減小了開發成本與維護成本，甚至在推送穩定性上第三方也會比自己做的推送更好一些。

2、精準推送：可以將針對內容及標簽等信息進行精準推送，比如將杭州的新聞推送給杭州用戶，自己推送需要額外開發，而第三方大部分已經支持這樣的功能。

3、推送統計：自己推送還是需要額外開發該功能，而第三方基本都必備該功能，相對來說就我現在使用的個推統計效果還是令人滿意的，區分在線下發和APNs下發統計功能，支持通知的展示統計和點擊統計，可以知道真實的下發量，下發後有多少被展示了，有多少被點擊了。

4、可控性：使用第三方推送可控性太低，想想，如果第三方推送廠商宕機、或者被黑客攻擊了，你服務沒法推送了，需要等待第三方廠商響應，或者第三方廠商出問題了，也會影響你的推送。所以那些痛的經驗告訴我們要選擇家專業做推送，比如個推，至少人家也是百億級用戶量，服務器掛了懟他去，哈哈。

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

五：使用個推後的感受

1、在開發測試時，更換了推送證書，證書更換後需要10分鐘左右生效，測試時感覺好麻煩，不能立即生效麽。

2、推送時，可以角標自動增加，產品的需求，作為一個開發人員不知道有什麽好，不過產品這樣要求，只能做了，還好個推支持。

3、可以統計通知的展示率和點擊率，運營同學可以在推送活動通知後，知道用戶對什麽樣的活動比較感興趣，更方便他們運營。

4、可以對指定人群推送，例如我們活動在上海，可以指定給上海用戶大力推送。這個比較好，不用全部用戶都發送，保證不相關的用戶不被打擾。

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

6、在發送透傳消息時，“iOS高級通知”中“代碼塊”功能比較贊，我個人超喜歡，可以提前預覽客戶端收到APNs通知消息的數據格式。

iOS APNs實戰分享