01

一個(gè)近場(chǎng)通信的例子

1.1 全場(chǎng)景智慧生活的典型問(wèn)題

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

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

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

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

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

前提條件：

1、 手機(jī)、PAD均搭載了HarmonyOS，具備分布式軟總線(xiàn)能力

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

過(guò)程描述：

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

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

3、 PAD調(diào)用SendMessage接口把控制消息Message反饋給手機(jī)。

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

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

02

近場(chǎng)Message/Byte傳輸實(shí)現(xiàn)原理

2.1 實(shí)現(xiàn)過(guò)程描述

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

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

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

2）設(shè)備A的APP X要向設(shè)備B上的APP X發(fā)送消息，設(shè)備A的APP X首先把設(shè)備B的設(shè)備ID信息、以及標(biāo)識(shí)APP X的信息傳遞給軟總線(xiàn)，請(qǐng)求一個(gè)傳輸通道。

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

4）設(shè)備A的APP X拿到通道標(biāo)識(shí)后再調(diào)用SendMessage/SendByte接口和設(shè)備B的APP X進(jìn)行通信。設(shè)備B的APP X也可以使用相同的方法和設(shè)備A進(jìn)行通信。

5）傳輸結(jié)束后，設(shè)備A的APP X可以調(diào)用關(guān)閉傳輸接口完成傳輸通道資源的釋放。

2.2 Message/Byte傳輸注意事項(xiàng)

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

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

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

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

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

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

本文作者：zhangkesi，華為軟件架構(gòu)設(shè)計(jì)工程師

編輯：jq