androidxmpp接收消息

㈠ 怎麼實現伺服器給android客戶端主動推送消息

採用MQTT協議實現Android推送功能是一種解決方案。MQTT是一個輕量級的消息發布/訂閱協議，是實現基於手機客戶端的消息推送伺服器的理想解決方案。

常見的解決方案實現原理：

1、輪詢(Pull)方式：客戶端定時向伺服器發送詢問消息，一旦伺服器有變化則立即同步消息。

2、SMS(Push)方式：通過攔截SMS消息並且解析消息內容來了解伺服器的命令，但這種方式一般用戶在經濟上很難承受。

3、持久連接(Push)方式：客戶端和伺服器之間建立長久連接，這樣就可以實現消息的及時行和實時性。

(1)androidxmpp接收消息擴展閱讀：

推送消息注意事項：

1、支持第三方推送內容，是要客戶端和伺服器都支持的，客戶端和伺服器都導入推送SDK。

2、伺服器推送內容，可以精確指定推送時間，推送的具體接收人，用戶群，位置。

3、即推送的維度可以使時間，位置，人群。

4、極光使用了兩種不同的通知方式，一種是推送通知，一種是推送消息。

5、如果要使用androidpn，則還需要做大量的工作，需要理解XMPP協議、理解Androidpn的實現機制，需要調試內部存在的BUG。

參考資料來源：網路-伺服器

參考資料來源：網路-Android客戶端

參考資料來源：網路-信息推送

㈡ 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如果僅僅通過通知欄消息，是無法接觸到消息數據本身的。

可自定義通知提醒的樣式（包括提示樣式、提示形式如聲音等等）

所以大家可以根據不同的使用場景來對推送消息類別進行選擇了。

㈢ android xmpp退到後台怎麼接收消息

你是研究XMPP協議內容還是研究仿衡簡介面的調用？
如果是用現成的包是可以備褲中文的。如果是研究協議，有可能是因為離線模塊中攔腔文亂碼導致的錯誤。
XML二進制流傳遞過程用什麼文字沒有影響。！

㈣ 如何使用androidpn實現android手機消息推送

由於目前首塵仔的web項目中要用到android手機消息推送，嘗試過很多中方式之後發現，利用androidpn的部分代碼來實現這個功能是比較方便的。經過使用tsung進行簡單的壓力測試，證明這個框架能夠滿足大多數簡單應用的需求。
Androidpn包含有server和client兩個包，server部分可以作為伺服器單獨運行，也可以嵌入到web項目的servlet中，在tomcat環境中與web項目的其他部分交互。androidpn的簡單用法網上已經有很多文章介紹，這里就不細說了。主要談談如何將androidpn和自己的web程序整合到一起。
Server部分的主要包結構如下：
其中org.androidpn.server.，org.androidpn.server.model和org.androidpn.server.service為使用hibernate鏈接資料庫並實現簡單的用戶登錄認證，開發中可以用我們自己的認證模塊替換。剩下的包就是推送的主體實現。
接下來逐個包來看：
1.util包中的類用來載入resources中的配置文件，在配置文件中可指定監聽埠和ssl證書目錄等屬性。
2.org.androidpn.server.xmpp包裡面定義了一些異常類型，主要是包含有入口類XmppServer，這個類用來啟動和停止server程序。
3.org.androidpn.server.xmpp.auth包裡面是認證的一些類，我們自己的認證模塊可以在這里與androidpn進行結合。
4.org.androidpn.server.xmpp.codec是XMPP協議的XML文件解析包，server收到和發送的消息都要通過這個包來進行xmpp協議編碼和解碼。
5.org.androidpn.server.xmpp.handler包主要是對消息的處理，我們可以針對不同的消息類型定義自己的handler，
6.org.androidpn.server.xmpp.net包負責維護與client之間的持久連接，並實現了一些傳輸方式供發送xmpp消息時使用。
7.org.androidpn.server.xmpp.presence裡面只包含PresenceManager類，用兄手來維護client的在線狀態。
8.org.androidpn.server.xmpp.push包裡面的NotificationManager類包含有向client發送消息的介面。
9.org.androidpn.server.xmpp.router包負責將收到的信息包發送到相應的handler進行處理，是一個路由包。
10.org.androidpn.server.xmpp.session包定義了用來表示持久鏈接的session，每個session包含一條連接的狀態信息。
11.org.androidpn.server.xmpp.ssl是對連接進行ssl認證的工具包。
server發送消息的整個流程主者汪要是：
1. NotificationManager的push介面被調用。
2.使用SessionManager在當前session集合中查找相應的client鏈接。
3.定義自己的XMPP消息格式並組裝。
4.通過相應session，向client發送消息。
在這個流程中我們需要修改的是步驟3，也就是需要定義和組裝自己的xmpp消息，以便於將適當的信息傳到客戶端並便於客戶端解析。一個簡單的消息組裝例子如下：
private IQ createMessageIQ(String title, String message, String userId,
String json) {
Element notification = DocumentHelper.createElement(QName.get(
"message", INQURIE_NAMESPACE));
notification.addElement("title").setText(title);
notification.addElement("text").setText(message);
notification.addElement("userId").setText(userId);
notification.addElement("json").setText(json);
IQ iq = new IQ();
iq.setType(IQ.Type.set);
iq.setChildElement(notification);
return iq;
}

