androidmqtt客戶端

㈠ 如何採用mqtt協議實現android消息推送

使用一個代理伺服器message broker，客戶端client連接上這個伺服器，然後告訴伺服器，可以接收哪些類型的消息，同時client也可以發布自己的消息，這些消息根據協議的內容，可以別的client獲取。這樣就實現了消息推送。
消息推送是通過一定的技術標准或協議，在互聯網上通過定期傳送用戶需要的信息來減少信息過載的一項新技術。
如果想要使用消息推送，推薦使用深圳極光的消息推送系統。深圳極光是國內首個為移動應用開發者提供專業、高效的消息推送服務的產品。品牌成長的過程，就是與客戶肩並肩邁向成功的過程。極光將以市場為導向，以創新為動力，以技術為支持，不斷用心努力，為每一位尊貴的客戶提供極致的服務。

㈡ Android使用MQTT通訊

主要講下Android如何使用MQTT通訊。用到的軟體或者框架有：

EMQ： https://www.emqx.io/cn/
org.eclipse.paho的MQTT通訊框架： https://github.com/eclipse/paho.mqtt.android

如果已經有MQTT相關服務，可以跳過第一項，從第二項開始看。

1.安裝所需要的依賴包

2.使用以下命令設置穩定存儲庫，以 CentOS7 為例

3.安裝最新版本的 EMQ X

4.安裝特定版本的 EMQ X

5.啟動 EMQ X

地址：xxx.xxx.xxx:18083，地址為伺服器ip或者域名，埠為18083埠

1.在Android中導入依賴

項目地址： https://github.com/eclipse/paho.mqtt.android
2.創建MQTT連接的一個Service

㈢ 如何寫一個MQTT連接的android客戶端

MQTT是一個輕量級的消息發布/訂閱協議，它是實現基於手機客戶端的消息推送伺服器的理想解決方案。 我們可以從這里下載該項目的實例代碼，並且可以找到一個採用php書寫的伺服器端實現。 架構如下所示： wmqtt.jar 是IBM提供的MQTT協議的實現。你可以從如下站點下載它。你可以將該jar包加入你自己的Android應用程序中。 Really Small Message Broker (RSMB) ，他是一個簡單的MQTT代理，同樣由IBM提供。預設打開1883埠，應用程序當中，它負責接收來自伺服器的消息並將其轉發給指定的移動設備。 SAM是一個針對MQTT寫的PHP庫。你可以從這個下載它. send_mqtt.php是一個通過POST接收消息並且通過SAM將消息發送給RSMB的PHP腳本。 實例代碼： Ø 採用XMPP協議實現Android推送 這是我在項目中採用的方案。事實上Google官方的C2DM伺服器底層也是採用XMPP協議進行的封裝。 XMPP(可擴展通訊和表示協議)是基於可擴展標記語言（XML）的協議，它用於即時消息（IM）以及在線探測。這個協議可能最終允許網際網路用戶向網際網路上的其他任何人發送即時消息。 androidpn是一個基於XMPP協議的java開源Android push notification實現。它包含了完整的客戶端和伺服器端。經過源代碼研究我發現，該伺服器端基本是在另外一個開源工程openfire基礎上修改實現的，不過比較郁悶的是androidpn的文檔是由韓語寫的，所以整個研究過程基本都是讀源碼。它的實現示意圖如下： androidpn客戶端需要用到一個基於java的開源XMPP協議包asmack，這個包同樣也是基於openfire下的另外一個開源項目smack，不過我們不需要自己編譯，可以直接把androidpn客戶端裡面的asmack.jar拿來使用。客戶端利用asmack中提供的XMPPConnection類與伺服器建立持久連接，並通過該連接進行用戶注冊和登錄認證，同樣也是通過這條連接，接收伺服器發送的通知。 androidpn伺服器端也是java語言實現的，基於openfire開源工程，不過它的Web部分採用的是spring框架，這一點與openfire是不同的。Androidpn伺服器包含兩個部分，一個是偵聽在5222埠上的XMPP服務，負責與客戶端的XMPPConnection類進行通信，作用是用戶注冊和身份認證，並發送推送通知消息。另外一部分是Web伺服器，採用一個輕量級的HTTP伺服器，負責接收用戶的Web請求。伺服器架構如下： 最上層包含四個組成部分，分別是SessionManager，Auth Manager，PresenceManager以及Notification Manager。SessionManager負責管理客戶端與伺服器之間的會話，Auth Manager負責客戶端用戶認證管理，Presence Manager負責管理客戶端用戶的登錄狀態，NotificationManager負責實現伺服器向客戶端推送消息功能。 伺服器端界面如下，分別對應了上述的幾個功能模塊： 發送以後，我們可以在手機端看到接收的消息：

