ZPush--基于netty4實作的蘋果通知推送服務（APNs）Java用戶端

簡單說下實作蘋果通知推送服務（apns）用戶端的一些要注意的地方：

使用長連接配接；

sanbox伺服器是沒用的，調試時直接用“gateway.push.apple.com”域名；

對于錯誤的notification，蘋果會回應一個error response，裡面有個identifier，在這個identifier之後的notification全都失敗；

是以發送者要緩存已經發送的notification，最好設定notification identifier為增長的整數序列，當收到error response裡，從緩存裡取出比error response的identifier要大的notification，再次重新發送；

對于一台裝置，apns伺服器隻存儲一條notification，是以如果裝置不線上，連續發送多條消息的話，後面的會覆寫前面的；

apple的文檔裡有提到可以設定notification的priority = 5，具體是什麼意思不太明白。實際測試是當螢幕關閉，在省電時才會接收到的。如果是螢幕亮着，是不會接收到消息的。而且這種消息是沒有聲音提示的。貌似意義不大。

特點：

支援第三版通知推送，即command = 2。目前的絕大部分java用戶端都隻支援command = 1，即第二版。

支援ssl握手成功才傳回，可以調用 pushmanager.start().sync(); 等待握手成功；

最大限度重試發送，内部自動處理重連，錯誤重發機制；

支援配置rejectlistener，即通知被apple伺服器拒絕之後的回調接口；

支援配置shutdownlistener，即當shutdown時，沒有發送完的消息處理的回調接口；

支援發送統計資訊；

實作元件分離，可以利用pushclient，feedbackclient來寫一些靈活的代碼；

notification發送者可以自己定義設定發送的queue，自己靈活處理阻塞，逾時等問題。

把queue暴露給發送者，這嚴格來說是一個不好的設計。因為在shutdown裡，有可能别的線程還在put notification到queue裡。

但是因為apns協定本身，包括消息推送機制本身就是一個不完全靠譜的東東，考慮到發送者處理阻塞，消息積壓的便利性，是以把queue暴露給發送者。

代碼位址：

https://github.com/hengyunabc/zpush

例子：