前段時間，仔細研究了APNS的文檔，把一些關(guān)鍵的地方記錄了下來，弄懂這些對于理解APNS的規(guī)則，至關(guān)重要。

1. If APNs attempts to deliver a notification but the device is offline, the notification is stored for a limited period of time, and delivered to the device when it becomes available.

假如用戶手機不在線，可能沒有信號或者關(guān)機吧，APNs會存儲轉(zhuǎn)發(fā)，等用戶在線時再發(fā)送

2.Only one recent notification for a particular application is stored. If multiple notifications are sent while the device is offline, each new notification causes the prior notification to be discarded. This behavior of keeping only the newest notification is referred to as coalescing notifications.

如果用戶不在線，通知會合并，只會保留最新的一條。假如你給用戶發(fā)了兩條通知，但用戶反饋說，只收到了一條，那么很可能是用戶當時不在線，APNs的合并策略生效，只保留了最近一條

3.If the device remains offline for a long time, any notifications that were being stored for it are discarded

4.The maximum size allowed for a notification payload is 256 bytes; Apple Push Notification Service refuses any notification that exceeds this limit.

這個很重要，payload，就是最后生成的那段Json，不得超過256字節(jié)。如果超過了，建議去掉一些不需要的參數(shù)，把alert，就是提示信息的字數(shù)減少

5.don’t repeatedly open and close connections. APNs treats rapid connection and disconnection as a denial-of-service attack.

6.If you send a notification that is accepted by APNs, nothing is returned.

發(fā)送成功的木有返回，只有發(fā)送失敗的才會返回

7.If you send a notification that is malformed or otherwise unintelligible, APNs returns an error-response packet and closes the connection. Any notifications that you sent after the malformed notification using the same connection are discarded, and must be resent.

這條非常重要，如果有error-response，那么這條之后的通知都需要重發(fā)。有很多開源的庫，在發(fā)蘋果通知時都沒有檢測error-response，如果你不小心用了，那么用戶很可能反饋“怎么沒有通知啊”

8.The notification identifier in the error response indicates the last notification that was successfully sent（實際情況不是，實際上返回的是出錯的那條通知的ID）. Any notifications you sent after it have been discarded and must be resent.When you receive this status code, stop using this connection and open a new connection.

這是對上一條的補充，如果出錯了，需要關(guān)閉當前的連接，并且重新連接再發(fā)。error-response中返回的通知ID，可以幫助我們找出哪條出錯了，這樣就能知道哪些需要重發(fā)了

9.When a push notification cannot be delivered because the intended app does not exist on the device, the feedback service adds that device’s token to its list.

APNS的feedback service會返回那些已經(jīng)卸載的設(shè)備的token--device_token。存儲這些token，下次就不用再給他們發(fā)了，可以節(jié)省點資源。需要注意的是：feedback的接口讀取一次，APNS就會清空它的列表，下次再讀取時，返回的就是這兩次讀取之間這段時間新產(chǎn)生的device_token。

只有把這些搞清楚，才方便我們理解蘋果推送的規(guī)則，知道自己推送上的一些不足之處。搞懂這些規(guī)則后，我自己封裝了個Java的類庫，已經(jīng)開源并放到Github上了，下一篇文章奉上詳情。

更多信息請查看IT技術(shù)專欄