iOS遠程推送原理

標籤：溝通   串連   擷取資料   token   服務   另一個   通知   結束   推送   

遠程推送

就是從遠程server推送訊息給client的通知。當然須要連網。

遠程推送服務APNs （Apple Push NotificationServices）

 

為什麼須要遠程推播通知？

傳統擷取資料的局限性是僅僅要使用者關閉了app。就無法跟app的server溝通。無法從server上獲得最新的資料內容

而遠程推播通知能夠解決問題，無論使用者開啟還是關閉app，僅僅要連網了，都能接收到server推送的遠程通知。

我們先從網路連接開始瞭解下。

http協議：是個短串連，一個請求一個響應就結束了。

典型的網路請求。

tcp/ip協議：三向交握串連，僅僅要server或者client不主動斷開。保持串連著。大概QQ聊天就是這樣的協議了。

推送，我們從QQ聊天著手吧。

A使用者和B使用者聊天：

1.A和B使用者同一時候線上，跟server保持串連狀態下：“A發送訊息給B：在嗎？，B回複：在的。”我們分析下這個過程。

->A將訊息“在嗎？”發送給QQserver，此時由於B與server也保持串連，因此server將訊息發送給B，相同B的回複也反向傳輸成立。

2.A發送訊息給B。但B不線上。

->這樣的情況下，server無法將A的訊息發送給B了。那我們手機不線上的情況下是怎麼收到A的訊息的？

那我們就不得不拿出來神器遠程推送了。遠程推送是通過蘋果的APNsserver來實現的。僅僅要你的蘋果裝置連網狀態，你的裝置就與蘋果的APNsserver保持一個長串連狀態。

那我們就能夠想到。A將訊息發送給server時，server將訊息發送給APNsserver的方式能夠實現將訊息發送給B了，那詳細是怎麼實現的呢？我們往下看：

1. A與B安裝QQclient。登入自己的QQ號碼時。A和B將自己的QQ號碼+蘋果裝置的DeviceToken發送給QQserver，QQserver將這一組資料儲存在自己的資料庫中。

擷取DeviceToken方法。在AppDelegate.m中：

- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {}

2.A將訊息“在嗎？”發送給B時，server發現B不線上，這時，server從資料庫中尋找B相應的DeviceToken,將B的DeviceToken+訊息“在嗎？”發送給APNsserver。

3.APNsserver收到訊息後，找到B相應的DeviceToken,將訊息“在嗎？”發送給B的裝置。

那麼另一個疑問。APNsserver將訊息發送給B的裝置。那怎麼知道是QQclient呢？

事實上說白了。這個事情就被DeviceToken包括了，當你擷取DeviceToken時，蘋果偷偷的將裝置的UDID和APP和bundle identifier發送給蘋果server。蘋果server返回給你了DeviceToken。因此QQserver將訊息+B的DeviceToken發送給蘋果的APNsserver時，蘋果已經知道了是哪個client了。

----end

iOS遠程推送原理