1. android 即時通信。。如何實現
Android現在即時通訊（或者消息推送）有好幾個開源項目框架可以實現，可以使用XMPP來實現即時通信。
XMPP（Extensible Messageing and Presence Protocol：可擴展消息與存在協議）是目前主流的四種IM（IM：instant messaging,即時消息）協議之一，其他三種分別為：即時信息和空間協議(IMPP)、空間和即時信息協議(PRIM)、針對即時通訊和空間平衡擴充的進程開始協議SIP(SIMPLE)。
1. XMPP的前身是Jabber，一個開源形式組織產生的網路即時通信協議。XMPP目前被IETF國際標准組織完成了標准化工作。標准化的核心結果分為兩部分； 核心的XML流傳輸協議 基於XML流傳輸的即時通訊擴展應用 XMPP的核心XML流傳輸協議的定義使得XMPP能夠在一個比以往網路通信協議更規范的平台上。藉助於XML易於解析和閱讀的特性，使得XMPP的協議能夠非常漂亮。 XMPP的即時通訊擴展應用部分是根據IETF在這之前對即時通訊的一個抽象定義的，與其他業已得到廣泛使用的即時通訊協議，諸如AIM，QQ等有功能完整，完善等先進性。
2.XMPP中定義了三個角色，客戶端，伺服器，網關。通信能夠在這三者的任意兩個之間雙向發生。伺服器同時承擔了客戶端信息記錄，連接管理和信息的路由功能。網關承擔著與異構即時通信系統的互聯互通，異構系統可以包括SMS（簡訊），MSN，ICQ等。基本的網路形式是單客戶端通過TCP/IP連接到單伺服器，然後在之上傳輸XML。
3.傳輸的是與即時通訊相關的指令。在以前這些命令要麼用2進制的形式發送，要麼用純文本指令加空格加參數加換行苻的方式發送（比如MSN）。而XMPP傳輸的即時通訊指令的邏輯與以往相仿，只是協議的形式變成了XML格式的純文本。這不但使得解析容易了，人也容易閱讀了，方便了開發和查錯。而XMPP的核心部分就是一個在網路上分片斷發送XML的流協議。這個流協議是XMPP的即時通訊指令的傳遞基礎，也是一個非常重要的可以被進一步利用的網路基礎協議。
2. Android 中使用MQTT(第一篇)
MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）是IBM開發的一個即時通訊協議。它是一種發布/訂閱，極其簡單和輕量級的消息傳遞協議，專為受限設備和低帶寬，高延遲或不可靠的網路而設計。它的設計思想是輕巧、開放、簡單、規范，易於實現。這些特點使得它對很多場景來說都是很好的選擇，特別是對於受限的環境如機器與機器的通信（M2M）以及物聯網環境。相對於XMPP，MQTT更加輕量級，並且佔用的寬頻低。
MQTT協議有以下特點：
那麼問題來了？重連連接成功後重復接收到最後一條消息
MQTT推送消息訂閱端重復接收問題。
（背景）訂閱端斷開的時候，發布端多次推送消息。
（現象）訂閱端啟動時，接收到最後一條推送消息有兩次；即使Qos設置為2；依然是兩次。
經排查是因為
MqttMessage的Retained設置為了true;
該值很多文章上只說了是 消息保留機制，若設置為true，mqtt伺服器會保留每次發布的消息；較少提到 若訂閱某主題的客戶端重啟，則會把此主題之前發布的消息重新推送到客戶端。該值默認為false;去掉修改該值即可
那麼問題來了？重連連接後手動那麼多遺漏的消息，怎麼選擇只接收最新的一條消息呢？
MQTT推送消息訂閱端重復接收問題。
（背景）訂閱端斷開的時候，發布端多次推送消息。
（現象）訂閱端啟動時，接收到msg1，msg2，msg3 （這三個消息都是同一個類型消息，只需要處理最新的msg3就好，不然界面會刷新三次）這個誰有什麼好辦法沒呢？
GitHub地址： https://github.com/eclipse/paho.mqtt.android
mqtt的官方文檔： http://mqtt.org/documentation
Github上有中文翻譯： https://github.com/mcxiaoke/mqtt
在mole的build.gradle文件中添加依賴
在 AndroidManifest.xml 添加限權
在 AndroidManifest.xml 注冊Service （MyMqttService為自己寫的服務，下文會講到）
3. android系統的APP消息推送機制
參考文章：
http://blog.csdn.net/carson_ho/article/details/52862418
1. 主流的第三方推送平台分類
手機廠商類：小米推送、華為推送。
第三方平台類：友盟推送、極光推送、雲巴（基於MQTT）
BAT大廠的平台推送：阿里雲移動推送、騰訊信鴿推送、網路雲推送
2. 對比其他推送方式的特點
其他推送方式還有：C2DM、輪詢、SMS、MQTT協議、XMPP協議等等，相對於這些推送方式，第三方推送方式的特點分別是：
優點：
成本低
上述的推送大多數是免費的，假如自己實現則消耗過多資源（開發成本和後台管理、統計成本）
消息到達率高
如果一個手機里有多個App使用了同一家推送服務，那麼這些App將共用一條消息通道，即使你家的App推送服務被殺死了，那麼只要用戶打開了其他集成該推送服務的App，你家的推送就能到達用戶
缺點
安全性低
使用別人的伺服器，所以你懂的。
服務會被殺死
由於Android系統的機制，後台推送 Service 會被各種主動的或是被動的行為給殺死，而服務一旦被殺死，意味著就接收不到推送消息。
3. 第三方推送服務方式的特點
第三方服務基本都具備免費、和到達率高的特點
那麼應該如何選擇呢？我們來分別看一下第三方推送各種方式的優點：
3.1 手機廠商推送
請記住一個潛規則：操作系統是不會殺死屬於自己品牌的推送服務。
手機廠商的推送服務在自家的手機上屬於系統級別的服務，這意味著系統不會殺死自家的推送服務
比如說，Android原生系統是不會殺死C2DM消息推送服務，MIUI系統是不會殺死小米的推送服務。
當今市場上的Android手機系統份額最高是MIUI系統，即小米（具體排名請看http://www.umindex.com/）
因為：免費、到達率高且在Android系統市場份額第一的MIUI系統上不被殺死。所以，如果要選擇手機廠商的推送服務，請選擇小米推送作為第三方平台實現推送服務
下面一些應用可以從側面來證明我的推斷：
騰訊新聞使用的小米推送，沒有使用自己家的信鴿推送
淘寶使用了自家的阿里雲推送，同時還集成了小米推送
網路視頻和愛奇藝使用的是小米推送，沒有用自家的網路推送
官網截圖 - 集成應用：
如果希望進一步提高推送的效果，其實可以集成多個手機廠商的推送服務
比如小米渠道用小米推送，華為渠道用華為推送，但這樣的實現成本會大一些
3.2 第三方平台類
請記住一個規則：推送系統會共享一條推送渠道
這意味著假設你接入了友盟推送，而恰好今日頭條也接入了友盟。
有一天你的App被殺死了，但這時用戶啟動了今日頭條，那麼推送系統也就會通過共享的推送通道順便把你推送消息送達到手機上，然後還可能把你的進程也喚醒（被「保活」了）。
所以說，關於如何選擇第三方平台類的推送，推送平台的規模效應就很重要了。
那如何得知他們的規模和市場份額呢？按個人經驗，主要看兩點：
問內部的朋友。
看推送平台的合作客戶里有哪些大的app - 參考對應官網的合作案例
3.3 BAT大廠的推送
BAT大廠其實並沒有什麼優勢，同時謹記：
不要以為用了騰訊信鴿推送，就能占上微信的光保證你的App永遠內部被殺死。
說個題外話，手機淘寶除了自家的阿里雲的移動推送，同時也使用其它的第三方推送平台啊（比如友盟推送）。
4. 如何選擇第三方平台推送服務？
主要從用戶類別+實現成本+渠道來選擇不同的使用場景
1. 如果用戶群體精準（使用小米手機或華為手機居多），可以考慮只集成對應手機廠商的推送；
注意：單一的手機廠商也能工作，比如小米推送在非小米手機上當然也能工作，只不過不是系統級別的服務了，容易被殺死。
如果用戶群體廣泛、希望實現成本低，可以考慮只使用單一第三方平台類的推送（極光、友盟blabla，選一個規模效應最大的）
如果用戶群體廣泛、不在意實現成本，個人建議：
對於小米手機，使用小米推送；
對於華為手機，使用華為推送；
對於其他手機，只使用單一第三方平台類的推送（極光、友盟blabla，選一個規模效應最大的）
讓不同的推送運行在各自擅長的環境里，最大化實現推送的到達率和產品的存活率
大家可以根據自己的使用場景來進行消息推送平台的選擇。
5. 推送消息類別的選擇
5.1 推送消息的類別
通常第三方推送平台都支持兩種推送消息類型：通知欄消息和透傳消息。
通知欄消息：該類消息在被送達用戶的設備後，直接以系統通知欄的形式展示給用戶
不會繼續被傳遞到App
透傳消息：該類消息在被送達用戶的設備後，還會繼續傳遞到App
通過回調App的某個BroadcastReceiver的形式將消息傳遞到App內部。然後由App決定如何處理和顯示這個消息。
所以透傳消息不一定會以系統通知欄的形式進行推送，由程序猿自定義
5.2 消息類別的區別與特點
二者的區別在於：透傳消息在整個消息傳遞過程中比通知欄消息多了一步-傳遞到App
通知欄消息的優點：送達率高
因為透傳消息在整個消息傳遞過程中比通知欄消息多了一步-傳遞到App，因此透傳消息就增加一些被系統限制的概率，給系統殺死的概率就高一些，所以說，通知欄消息比透傳消息應該能提供更好的送達率。
我們來看下小米推送的官方文檔描述：
在一些 Android 系統(如 MIUI)中，受到系統自啟動管理設置的限制,應用不能在後台自啟動
在這類系統中，如果在發送消息的時候對應的應用沒有被啟動，透傳類消息將不能順利送達。
因此,對於對送達率要求很高的消息,建議盡量採用通知欄提醒的方式推送消息
透傳消息的優點：對消息操作程度高 & 自定義程度高
提供了對消息數據的更靈活的操縱能力。
App如果僅僅通過通知欄消息，是無法接觸到消息數據本身的。
可自定義通知提醒的樣式（包括提示樣式、提示形式如聲音等等）
所以大家可以根據不同的使用場景來對推送消息類別進行選擇了。
4. java伺服器推送消息給android
幾種常見的解決方案實現原理
1）輪詢(Pull)方式：客戶端定時向伺服器發送詢問消息，一旦伺服器有變化則立即同步消息。
2）SMS(Push)方式：通過攔截SMS消息並且解析消息內容來了解伺服器的命令，但這種方式一般用戶在經濟上很難承受。
3）持久連接(Push)方式：客戶端和伺服器之間建立長久連接，這樣就可以實現消息的及時行和實時性。
3、消息推送解決方案概述
A、C2DM雲端推送方案
在Android手機平台上，Google提供了C2DM（Cloudto Device Messaging）服務。Android
Cloud to Device Messaging (C2DM)是一個用來幫助開發者從伺服器向Android應用程序發送數據的服務。該服務提供了一個簡單的、輕量級的機制，允許伺服器可以通知移動應用程序直接與伺服器進行通信，以便於從伺服器獲取應用程序更新和用戶數據。
該方案存在的主要問題是C2DM需要依賴於Google官方提供的C2DM伺服器，由於國內的網路環境，這個服務經常不可用。
B、MQTT協議實現Android推送
採用MQTT協議實現Android推送功能也是一種解決方案。MQTT是一個輕量級的消息發布/訂閱協議，它是實現基於手機客戶端的消息推送伺服器的理想解決方案。
wmqtt.jar
是IBM提供的MQTT協議的實現。我們可以從這里（https://github.com/toku/AndroidPushNotificationsDemo）下載該項目的實例代碼，並且可以找到一個採用php書寫的伺服器端實現（https://github.com/toku/PhpMQTTClient）。
C、RSMB實現推送功能
Really Small Message Broker (RSMB)
，是一個簡單的MQTT代理，同樣由IBM提供，其查看地址是：http://www.alphaworks.ibm.com/tech/rsmb。預設打開1883埠，應用程序當中，它負責接收來自伺服器的消息並將其轉發給指定的移動設備。SAM是一個針對MQTT寫的PHP庫。我們可以從這個http://pecl.php.net/package/sam/download/0.2.0地址下載它.
D、XMPP協議實現Android推送
Google官方的C2DM伺服器底層也是採用XMPP協議進行的封裝。XMPP(可擴展通訊和表示協議)是基於可擴展標記語言（XML）的協議，它用於即時消息（IM）以及在線探測。這個協議可能最終允許網際網路用戶向網際網路上的其他任何人發送即時消息。
androidpn是一個基於XMPP協議的java開源Android push notification實現。它包含了完整的客戶端和伺服器端。但也存在一些不足之處：
1）
比如時間過長時，就再也收不到推送的信息了。
2）性能上也不夠穩定。
3）如果將消息從伺服器上推送出去，就不再管理了，不管消息是否成功到達客戶端手機上。
如果我們要使用androidpn，則還需要做大量的工作，需要理解XMPP協議、理解Androidpn的實現機制，需要調試內部存在的BUG。
5. 如何實現android和伺服器的長連接
轉載 這種功能實際上就是數據同步，同時要考慮手機本身、電量、網路流量等等限制因素，所以通常在移動端上有一下兩個解決方案:
1.一種是定時去server查詢數據，通常是使用HTTP協議來訪問web伺服器，稱Polling（輪詢）；
2.還有一種是移動端和伺服器建立長連接，使用XMPP長連接，稱Push（推送）。
從耗費的電量、流量和數據延遲性各方面來說，Push有明顯的優勢。但是使用Push的缺點是：
對於客戶端：實現和維護相對成本高，在移動無線網路下維護長連接，相對有一些技術上的開發難度。
對於伺服器：如何實現多核並發，cpu作業調度，數量龐大的長連接並發維護等技術，仍存在開發難點。
在講述Push方案的原理前，我們先了解一下移動無線網路的特點。
移動無線網路的特點：
因為 IP v4 的 IP 量有限，運營商分配給手機終端的 IP 是運營商內網的 IP，手機要連接 Internet，就需要通過運營商的網關做一個網路地址轉換（Network Address Translation，NAT）。簡單的說運營商的網關需要維護一個外網 IP、埠到內網 IP、埠的對應關系，以確保內網的手機可以跟 Internet 的伺服器通訊
GGSN（Gateway GPRS
Support Node 網關GPRS支持結點）模塊就實現了NAT功能。
因為大部分移動無線網路運營商都是為了減少網關的NAT映射表的負荷，所以如果發現鏈路中有一段時間沒有數據通訊時，會刪除其對應表，造成鏈路中斷。（關於NAT的作用及其原理可以查看我的另一篇博文：關於使用UDP(TCP)跨區域網，NAT穿透的心得）
Push在Android平台上長連接的實現：
既然我們知道我們移動端要和Internet進行通信，必須通過運營商的網關，所以，為了不讓NAT映射表失效，我們需要定時向Internet發送數據，因為只是為了不然NAT映射表失效，所以只需發送長度為0的數據即可。
這時候就要用到定時器，在android系統上，定時器通常有一下兩種：
1.java.util.Timer
2.android.app.AlarmManager
分析：
Timer:可以按照計劃或者時間周期來執行相關的任務。但是Timer需要用WakeLock來讓CPU保持喚醒狀態，才能保證任務的執行，這樣子會消耗大量流量；當CPU處於休眠的時候，就不能喚醒執行任務，所以應用於移動端明顯是不合適。
AlarmManager：AlarmManager類是屬於android系統封裝好來管理RTC模塊的管理類。這里就涉及到RTC模塊，要更好地了解兩者的區別，就要明白兩者真正的區別。
RTC（Real- Time Clock）實時鬧鍾在一個嵌入式系統中，通常採用RTC
來提供可靠的系統時間，包括時分秒和年月日等;而且要求在系統處於關機狀態下它也能夠正常工作（通常採用後備電池供電），它的外圍也不需要太多的輔助電路，典型的就是只需要一個高精度的32.768KHz
晶體和電阻電容等。（如果對這方面感興趣，可以自己查閱相關資料，這里就說個大概）
好了，回來正題。所以，AlarmManager又稱全局定時鬧鍾。這意味著，當我用使用AlarmManager來定時執行任務，CPU可以正常地休眠，只有在執行任務是，才喚醒CPU，這個過程是很短時間的。
下面簡單來說明其使用：
1.類似於Timer功能：
//獲得鬧鍾管理器
AlarmManager
am = (AlarmManager)getSystemService(ALARM_SERVICE);
//設置任務執行計劃
am.setRepeating(AlarmManager.ELAPSED_REALTIME, firstTime, 5*1000,
sender);//從firstTime才開始執行，每隔5秒再執行
2.實現全局定時功能：
//獲得鬧鍾管理器
AlarmManager
am = (AlarmManager)getSystemService(ALARM_SERVICE);
//設置任務執行計劃
am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstTime,
5*1000, sender);//從firstTime才開始執行，每隔5秒再執行
總結：在android客戶端使用Push推送時，應該使用AlarmManager來實現心跳功能，使其真正實現長連接。