有段時間沒寫博客了，在走上“黑暗的道路上”...
////////////////////////////////////////////////////////萬惡的分割線////////////////////////////////////////////////////////////////////////
最近這段時間一直在做手機APP服務端相關開發工作，其中對於推送這塊是我單獨負責的一個模塊，在此有些相關細節的說明，相信會對一些開發有些幫助
一.基本介紹
蘋果推送官網相關介紹：http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html#//app
le_ref/doc/uid/TP40008194-CH100-SW9
相關推送的原理，建議最好查看官網文檔，看完後，對其推送會有深入的理解。
IOS推送協議經歷過協議的修訂，現在是V2版本
相關推送的實現，java中主要有javapns與apns兩個開源項目，我們項目中使用了jar包javapns2.2版本，並在此基礎上修訂了一些小地方。
javapns開源地址https://code.google.com/p/javapns/
對於IOS推送的證書生成及相關細節，有需要的可自行查找。(本人只做服務器端開發)
二.推送方式
IOS推送主要有兩種主式，一種是sandbox方法，一種是production方式，前者是測試所用，後者是線上產品推送所用。
兩種不同的方式，會推送到蘋果不同的服務器上。每個設備每個應用會有一個叫token的唯一標識，在線上與測試過程中，也會生成不同的token,測試所用token一定要發送到sandbox服務器，還在線上需要發送到
production服務器中去。在此需要注意，javapns在實現時，SSLsocket會重用，如果當使用一個sandbox的token發送到production上的服務器上時，會引起此socket連接不可用，但是此狀態是無法檢測的，這會引起後續使用此socket連接推送的消息都會推送失敗，因此一定需要注意。
另位SSLsocket一段時間未使用，會出現推送失敗的問題，現在我們的修訂是，對於SSLSocket空閒時間過長，在發送消息時會進行檢測，出現此情況，會重建此連接後再繼續推送消息，從而保證推送的成功。
三.推送內容
消息推送時，主要有對應三個字段
alert 推送的消息內容（會組裝成Json格式）
badge 用戶未讀消息的條數（需要我們自己的服務器保證用戶的未讀消息自增）
sound 用戶接收消息時所聽到的聲音提示（不填，或者使用默認的"default"字符，即是默認聲音，如果需要自定義聲音，需要在自己的應用下指定聲音文件，並在推送
時寫上此聲音文件的名字，如果無對應的文件，會以默認聲音提示）對於以上字段值得說明的有時我們需要達到一種無聲的狀態，即在應用中可配製，對用戶只顯示提示的未讀消息條數，還不顯示推送內容，也無推送聲音，此實現只要把推送內容填成空字符即可~
對於定製的聲音格式，IOS是有限制的：
Custom alert sounds are played by the iOS system-sound facility, so they must be in one of the following audio data formats:
-
Linear PCM
-
MA4 (IMA/ADPCM)
-
µLaw
-
aLaw
You can package the audio data in an aiff, wav, or caf file.
四.推送優化
使用javapns推送時，存在多線程的方式，可用於推送，但是其多線程的實現對於實際使用時會存在問題。
對於相同的用戶，消息推送提醒比較頻繁時，由於多線程，會出現晚發送的消息會比早推送的消息早提示，並且會引起未讀消息條數亂序的錯誤提示現象，此問題還是比較嚴重的。對於此，可基於相同的token設置做映射到相同的線程進行推送，因爲其基於隊列的方式，基於此實現，只要入隊列保證了唯一性，即可保證推送順序的準確性。
五.token失效問題
說到token問題，蘋果爲了更好的用戶體驗，這個推送帶來了多少推送的用戶量，應該很多服務器啊！！！
對於token失效，是指蘋果在推送應用的消息給此設備時，發現此設備對應的應用已經刪除，蘋果會保證此token失效在feedback隊列中。
我們可以通過其feedback服務定時去查詢失效token，並檢測到哪些token已經失效，可做特殊處理。
但實現存在的問題：
當一個用戶在卸裝後，收到一條推送後，此token就會被標識爲已經失效，但是用戶在馬上又重裝了此應用後，並登錄，使用，此前feedback服務如果一直未去檢測，還會把此token保存在失效的隊列中。雖然此不影響到用戶的推送與使用。如果feedback服務在處理時，對於失效的token進行了清除等嚴重的操作，會小悲劇下下。當然蘋果的實現還是比較合理的，feedback返回時，同時也會帶上此token失效的時間，通過此時間應用可進行相應的判斷做處理。值得說明的是feedback在調用後，蘋果對於此失效的token將不會再保存。
以上是IOS推送在實現過程中比較明顯的問題，希望對各位有所有幫助。