01

一個近場通信的例子

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

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

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

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

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

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

前提條件：

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

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

過程描述：

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

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

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

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

上面描述的過程看似簡單，實際上底層通信使用到了HarmonyOS分布式軟總線的發現、連接和傳輸的能力。本次不講發現和連接的技術點，僅對傳輸的實現原理進行解釋。

02

近場Message/Byte傳輸實現原理

2.1 實現過程描述

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

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

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

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

3）軟總線要根據當前兩個設備已有的物理通道種類（BR/BLE/WIFI2.4/Wifi 5G/P2P），以及物理通道的負載和設備的狀態，決策選擇一個最優的傳輸通道的底層連接，同時完成傳輸層的連接建立，和傳輸標識的內核態到用戶態的映射，最后把傳輸通道標識傳遞到兩個設備的上層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類型主要用于低時延、高可靠業務，比如游戲的控制命令、IoT設備的開關（燈的開關、門窗的開關）等等，數據量最大不超過4KB。

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

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

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

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

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

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

編輯：jq