iOS推送功能詳細(xì)解決方案
iOS推送必必須用到APNS。ApNS是Apple Push Notification Service (Apple PushH服務(wù))由于iOS系統(tǒng)的限制，應(yīng)用是不允許在后臺(tái)運(yùn)行并連接網(wǎng)絡(luò)的。如果App在iOS上沒(méi)有運(yùn)行，但是我們APP開(kāi)發(fā)者卻想推送消息給使用該App的iOS用戶，只能通過(guò)APNS推送消息。深圳APP開(kāi)發(fā)公司現(xiàn)在就這個(gè)問(wèn)題結(jié)合我們多年實(shí)際開(kāi)發(fā)經(jīng)驗(yàn)整理歸納出如下幾種方法供您參考：
1.APNS原理
APINS推送有一個(gè)重要概念：Device t oken。Device token是iOS設(shè)備上某個(gè)App在APNS上的唯一標(biāo)識(shí)符，通過(guò)Device tokeu，APNS就知道把消息推送到哪臺(tái)iOS設(shè)備上由哪個(gè)App接收。
APNS的推送原理如圖9-40所示
根據(jù)圖9-40“APNS的推送原理”，APNS推送流程如下。
(1) iOS設(shè)備在網(wǎng)絡(luò)接通的情況下連接APNS服務(wù)器，連接成功后和APNS服務(wù)器保持一個(gè)長(zhǎng)連接。在圖9-40中，iOS設(shè)備l對(duì)應(yīng)的是長(zhǎng)連接l。
(2) App后臺(tái)服務(wù)器按照定格式推送消息（消息己包含Device token）到APNS服務(wù)器。在圖9-40中，推送的消息包含了Device tokenl。
(3) APNS服務(wù)器根據(jù)Device token查找其對(duì)應(yīng)的長(zhǎng)鏈接。在圖9-40，Device tokenl對(duì)應(yīng)的是長(zhǎng)鏈接l，APNS服務(wù)器把消息推送到長(zhǎng)鏈接l對(duì)應(yīng)的是iOS設(shè)備l。
(4) iOS沒(méi)各l收到推送消息后，如果該推送消息對(duì)應(yīng)的App正在運(yùn)行，則通知App處理，如果該App沒(méi)有運(yùn)行，則在屏幕上彈出消息。
2．APNS推送協(xié)議分析
APNS上的推送接口稱(chēng)為Binary Interface，App后臺(tái)連接APNS服務(wù)器后必須按照Biuary Interface格式推送消息。
如圖9-41所示是最初版本的Binuy Interface，稱(chēng)之為vl版。
這個(gè)版本的接口有如下兩個(gè)問(wèn)題。
·沒(méi)法確定消息是否發(fā)送成功。
·當(dāng)發(fā)送了一個(gè)無(wú)效Device token后，APNS和iOS設(shè)備的連接會(huì)在短時(shí)間內(nèi)斷開(kāi)，在連接斷開(kāi)之前發(fā)送的Device t oken也會(huì)失效。這就是說(shuō)，當(dāng)連續(xù)推送批消息(里面可能包含無(wú)效的Device token)后如果鏈接斷開(kāi)，沒(méi)法確定推送給哪些Device token的消息是已經(jīng)發(fā)送成功，推送給哪些Device t oken的消息需要重發(fā)，這就造成了用戶經(jīng)常收不到推送的情況。
接下來(lái)蘋(píng)果推出了改進(jìn)版本的Binary Interface，稱(chēng)之為V2版，如圖9-42所示。
我們可看到V2版的協(xié)議增加了如下兩個(gè)字段。
·Identifier:用于識(shí)別條消息，可以是任意值。如果發(fā)送出現(xiàn)問(wèn)題，在APNS返回的錯(cuò)誤應(yīng)答中會(huì)包含出問(wèn)題的Identifier。
·Expiry:離線消息超時(shí)的時(shí)間。如果為0或者小于0，APNS服務(wù)器不會(huì)保存這條消息。在V2版中，如果發(fā)送過(guò)程中發(fā)生了錯(cuò)誤，會(huì)返回個(gè)錯(cuò)誤的Error-response．包含status和Identifier。錯(cuò)誤碼的格式如圖9-43所示。
根據(jù)錯(cuò)誤應(yīng)答的Identifier，開(kāi)發(fā)者就知道推送給哪些Device token的消息需要重發(fā)。
Binary Interface V2有個(gè)不便的地方：每個(gè)推送只能給一個(gè)Device token推送消息，如果要給上百萬(wàn)臺(tái)設(shè)備推送消息那效率非常低，于是蘋(píng)果推出了Binary Interface V3版，如圖9-44所示。
從圖9-44中可看到，在Binarv Interface V3版中次給多個(gè)Device token發(fā)送消息。
3．iOS推送服務(wù)器架構(gòu)
服務(wù)端推送APNS過(guò)程中需要注意推送了無(wú)效Device token的問(wèn)題。為什么會(huì)有無(wú)效的Device token呢?因?yàn)楫?dāng)用戶卸載了App后，用戶的Device t oken就失效，但是這個(gè)失效的Device token可能被開(kāi)發(fā)者保存在數(shù)據(jù)庫(kù)，下次推送時(shí)還會(huì)把這個(gè)失效的Device token推送到APNS服務(wù)器。
如果推送返回Error-response，iOS推送服務(wù)器獲取Error-response中錯(cuò)誤消息的Identifier．該identifier后的推送都需要重發(fā)。因為服務(wù)器發(fā)送的消息包含了無(wú)效Device token后隔段時(shí)間，服務(wù)器和APNS連接會(huì)斷開(kāi)，從發(fā)送無(wú)效的Device t oken那個(gè)刻起直到APNS連接斷開(kāi)，這段時(shí)間所發(fā)送的Device token都會(huì)失效。所以考慮重發(fā)解決Device token的問(wèn)題時(shí)可以把發(fā)送消息保存到歷史消息發(fā)送隊(duì)列，從歷史消息發(fā)送璣列中找到Error-response中返回的Identifier．就可以知道哪個(gè)消息開(kāi)始出錯(cuò)，這樣就能知道哪些消息需要重發(fā)了。
APNS歷史消息璣列如圖9-45所示
假設(shè)當(dāng)Error-response中返回的Identifier為4，那么后面Identifier的5和6都需要重發(fā)。
另外APNS的feedback s ervice會(huì)返回那些已經(jīng)卸載的設(shè)備的Device t oken，定期在數(shù)據(jù)庫(kù)中刪除這些無(wú)效的Device token以提高推送的成功率。
因此針對(duì)重發(fā)Device token的問(wèn)題．iOS推送服務(wù)器工作的流程如下。
(1)應(yīng)用服務(wù)器把推送的消息寫(xiě)入到iOS推送服務(wù)器的APNS消息隊(duì)列。
(2) APNS發(fā)送模塊從APNS消息隊(duì)列取出一個(gè)消息，根據(jù)APNS推送協(xié)議封裝這個(gè)消息(包括給這個(gè)消息加上一個(gè)全局唯一的Identifier)，然后發(fā)送到蘋(píng)果APNS服務(wù)器，同時(shí)把發(fā)送的消息保存在APNS歷史消息隊(duì)列。
(3) iOS推送服務(wù)器中有一個(gè)模塊不斷檢測(cè)蘋(píng)果APNS服務(wù)器是否有返回Error-response，一旦發(fā)現(xiàn)Error-response就獲取其中的Identifier，遍歷APNS歷史消息隊(duì)列．把隊(duì)列中這個(gè)Identifier后面的所有消息重新放入到PNS消息隊(duì)列，讓APNS發(fā)送模塊重新發(fā)送這些消息。
APP開(kāi)發(fā)公司工程師上面所描述的iOS推送服務(wù)器的工作流程如圖9-46所示。
好了，本文關(guān)于ios系統(tǒng)推送功能的解決流程就分享到這里，喜歡本站的朋友請(qǐng)持續(xù)關(guān)注本站，我們會(huì)定期更新相關(guān)類(lèi)型經(jīng)驗(yàn)分享文章。博納網(wǎng)絡(luò)編輯整理。