要注意的是在創建element的時候，傳入的namespace要和client解析使用的namespace相匹配。
server端接收和處理消息的流程是：
1.connection收到packet，使用tsc.push.server.xmpp.codec解碼。
2.router根據packet的namespace等信息，將packet路由到相應的handler。
3.handler進行處理。
相應的router和handler類在androidpn中都有例子可以參考，這里就不貼代碼了。開發中只要根據client發送消息的格式，定義自己的router和handler類，然後在PacketRouter中注冊router，在IQRouter中注冊handler即可。
Client部分的主要包結構如下：
這邊包含有消息的收發，解析以及持久連接的發起，重連等功能呢，十分強大，我們開發時完全不用管底層的連接，也不用擔心斷線，可以專注於業務部分的開發。
同時，代碼結構也很簡單。去除android的Service和BroadCast類以及一些工具類和常量類不談：
1.NotificationIQ,NotificationIQProvider,NotificationPacketListener三個類負責對收到的Notification格式的消息進行解析和處理，
2.XmppManager是主控制器，NotificationService通過這個類，在後台維護androidpn連接。
3.PersistentConnectionListener，PhoneStateChangeListener，ReconnectionThread.java三個類則負責監聽手機的狀態並進行斷線重連。

㈤ Android 幾種消息推送方案總結

Android 幾種消息推送方案總結:
一、使用GCM(Google Cloude Messaging) Android自帶的推送GCM可以幫助開發人員給他們的Android應用程序發送數據。它是一個輕量級的消息，告訴Android應用程序有新的數據要從伺服器獲取，或者是一個消息，其中包含了4KB的payload data（像即時通訊這類應用程序可以直接使用該payload消息）。
GCM服務處理排隊的消息，並把消息傳遞到目標設備上運行的Android應用程序。
二、使用XMPP協議（Openfire+Spark+Smark） XMPP是一種基於XML的協議，它繼承了在XML環境中靈活的發展性，有很強的可擴展性。包括上面講的GCM伺服器底層也是採用XMPP協議封裝的。
三、使用MQTT協議（想了解更多可以看http://mqtt.org/）輕量級的、基於代理的「發布/訂閱」模式的消息傳輸協議。
四、HTTP輪循方式。定時向HTTP服務端介面（Web Service API）獲取最新消息。
五、採用第三方服務。客戶端只需要導入第三方提供的lib庫，有第三方管理長連接，負責消息的接收/發送。同時對消息都有比較詳細的報表數據，可以用於做數據分析、挖掘，改善用戶體驗。
中合對比還是採用第三方服務簡捷高效。比如極光推送就很好用，極光推送搭建起一個高度穩定、可擴展的雲端架構，極大地幫助移動應用開發者節約開發和維護的成本，輕松實現毫秒級的精準推送。

㈥ android消息推送怎麼實現

極光推送可以輕松實現android消息推送。具有操作步驟如下:
1、到極光官網注冊賬號：https://www.jpush.cn/
2、創建應用，按照要求填寫你的應用名稱，包名提交
3、下載案例，一般情況測試是能收到信息的
4、集成到自己的項目中，按照官網的集成http://docs.jpush.cn/pages/viewpage.action?pageId=557214
5、集成時將注意的要點，官網上也有說，但是我再強調一下要注意兩個許可權的包名填寫，有可能直接用案例上的拷貝到自己的manifest中時沒有替換掉包名，切記，要替換成自己的項目的包名。
極光推送已經覆蓋了近10億Android、IOS終端，30多萬款APP應用，服務總用戶數超過30億，每天消息推送量達5億多條，已成為移動應用數據平台。極光分享幫助應用具備國內主流社交平台分享功能，提供新浪微博、QQ、微信等第三方社會化分享服務，提高產品推廣效率，幫助產品提高用戶體驗，獲得更多用戶。

㈦ android消息推送GCM、XMPP、MQTT三種方案的優劣，越仔細越好，有具體分析更好！

android消息推送GCM、XMPP、MQTT三種方案的優劣：
1、GCM服務（Google Cloud Messaging）優點：Google提供的服務、原生、簡單，無需實現和部署服務端。缺點：Android版本限制，該服務在國內不夠穩定、需要用戶綁定Google帳號，受限於Google。
2、XMPP協議（Openfire + Spark + Smack）優點：協議成熟、強大、可擴展性強、目前主要應用於許多聊天系統中，且已有開源的Java版的開發實例androidpn。缺點：協議較復雜、冗餘（基於XML）、費流量、費電，部署硬體成本高。
3、MQTT協議優點：協議簡潔、小巧、可擴展性強、省流量、省電，目前已經應用到企業領域，且已有C++版的服務端組件rsmb。缺點：不夠成熟、實現較復雜、服務端組件rsmb不開源，部署硬體成本較高。
d消息推送可以去了解一下極光，極光是個不錯的平台。極光緊密圍繞移動開發者需求，打造的開發者服務平台，可以提供一站式SaaS服務，通過全面覆蓋PC、手機、感測器、無線路由器等多種設備數據，打造全域數據平台。當前，不斷更新的SaaS產品及服務已深受國內百萬開發者的認可和信賴。

㈧ 如何自己搭建一個xmpp，實現推送消息

主要有三種方式：
1.客戶端定時去服務端取或者保持一個長Socket，從本質講這個不叫推送，這是去服務端拽數據。但是實現簡單，主要缺點：耗電等。
2.Google的C2DM，具體不細說，缺點，伺服器在國外，你懂得，不是很穩定。
3.XMPP協議，它是一種基於XML的傳遞協議，具有很強的靈活性和可擴展性。它的特點是將復雜性從客戶端轉移到了伺服器端。

接下來說說XMPP在android客戶端上的應用。分兩部分：服務端搭建和客戶端實現。

㈨ android xmpp實現消息推送，為什麼在手機後台運行一段時間就會掉線，而且不會重新登錄

建議對粗仿悔比下其他網路，最好選擇wifi環境下對大畝比。若其他網路正常，則可以判斷網路異常導致，建議更換網路環境或重新進行設岩正置等操作進行調節；