㈣ 安卓mqtt 同一個客戶端ip是否會踢掉前一個連接

不會，除非客戶端CLIENTID一致，在連接時會將上一個相同clientId的連接踢掉，並且會出現EOFException。windows同一台PC機上面使用MQTT協議連接服務端，最多也就1000過些，因為埠有限。目前我也在做這個，使用LINUX操作系統，調整句柄數，這樣能連接的更多

㈤ 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產品及服務已深受國內百萬開發者的認可和信賴。

㈥ android studio怎麼安裝mqtt

1、 下載Apollo伺服器，下載後解壓，然後運行apache-apollo-1.6\bin\apollo.cmd，輸入create mybroker（名字任意取，這里是根據 官網 介紹的來取的）創建伺服器實例，伺服器實例包含了所有的配置，運行時數據等，並且和一個伺服器進程關聯。
2、create mybroker之後會在bin目錄下生成mybroker文件夾，裡麵包含有很多信息，其中etc\apollo.xml文件下是配置伺服器信息的文件，etc\users.properties文件包含連接MQTT伺服器時用到的用戶名和密碼，後面會介紹，可以修改原始的admin=password，可以接著換行添加新的用戶名密碼。
3、打開cmd，運行…apache-apollo-1.6\bin\mybroker\bin\apollo-broker.cmd run 開啟伺服器，可以在瀏覽器中輸入 http://127.0.0.1:61680/ 查看是否安裝成功，該界面展示了topic，連接數等很多信息。
經過上面的簡單步驟，伺服器基本上就已經完成，下一篇將介紹Android客戶端的編寫和注意事項。
客戶端使用的API，開始我使用的是mqtt-client，使用過後發現問題百出，不能很好的滿足要求，後來使用了官方推薦的 Eclipse Paho ，下面開始客戶端代碼的編寫，為了方便測試這里有android和j2se兩個工程：
1、新建android工程MQTTClient
2、MainActivity代碼如下：
[java] view plainprint?

package ldw.mqttclient;

import java.util.concurrent.Executors;

import java.util.concurrent.ScheledExecutorService;

import java.util.concurrent.TimeUnit;

import org.eclipse.paho.client.mqttv3.IMqttDeliveryToken;

import org.eclipse.paho.client.mqttv3.MqttCallback;

import org.eclipse.paho.client.mqttv3.MqttClient;

import org.eclipse.paho.client.mqttv3.MqttConnectOptions;

import org.eclipse.paho.client.mqttv3.MqttException;

import org.eclipse.paho.client.mqttv3.MqttMessage;

import org.eclipse.paho.client.mqttv3.persist.MemoryPersistence;

import android.app.Activity;

import android.os.Bundle;

import android.os.Handler;

import android.os.Message;

import android.view.KeyEvent;

import android.widget.TextView;

import android.widget.Toast;

public class MainActivity extends Activity {

private TextView resultTv;

private String host = "tcp://127.0.0.1:1883";

private String userName = "admin";

private String passWord = "password";

private Handler handler;

private MqttClient client;

private String myTopic = "test/topic";

private MqttConnectOptions options;

private ScheledExecutorService scheler;

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.main);

resultTv = (TextView) findViewById(R.id.result);

init();

handler = new Handler() {

@Override

public void handleMessage(Message msg) {

super.handleMessage(msg);

if(msg.what == 1) {

Toast.makeText(MainActivity.this, (String) msg.obj,

Toast.LENGTH_SHORT).show();

System.out.println("-----------------------------");

} else if(msg.what == 2) {

Toast.makeText(MainActivity.this, "連接成功", Toast.LENGTH_SHORT).show();

try {

client.subscribe(myTopic, 1);

} catch (Exception e) {

e.printStackTrace();

}

} else if(msg.what == 3) {

Toast.makeText(MainActivity.this, "連接失敗，系統正在重連", Toast.LENGTH_SHORT).show();

}

}

};

