華為架構(gòu)師解讀：HarmonyOS低時(shí)延高可靠消息傳輸原理
51CTO和華為官方合作共建的鴻蒙技術(shù)社區(qū)
這是一篇HarmonyOS低時(shí)延高可靠消息傳輸原理的介紹，希望對(duì)你有所幫助。
01 一個(gè)近場通信的例子
1.1 全場景智慧生活的典型問題
在全場景智慧生活當(dāng)中，設(shè)備種類和數(shù)量越來越多，各種富設(shè)備(如智慧屏、PC、PAD、音箱)以及各種瘦設(shè)備(如IOT的智能門鎖、攝像頭、智能燈、智能窗簾)的近場通信方式各不相同，有wifi、藍(lán)牙、NFC、usb、zigbee等。
在這么多種近場通信方式選擇上，如何讓這些設(shè)備便捷、高效地通信，從而實(shí)現(xiàn)上層應(yīng)用無需考慮設(shè)備差異，就如同使用“一個(gè)設(shè)備”一樣，流暢地使用多個(gè)設(shè)備的能力，是全場景智慧生活中面臨的一個(gè)典型問題。HarmonyOS分布式軟總線為這個(gè)問題提供了可靠的解決方案，并通過簡單的API接口向開發(fā)者開放出來。
1.2 如何保障控制消息(Message)低時(shí)延高可靠
下圖是一個(gè)家庭場景中典型的富瘦設(shè)備的組網(wǎng)圖，主要包含兩類業(yè)務(wù)，黑色線條的上網(wǎng)業(yè)務(wù)，紅色線條的近場業(yè)務(wù)。橫向的近場通信業(yè)務(wù)的物理通道，比縱向的上網(wǎng)業(yè)務(wù)的物理通道種類更多，帶寬也不同，HarmonyOS分布式軟總線完全屏蔽了底層通信的差異，讓上層應(yīng)用通過使用幾個(gè)簡單的軟總線接口，就像使用本地接口一樣，輕松實(shí)現(xiàn)多設(shè)備間高速通信。
圖1
舉個(gè)例子，將手機(jī)上的游戲App的操作界面投屏到PAD上，如何實(shí)現(xiàn)在PAD上進(jìn)行手機(jī)上游戲APP的控制如在手機(jī)上控制一樣的流暢?其中，使用軟總線的SendMessage接口完成PAD到手機(jī)的反控操作(華為Cast+技術(shù))Message的無延遲傳輸，起到了一個(gè)關(guān)鍵的作用。具體實(shí)現(xiàn)如下：
前提條件：
1、 手機(jī)、PAD均搭載了HarmonyOS，具備分布式軟總線能力
2、 手機(jī)已經(jīng)把游戲APP的操作界面投屏到PAD上
過程描述：
1、 手機(jī)首先使用軟總線的發(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ī)之間需要通過軟總線建立控制通道。軟總線要選擇最優(yōu)傳輸通道，并保障該通道上的數(shù)據(jù)得到高優(yōu)先級(jí)的傳輸。
3、 PAD調(diào)用SendMessage接口把控制消息Message反饋給手機(jī)。
4、 手機(jī)收到PAD的反控消息并執(zhí)行，并把執(zhí)行后的結(jié)果再反饋到PAD上。整個(gè)過程的時(shí)延要求在百毫秒級(jí)。
上面描述的過程看似簡單，實(shí)際上底層通信使用到了HarmonyOS分布式軟總線的發(fā)現(xiàn)、連接和傳輸?shù)哪芰Α１敬尾恢v發(fā)現(xiàn)和連接的技術(shù)點(diǎn)，僅對(duì)傳輸?shù)膶?shí)現(xiàn)原理進(jìn)行解釋。
02 近場Message/Byte傳輸實(shí)現(xiàn)原理
2.1 實(shí)現(xiàn)過程描述
HarmonyOS分布式軟總線提供了兩個(gè)接口，分別用于近場通信場景下長短消息的傳輸，分別是SendMessage和SendByte，實(shí)現(xiàn)原理相同，如下圖所示：
圖2
圖中APP X統(tǒng)一代表不同的上層應(yīng)用App。具體過程描述：
1)設(shè)備A和設(shè)備B的APP X會(huì)在初始化階段向軟總線注冊(cè)回調(diào)通知接口，用于在傳輸通道打開、數(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的信息傳遞給軟總線，請(qǐng)求一個(gè)傳輸通道。
3)軟總線要根據(jù)當(dāng)前兩個(gè)設(shè)備已有的物理通道種類(BR/BLE/WIFI2.4/Wifi 5G/P2P)，以及物理通道的負(fù)載和設(shè)備的狀態(tài)，決策選擇一個(gè)最優(yōu)的傳輸通道的底層連接，同時(shí)完成傳輸層的連接建立，和傳輸標(biāo)識(shí)的內(nèi)核態(tài)到用戶態(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類型主要用于低時(shí)延、高可靠業(yè)務(wù)，比如游戲的控制命令、IoT設(shè)備的開關(guān)(燈的開關(guān)、門窗的開關(guān))等等，數(shù)據(jù)量最大不超過4KB。
2)SendMessage對(duì)Message類型消息的傳輸，HarmonyOS軟總線在底層實(shí)現(xiàn)按照最高優(yōu)先級(jí)進(jìn)行傳輸，例如空口使用最高優(yōu)先級(jí)VO隊(duì)列。因此在實(shí)際使用中，為了獲得更低的時(shí)延，最好是一幀數(shù)據(jù)就能把Message消息發(fā)送完成。比如1.5KB大小，保證空口一幀就發(fā)送完成，減少空口的資源競爭和退避帶來的時(shí)延開銷。
3)Byte類型主要用于傳輸比Message類型消息大，時(shí)延要求沒那么高的業(yè)務(wù)。比如傳輸一個(gè)圖片的縮略圖。通常最大不超過4M大小。具體大小取決于設(shè)備的內(nèi)存大小，有些設(shè)備內(nèi)存小，則其Byte類型消息不會(huì)超過4M。
4)SendByte除了用于時(shí)延要求不高的基本業(yè)務(wù)數(shù)據(jù)傳輸外，也可以用于探測網(wǎng)絡(luò)端與端之間的時(shí)延，比如探測當(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)致傳輸性能下降。
本次為大家簡單介紹HarmonyOS Message/Byte類型消息的底層傳輸原理，這兩個(gè)都是數(shù)據(jù)量比較小(Byte/M)且非持續(xù)性的消息傳輸，對(duì)于規(guī)格比較大(G)且有持續(xù)性傳輸要求的File和Stream類型數(shù)據(jù)傳輸，會(huì)在后續(xù)技術(shù)解析文章中進(jìn)行講解，敬請(qǐng)期待!
51CTO和華為官方合作共建的鴻蒙技術(shù)社區(qū)
