消息推送分類：推動(Push)模式和拉動(Pull)模式

push：保持長連接（採用異步socket建立tcp連接），能實時無延遲的收到服務推送過來的消息。服務器的域名不會改變，客戶端能夠找到服務器，而手機客戶端是用的是移動運營商的網絡，若30分鐘（不同省份的運營商設置的可能不同，大部分運營商設置的是30分鐘）用戶不使用網絡，運營商可能把這個IP分配給其它的用戶，所以服務器一般不能實時的找到手機客戶端。所要要實現push，那麼就要再服務器和手機客戶端建立長連接。由於手機客戶端需要連接服務器的連接很多，通常服務器要支持集羣，畢竟一臺服務器要實現少衝突的分配長連接端口號，那麼就最好不超過20000個連接。Push的好處是實時，維護通道的流量超少，只需要每30分鐘維護一次通道（爲保持安全穩定最好每14分鐘維護一次通道，就是發送一次請求，應用前後臺切換時有繼續讓線程僵死，所以應用前後切換時要維護一次通道）就可以。個推的透傳和蘋果APNS本質就時push長連接，所以他們很省點，也較快。只所以它們沒有做到想象的那麼實時是因爲蘋果運營的手機是海量的，APNS連接也是海量的，消息的調度是很費時間的。個推的連接比蘋果少，但是再少也是海量級別的。所以個推付費能提高響應速度，但不能從根本上解決問題。想解決響應慢的問題只有你自己實現push長連接才更安全可能，畢竟是消息隊列調度問題還是連接問題你都實時的知道，可以用http請求的方案替代暫時連接異常。大部分郵箱和郵箱客戶端都不真正的支持push。微軟的exchange服務器的imap idle從實現機制上它是push。
個推的付費用戶也不是單獨給你搭建一個服務器，而是調整給你有消息隊列插隊的的特權。如：你是付費用戶，個推服務器有1億條消息在排隊，又一次性來1000萬條消息，其中有5000條消息是付費用戶的，那麼這5000條消息肯定排列在1億條消息緊挨着的後面，至於這5000條消息的那麼就靠誰先來誰就在前面了。若一條消息處理時間是x毫秒，那麼你的等待時間最快就是1億＊x毫秒。所以你可以看到你的個推消息響應時間不但於你的應用使用量，也取決於這個時間段消息擁堵狀況，其它人使用個推發送消息的瞬時情況，個推的透傳可能發送很快（長連接大部分情況正常，無需建立通道的時間）但是它們大部分時間被耽誤在消息排隊上了。蘋果的APNS服務器也是一樣，只是沒有插隊的後門而已。自己在服務器上實現蘋果的APNS的通信功能，不但在要求這方面的技術，最關鍵的是它不支持類似的安卓手機遠程。而是個推集成了iOS和android這兩方面的遠程推送，所以你若想用不依賴於手機是否開啓都推送消息，最簡單的方法是使用個推。個推的APNS遠程遠沒有個推的透傳來的快，畢竟少了，在個推推送到蘋果APNS服務，在哪裏排隊的時間，蘋果的連接可是海量的。個推的付費用戶對你的及時性有所提高，但是也沒有你想象的那麼及時，必定要在個推那裏進行大量消息排隊。自己實現push長連接，只排隊等待自己應用的消息和其它應用的消息無關，所以響應最快最準確，不用擔心消息丟失率的問題。
Pull:就是定時獲取。優點是實現簡單，技術難點和異常很少。缺點不夠實時，若獲取的時間間隔太短，設備的耗電量超快。
還有一種實現方案是結合push和pull兩者的優缺點，具有實時收到消息，實現簡單，耗電量界於兩者間。具體的是建立長連接，卻是10秒維護一次通道（服務器或客戶端不夠強大，沒有實現監控兩者間異常的機制，才頻繁的發送心跳消息來代替這種異常監控機制）。這種方案的優點是基本做到了push的省去了發送請求才建立tcp通道的時間，達到了實時發送。它可以是異步socket也可以是同步socket。同步socket的優點是實現簡單，異常較少；缺點是阻塞連接線程，異步socket的優點是實時發現異常，不阻塞連接線程；缺點是實現相對複雜，異常較多。
綜上所述push的實現方案最優，pull的實現方案最簡單，兩者結合的方案是兩者的折中，具體實現那種實現方案，根據自己技術團隊的技術水平和項目緊急水平。