startReconnect();

}

private void startReconnect() {

scheler = Executors.();

scheler.scheleAtFixedRate(new Runnable() {

@Override

public void run() {

if(!client.isConnected()) {

connect();

}

}

}, 0 * 1000, 10 * 1000, TimeUnit.MILLISECONDS);

}

private void init() {

try {

//host為主機名，test為clientid即連接MQTT的客戶端ID，一般以客戶端唯一標識符表示，MemoryPersistence設置clientid的保存形式，默認為以內存保存

client = new MqttClient(host, "test",

new MemoryPersistence());

//MQTT的連接設置

options = new MqttConnectOptions();

//設置是否清空session,這里如果設置為false表示伺服器會保留客戶端的連接記錄，這里設置為true表示每次連接到伺服器都以新的身份連接

options.setCleanSession(true);

//設置連接的用戶名

options.setUserName(userName);

//設置連接的密碼

options.setPassword(passWord.toCharArray());

// 設置超時時間 單位為秒

options.setConnectionTimeout(10);

// 設置會話心跳時間 單位為秒 伺服器會每隔1.5*20秒的時間向客戶端發送個消息判斷客戶端是否在線，但這個方法並沒有重連的機制

options.setKeepAliveInterval(20);

//設置回調

client.setCallback(new MqttCallback() {

@Override

public void connectionLost(Throwable cause) {

//連接丟失後，一般在這裡面進行重連

System.out.println("connectionLost----------");

}

@Override

public void deliveryComplete(IMqttDeliveryToken token) {

//publish後會執行到這里

System.out.println("deliveryComplete---------"

+ token.isComplete());

}

@Override

public void messageArrived(String topicName, MqttMessage message)

throws Exception {

//subscribe後得到的消息會執行到這裡面

System.out.println("messageArrived----------");

Message msg = new Message();

msg.what = 1;

msg.obj = topicName+"---"+message.toString();

handler.sendMessage(msg);

}

});

// connect();

} catch (Exception e) {

e.printStackTrace();

}

}

private void connect() {

new Thread(new Runnable() {

@Override

public void run() {

try {

client.connect(options);

Message msg = new Message();

msg.what = 2;

handler.sendMessage(msg);

} catch (Exception e) {

e.printStackTrace();

Message msg = new Message();

msg.what = 3;

handler.sendMessage(msg);

}

}

}).start();

}

@Override

public boolean onKeyDown(int keyCode, KeyEvent event) {

if(client != null && keyCode == KeyEvent.KEYCODE_BACK) {

try {

client.disconnect();

} catch (Exception e) {

e.printStackTrace();

}

}

return super.onKeyDown(keyCode, event);

}

@Override

protected void onDestroy() {

super.onDestroy();

try {

scheler.shutdown();

client.disconnect();

} catch (MqttException e) {

e.printStackTrace();

}

}

}

由於項目需要，我用到了心跳重連。根據 這里 的解釋設置apollo.xml，主要有設置主機連接的地址。另外，options還有個setWill方法，如果項目中需要知道客戶端是否掉線可以調用該方法。

㈦ MQTT在Android中的使用

MQTT 是一種基於發布訂閱模型的即時通訊協議,主要應用於物聯網設備中

MQTT主要需要MQ伺服器地址、用戶名、密碼、發布主題和響應主題，以及客戶端唯一標識

使用方法：

為了防止內存泄漏，我們使用Application的Context

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

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

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

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

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

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

(8)androidmqtt客戶端擴展閱讀：

推送消息注意事項：

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

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

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

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

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

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

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

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

㈨ 為什麼每份 Android 簡歷都說 「熟悉 MQTT 協議」

MQTT (Message Queuing Telemetry Transport，消息隊列遙測傳輸) 是一種基於 TCP/IP 協議族的應用層協議。MQTT 協議是專門針對硬體性能低下 & 網路狀況不穩定的場景設計的，這使得 MQTT 在物聯網和移動應用等受限場景得到廣泛應用。

目前，MQTT 主要分為兩個大版本：

物聯網和移動應用場景的特點是硬體性能低下和網路狀況不穩定，而 MQTT 協議就是專門針對這種環境設計的，主要在四個方面有優勢：

