微信開(kāi)發(fā)協(xié)議的示例分析

這篇文章主要介紹微信開(kāi)發(fā)協(xié)議的示例分析，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

1.發(fā)布的消息對(duì)應(yīng)一個(gè)ID（只要單個(gè)方向唯一即可，服務(wù)器端可能會(huì)根ID判斷重復(fù)接收），消息重傳機(jī)制確保有限次的重試，重試失敗給予用戶提示，發(fā)送成功會(huì)反饋確認(rèn)，客戶端只有收到確認(rèn)信息才知道發(fā)送成功。發(fā)送消息可能不會(huì)產(chǎn)生新SyncKey。

2.基于版本號(hào)（SynKey）的狀態(tài)消息同步機(jī)制，增量、有序傳輸需求水到渠成。長(zhǎng)連接通知/短連接獲取、確認(rèn)等，交互方式簡(jiǎn)單，確保了消息可靠譜、準(zhǔn)確無(wú)誤到達(dá)。

3.客戶端/服務(wù)器端都會(huì)存儲(chǔ)消息ID處理記錄，避免被重復(fù)消費(fèi)客戶端獲取最新消息，但未確認(rèn)，服務(wù)器端不會(huì)認(rèn)為該消息被消費(fèi)掉。下次客戶端會(huì)重新獲取，會(huì)查詢當(dāng)前消息是否被處理過(guò)。根據(jù)一些現(xiàn)象猜測(cè)。

4.總體上看，微信協(xié)議跨平臺(tái)（TCP或HTPP都可呈現(xiàn)，處理方式可統(tǒng)一），通過(guò)“握手”同步，很可靠，無(wú)論哪一個(gè)平臺(tái)都可以支持的很好

5.微信協(xié)議最小成本為16字節(jié)，大部分時(shí)間若干個(gè)消息包和在一起，批量傳輸。微信協(xié)議說(shuō)不上最簡(jiǎn)潔，也不是最節(jié)省流量，但是非常成功的。

6.若服務(wù)器檢測(cè)到一些不確定因素，可能會(huì)導(dǎo)致微啟用安全套接層SSL協(xié)議進(jìn)行常規(guī)的TCP長(zhǎng)連接傳輸。短連接都沒(méi)有發(fā)生變化

7.發(fā)送消息方式

發(fā)送消息走已經(jīng)建立的TCP長(zhǎng)連接通道，發(fā)送消息到服務(wù)器，然后接受確認(rèn)信息等，產(chǎn)生一次交互。

小伙伴接收到信息閱讀也都會(huì)收到服務(wù)器端通知，產(chǎn)生一次交互等。

可以確定，微信發(fā)送消息走TCP長(zhǎng)連接方式，因?yàn)椴粚?duì)自身狀態(tài)數(shù)據(jù)產(chǎn)生影響，應(yīng)該不交換SyncKey。

在低速網(wǎng)絡(luò)下，大概會(huì)看到消息發(fā)送中的提示，屬于消息重發(fā)機(jī)制

網(wǎng)絡(luò)不好有時(shí)客戶端會(huì)出現(xiàn)發(fā)送失敗的紅色感嘆號(hào)

已發(fā)送到服務(wù)器但未收到確認(rèn)的消息，客戶端顯示紅色感嘆號(hào)，再次重發(fā)，服務(wù)器作為重復(fù)消息處理，反饋確認(rèn)

上傳圖片，會(huì)根據(jù)圖片大小，分割成若干部分（大概1.5K被劃分為一部分），同一時(shí)間點(diǎn)，客戶端會(huì)發(fā)起若干次POST請(qǐng)求，各自上傳成功之后，服務(wù)器大概會(huì)合并成一個(gè)完整圖片，返回一個(gè)縮略圖，顯示在APP聊天窗口內(nèi)。APP作為常規(guī)的文字消息發(fā)送到服務(wù)器端

上傳音頻，則單獨(dú)走TCP通道，一個(gè)兩秒的錄制音頻，客戶端錄制完畢，分為兩塊傳輸，一塊最大1.5K左右，服務(wù)端響應(yīng)一條數(shù)據(jù)通知確認(rèn)收到。共三次數(shù)據(jù)傳輸。

音頻和純文字信息一致，都是走TCP長(zhǎng)連接，客戶端發(fā)送，服務(wù)器端確認(rèn)。

以上是“微信開(kāi)發(fā)協(xié)議的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！