01

一個近場通信的例子

1.1 全場景智慧生活的典型問題

在全場景智慧生活當中，設備種類和數(shù)量越來越多，各種富設備（如智慧屏、PC、PAD、音箱）以及各種瘦設備（如IOT的智能門鎖、攝像頭、智能燈、智能窗簾）的近場通信方式各不相同，有wifi、藍牙、NFC、usb、zigbee等。

在這么多種近場通信方式選擇上，如何讓這些設備便捷、高效地通信，從而實現(xiàn)上層應用無需考慮設備差異，就如同使用“一個設備”一樣，流暢地使用多個設備的能力，是全場景智慧生活中面臨的一個典型問題。HarmonyOS分布式軟總線為這個問題提供了可靠的解決方案，并通過簡單的API接口向開發(fā)者開放出來。

1.2 如何保障控制消息（Message）低時延高可靠

下圖是一個家庭場景中典型的富瘦設備的組網(wǎng)圖，主要包含兩類業(yè)務，黑色線條的上網(wǎng)業(yè)務，紅色線條的近場業(yè)務。橫向的近場通信業(yè)務的物理通道，比縱向的上網(wǎng)業(yè)務的物理通道種類更多，帶寬也不同，HarmonyOS分布式軟總線完全屏蔽了底層通信的差異，讓上層應用通過使用幾個簡單的軟總線接口，就像使用本地接口一樣，輕松實現(xiàn)多設備間高速通信。

舉個例子，將手機上的游戲App的操作界面投屏到PAD上，如何實現(xiàn)在PAD上進行手機上游戲APP的控制如在手機上控制一樣的流暢？其中，使用軟總線的SendMessage接口完成PAD到手機的反控操作（華為Cast+技術）Message的無延遲傳輸，起到了一個關鍵的作用。具體實現(xiàn)如下：

前提條件：

1、 手機、PAD均搭載了HarmonyOS，具備分布式軟總線能力

2、 手機已經(jīng)把游戲APP的操作界面投屏到PAD上

過程描述：

1、 手機首先使用軟總線的發(fā)現(xiàn)能力發(fā)現(xiàn)PAD設備，并把手機上游戲APP的操作界面投屏到PAD。

2、 因為游戲APP本身在手機上，所以在PAD上操作手機游戲APP，就是從PAD到手機的“反控操作”，即PAD上控制消息Message反饋到手機上執(zhí)行，PAD和手機之間需要通過軟總線建立控制通道。軟總線要選擇最優(yōu)傳輸通道，并保障該通道上的數(shù)據(jù)得到高優(yōu)先級的傳輸。

3、 PAD調用SendMessage接口把控制消息Message反饋給手機。

4、 手機收到PAD的反控消息并執(zhí)行，并把執(zhí)行后的結果再反饋到PAD上。整個過程的時延要求在百毫秒級。

上面描述的過程看似簡單，實際上底層通信使用到了HarmonyOS分布式軟總線的發(fā)現(xiàn)、連接和傳輸?shù)哪芰?。本次不講發(fā)現(xiàn)和連接的技術點，僅對傳輸?shù)膶崿F(xiàn)原理進行解釋。

02

近場Message/Byte傳輸實現(xiàn)原理

2.1 實現(xiàn)過程描述

HarmonyOS分布式軟總線提供了兩個接口，分別用于近場通信場景下長短消息的傳輸，分別是SendMessage和SendByte，實現(xiàn)原理相同，如下圖所示：

圖中APP X統(tǒng)一代表不同的上層應用App。具體過程描述：

1）設備A和設備B的APP X會在初始化階段向軟總線注冊回調通知接口，用于在傳輸通道打開、數(shù)據(jù)接收后通知到APP X

2）設備A的APP X要向設備B上的APP X發(fā)送消息，設備A的APP X首先把設備B的設備ID信息、以及標識APP X的信息傳遞給軟總線，請求一個傳輸通道。

3）軟總線要根據(jù)當前兩個設備已有的物理通道種類（BR/BLE/WIFI2.4/Wifi 5G/P2P），以及物理通道的負載和設備的狀態(tài)，決策選擇一個最優(yōu)的傳輸通道的底層連接，同時完成傳輸層的連接建立，和傳輸標識的內(nèi)核態(tài)到用戶態(tài)的映射，最后把傳輸通道標識傳遞到兩個設備的上層APP X。

4）設備A的APP X拿到通道標識后再調用SendMessage/SendByte接口和設備B的APP X進行通信。設備B的APP X也可以使用相同的方法和設備A進行通信。

5）傳輸結束后，設備A的APP X可以調用關閉傳輸接口完成傳輸通道資源的釋放。

2.2 Message/Byte傳輸注意事項

1）Message類型主要用于低時延、高可靠業(yè)務，比如游戲的控制命令、IoT設備的開關（燈的開關、門窗的開關）等等，數(shù)據(jù)量最大不超過4KB。

2）SendMessage對Message類型消息的傳輸，HarmonyOS軟總線在底層實現(xiàn)按照最高優(yōu)先級進行傳輸，例如空口使用最高優(yōu)先級VO隊列。因此在實際使用中，為了獲得更低的時延，最好是一幀數(shù)據(jù)就能把Message消息發(fā)送完成。比如1.5KB大小，保證空口一幀就發(fā)送完成，減少空口的資源競爭和退避帶來的時延開銷。

3）Byte類型主要用于傳輸比Message類型消息大，時延要求沒那么高的業(yè)務。比如傳輸一個圖片的縮略圖。通常最大不超過4M大小。具體大小取決于設備的內(nèi)存大小，有些設備內(nèi)存小，則其Byte類型消息不會超過4M。

4）SendByte除了用于時延要求不高的基本業(yè)務數(shù)據(jù)傳輸外，也可以用于探測網(wǎng)絡端與端之間的時延，比如探測當前網(wǎng)絡傳輸1MB數(shù)據(jù)需要多少時間。

5）在支持多種物理鏈路的情況下，不建議上層應用指定具體的物理鏈路，讓HarmonyOS系統(tǒng)自動選擇，系統(tǒng)會根據(jù)當前的網(wǎng)絡情況選擇最優(yōu)的傳輸通道。

6）傳輸?shù)幕卣{接口，不要有阻塞性動作，特別是對于持續(xù)性的傳輸，如果在回調中有阻塞性動作，會導致傳輸性能下降。 本次為大家簡單介紹HarmonyOS Message/Byte類型消息的底層傳輸原理，這兩個都是數(shù)據(jù)量比較?。˙yte/M）且非持續(xù)性的消息傳輸，對于規(guī)格比較大（G）且有持續(xù)性傳輸要求的File和Stream類型數(shù)據(jù)傳輸，會在后續(xù)技術解析文章中進行講解，敬請期待！

本文作者：zhangkesi，華為軟件架構設計工程師

編輯：jq