結論：這三種協議並沒有絕對的優勝者，最好的協議取決於具體的需求和限制條件。但如果只從帶寬、電池、功能多樣性這些基本條件看，MQTT 在其中是更占優的選擇。

MQTT 協議的設計特性中包含了一項 「高可靠性交付」，它需要一個保證可靠的底層傳輸層協議，因此 TCP 協議、TLS 協議、WebSocket 協議都可以作為 MQTT 的底層協議。而無連接的 UDP 協議會丟失或重排數據，不能滿足 MQTT 協議的傳輸需要。

MQTT 是基於發布 - 訂閱模型 (pub/sub) 的消息傳遞協議，與請求 - 響應模型不同，發布 - 訂閱模型主要有三種角色： publisher & subscriber & subscriber ：

當 client 發布某個主題的消息時，broker 會將該消息分發給任何已訂閱該主題的 client。通常來說，client 不會存儲消息，一旦消息被發送到這些 client，消息就會從 broker 上刪除。另外，保留消息、持久連接和服務質量 QoS 可能會導致消息臨時存儲在 broker 上。

發布 - 訂閱模式使得 消息的發布者和訂閱者解耦 ，主要體現為空間解耦和時間解耦：

圖片引用自 https://juejin.cn/post/6976441705067184135 —— cxuan 著

一個 MQTT 消息由三部分組成：

1、固定報頭： 每一個 MQTT 消息都包含一個固定報頭，包含消息類型、標志位和剩餘長度三個部分。固定報頭長度為 2 ~ 5 位元組，具體取決於 「剩餘長度」 的大小，格式如下：

2、可變報頭： 不同消息的可變報頭內容不一樣，不過其中有一個比較通用的欄位：

3、載荷： 某些 MQTT 消息會包含一個有效載荷，對於 PUBLISH 消息來說，有效載荷就是應用消息。

MQTT 的連接總是發生在 client 和 broker 之間，兩個 client 之間不會互相感知。請求連接時，client 會向 broker 發送 CONNECT 連接消息，broker 接受連接後會響應 CONNACK 連接確認消息。一旦連接建立，連接會一直保持打開狀態，直到 client 發送 DISCONNECT 斷開連接消息或連接異常中斷。

CONNECT 是 client 發送給 broker 的首個消息，並且在一次連接中，client 只能發送一次 CONNECT 消息，發送的第二個 CONNECT 消息會被 broker 當作違反協議處理，並斷開連接。在 CONNECT 消息中，主要包含以下內容：

CONNACK 消息用於確認 CONNECT 消息。CONNECT 是 client 發送給 broker 的首個消息，相應地，broker 發送給 client 的首個消息一定是 CONNACK 消息。在 CONNACK 消息中，主要包含以下內容：

DISCONNECT 消息由 client 發送給 broker，用於斷開連接。 DISCONNECT 消息沒有可變報頭和有效載荷，也沒有對應的確認應答消息，表示一個干凈利索地斷開連接操作 。斷開連接後，client 不能再發送除 CONNECT 消息之外的消息，broker 也需要丟棄和當前會話有環的遺囑消息。

MQTT 是基於發布訂閱模型的協議，在建立連接後，client 可以向 broker 訂閱感興趣的一個或多個話題。

SUBSCRIBE 消息由 client 發送給 broker，用於訂閱感興趣的話題，SUBSCRIBE 消息主要包含以下內容：

SUBACK 消息用於確認 SUBSCRIBE 消息。SUBACK 消息主要包含以下內容：

UNSUBSCRIBE 消息由 client 發送給 broker，用於退訂不感興趣的話題，UNSUBSCRIBE 消息主要包含以下內容：

UNSUBACK 消息用於確認 UNSUBSCRIBE 消息。UNSUBACK 消息非常簡單，只有一個包唯一標識（位於可變報頭）。

當 MQTT client 在連接到 broker 之後就可以發送消息了，每條 PUBLISH 消息都包含一個 topic ，broker 會根據 topic 將消息發送給感興趣的 client。除此之外，每條消息還會包含一個 Payload，Payload 是真正發布的應用消息，載荷的內容和格式由應用層決定，MQTT 協議層不關心。

PUBLISH 消息可以由 client 發送給 broker，也可以由 broker 發送給 client，用來運送應用層消息。PUBLISH 消息主要包含以下內容：

