透過本教學給大家分享微信開發(fā)協(xié)議總結(jié)說明的相關(guān)知識，非常不錯，具有一定的參考借鑒價值，有興趣的朋友一起看看吧

#1.發(fā)佈的訊息對應一個ID（只要單一方向唯一即可，服務器端可能會根ID判斷重複接收），訊息重傳機制確保有限次的重試，重試失敗給予使用者提示，發(fā)送成功會回饋確認，客戶端只有收到確認訊息才知道發(fā)送成功。 發(fā)送訊息可能不會產(chǎn)生新SyncKey。

2.基於版本號（SynKey）的狀態(tài)訊息同步機制，增量、有序傳輸需求水到渠成。長連線通知/短連線取得、確認等，互動方式簡單，確保了訊息可靠譜、準確無誤到達。

3.客戶端/伺服器端都會儲存訊息ID處理記錄，避免被重複消費客戶端取得最新訊息，但未確認，伺服器端不會認為該訊息被消費掉。下次客戶端會重新獲取，會查詢目前訊息是否已處理過。根據(jù)一些現(xiàn)象猜測。

4.整體來看，微信協(xié)定跨平臺（TCP或HTPP都可呈現(xiàn)，處理方式可統(tǒng)一），透過「握手」同步，很可靠，無論哪一個平臺都可以支援的很好

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

6.若伺服器偵測到一些不確定因素，可能會導致微啟用安全通訊端層SSL協(xié)定進行常規(guī)的TCP長連線傳輸。短連線都沒有改變

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

發(fā)送訊息走已經(jīng)建立的TCP長連線通道，發(fā)送訊息到伺服器，然後接受確認訊息等，產(chǎn)生一次互動。

小夥伴接收到訊息閱讀也會收到伺服器端通知，產(chǎn)生一次互動等。

可以確定，微信發(fā)送訊息走TCP長連接方式，因為不對自身狀態(tài)資料產(chǎn)生影響，應該不交換SyncKey。

在低速網(wǎng)路下，大概會看到訊息傳送中的提示，屬於訊息重發(fā)機制

網(wǎng)路不好有時客戶端會出現(xiàn)傳送失敗的紅色感嘆號

#已傳送至伺服器但未收到確認的訊息，用戶端顯示紅色感嘆號，再次重發(fā)，伺服器作為重複訊息處理，回饋確認

上傳圖片，會根據(jù)圖片大小，分割成若干部分（大概1.5K被分割為一部分），同一時間點，客戶端會發(fā)起若干次POST請求，各自上傳成功之後，伺服器大概會合併成一個完整圖片，回傳一個縮圖，顯示在APP聊天視窗內(nèi)。 APP作為常規(guī)的文字訊息發(fā)送到伺服器端

上傳音頻，則單獨走TCP通道，一個兩秒的錄製音頻，客戶端錄製完畢，分為兩塊傳輸，一塊最大1.5K左右，服務端回應一則資料通知確認收到。共三次資料傳輸。

音訊和純文字訊息一致，都是走TCP長連接，客戶端發(fā)送，伺服器端確認。

以上所述是小編給大家介紹的微信開發(fā)協(xié)議小結(jié)，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回覆大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持！

以上是微信開發(fā)協(xié)議總結(jié)說明的詳細內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！