手機推送服務

標籤：android   style   io   os   使用   ar   資料   sp   問題   

設計一個長串連手機雲推送服務。

要求：

1. 穩定包括兩個部分一個是伺服器端的穩定性，一個是手機端的穩定性。

服務端穩定性，因為使用長串連方案，對伺服器的開銷和要求很大，推送方案對伺服器開發要求很高，海量線程串連下的伺服器穩定性是非常具有挑戰性的。一般的評判標準包括：

• 同時線上時峰值 （一般按照百萬並發串連時伺服器穩定性評測）
• 高並發時訊息平均延遲時間（一般按照1分鐘處理1百萬條資訊評測）
• 服務穩定性 （一般要求全年99.9%以上可用，有備份，有負載平衡等）
• 鑒於伺服器穩定的開發難度很大，小團隊不建議自己開發，建議使用穩定的第三方推送方案，如個推，蝴蝶等。

手機端的穩定性，主要是因為中國的複雜網路狀況及手機型號適配情況造成手機長時間穩定連網較困難，所以穩定性非常重要，一般的評判標準包括：

• -每日連網23.5小時以上使用者比例 （表徵連網穩定性）
• 訊息發送後9小時內收到率 （表徵到達率）
• 一般來說，推送方案要做網路的分電訊廠商，分省，分機型適配，自己開發工作量較大

2. 耗電

手機用戶端都是TCP長串連。TCP長串連有個心跳的時間，在國外可以很長比如30分鐘，在國內則因為網路環境複雜一般10分鐘。用戶端發起的心跳，會短暫地消耗手機電能，但在這個心跳間隔期間，則消耗電能是很少的。當在心跳期間伺服器端有推送資訊過來時，用戶端可以收到並做處理。

3. 共用串連

如果一台手機上裝了2個利用JPush的App，那他們會有多個後台服務在後台運行嗎？會有多少個長串連呢？

4. 負載平衡

F5？

5. 連結中斷

大部分移動無線網路電訊廠商都在鏈路一段時間沒有資料通訊時，會淘汰 NAT 表中的對應項，造成鏈路中斷。

6. 單機的輸送量

業界：

iOS 的推送：就是 Apple 官方的 APNs （Apple Push Notification service）。

Android 的推送：Google 官方的是 GCM (Google Cloud Messaging）。

本質上，APNs 與 GCM 是類似的技術實現原理：即系統層有一個常駐的 TCP 長串連，一直保持的長串連，即使手機休眠的時候也在保持的長串連。

JPush：

為了不讓 NAT 表失效，我們需要定時的發心跳，以重新整理 NAT 表項，避免被淘汰。

Android 上定時運行任務常用的方法有2種，一種方法用 Timer，另一種是AlarmManager。

• Android 的 Timer 類可以用來計劃需要迴圈執行的任務，Timer 的問題是它需要用 WakeLock 讓 CPU 保持喚醒狀態，這樣會大量消耗手機電量，大大減短手機待機時間。這種方式不能滿足我們的需求。
• AlarmManager 是 Android 系統封裝的用於管理 RTC 的模組，RTC (Real Time Clock) 是一個獨立的硬體時鐘，可以在 CPU 休眠時正常運行，在預設的時間到達時，通過中斷喚醒 CPU。這意味著，如果我們用 AlarmManager 來定時執行任務，CPU 可以正常的休眠，只有在需要運行任務時醒來一段很短的時間。

 

手機推送服務