PUBLISH 消息的接收方需要發送確認應答，不同 QoS 等級的 PUBLISH 消息響應的消息不同：

當 client 和 broker 在一段時間內沒有數據交互時，client 會發送 PINGREQ 探測消息，用於判斷連接是否正常，來決定是否要關閉該連接，這就是 MQTT 協議的保活機制。

PINGREQ 消息由 client 發送給 broker。

PINGRESP 消息由 broker 發送給 client，代表 client 是存活的。

MQTT 主題本質上是一種 「定址形式」 ，用於將應用層消息分發到期望的客戶端。MQTT 主題是一種類似於文件系統的分層結構，使用 「/」 正斜杠 作為分隔符。

客戶端訂閱主題時，可以訂閱確定的主題（例如 「group/group123」），也可以使用 「通配符」 來同時訂閱多個主題。需要注意的是： 在發布消息是不允許使用主題通配符，client 每次發布消息只能發布到單個主題。

$SYS 主題是 broker 上默認創建的只讀主題，除此之外，broker 不會默認創建任何主題，所有主題都是由客戶端訂閱或發布才創建的，都不是永久性的。關於 $SYS 主題的更多介紹在 這里

當 client 連接到 broker 時，可以使用持久連接或非持久連接，這是通過 CONNECT 消息中的 CleanSession 標志來決定的（當 CleanSession = 0 時表示持久連接）。對於持久會話，broker 會存儲會話狀態；而對於非持久會話，broker 不會存儲 client 的任何內容。會話狀態主要包含以下內容：

QoS 0 等級的 PUBLISH 消息的交付能力完全依賴於底層傳輸層，QoS 1 和 QoS 2 等級開始在應用層提高 PUBLISH 消息的交付能力。當消息丟失時，發送端會重新發送早前嘗試發送過的 PUBLISH 消息（DUP = 1），接收者收到消息也會發送確認響應消息。

在 QoS 0 的等級的 PUBLISH 消息中不包含包唯一標識。發送者不考慮消息交付結果，接收者也不發送響應。接收者最多隻能收到一次消息，也有可能一次也收不到。

在 QoS 1 等級的 PUBLISH 消息中包含包唯一標識，發送方會一直將該消息當作 「未確認」 的消息，直到收到對應的 PUBACK 確認消息。具體消息流如下：

QoS 2 是最高的服務質量，保證消息不會丟失也不會重復，缺點是會增加開銷。在 QoS 2 等級的 PUBLISH 消息中包含包唯一標識，發送者會一直將該消息當作 「未確認」 的消息，知道收到對應的 PUBCOMP 確認消息。

當 client 發布某個主題的消息時，broker 會將該消息分發給任何已訂閱該主題的 client，隨後這條消息會從 broker 上刪除。可以設置 RETAIN 保留標志設置該 PUBLISH 消息為保留消息，broker 會存儲該主題的最後一條保留消息，當新的 client 注冊訂閱時，並且匹配該消息主題時，該保留消息會發送給訂閱者。 需要注意：broker 只會為每個主題保存最近一條保留消息，新收到的 RETAIN = 1 的消息會覆蓋原本那條保留消息；

持久會話 & 服務質量等級 & 保留消息都會影響新訂閱者是否接受消息，總結如下表：

標記 DUP = 1 的消息是重復發送的消息，MQTT 消息重傳有兩種場景：

需要注意：DUP 標志只對 OoS > 0 的消息有效，所有 QoS = 0 的消息 DUP 標志必須設置為 0；

TCP 協議的報文重傳機制是對所有 TCP 報文有效的重傳機制，而 MQTT 協議的消息重傳機制只對一小部分消息有效，用於實現更可靠的消息交付保證。雖然 TCP 協議在一般情況下可以保證不丟包，但是這並不是絕對的，依然存在請求超時或者連接中斷等情況。而 MQTT 協議的 QoS 1 和 QoS 2 要求更可靠的交付能力，並且需要在客戶端重連後也能保證交付。因此，MQTT 協議也定義了一個消息重傳機制。

到這里，關於 MQTT 協議的工作原理 & 協議消息格式 & 核心特性等內容就介紹完了。我知道你應該會對 MQTT 協議的實戰應用更加感興趣，下一篇文章里，我將帶你實現基於 MQTT 協議的 IM 服務，請關注。