-
个人首页： VON
-
鸿蒙系列专栏： 鸿蒙开发小型案例总结
-
综合案例 ：鸿蒙综合案例开发
-
鸿蒙6.0：从0开始的开源鸿蒙6.0.0
-
鸿蒙5.0：鸿蒙5.0零基础入门到项目实战
-
Electron适配开源鸿蒙专栏：Electron for OpenHarmony
-
Flutter 适配开源鸿蒙专栏：Flutter for OpenHarmony
从单端到"空地一体"
- [基于 HarmonyOS 的多端协同感知系统开发实践](#基于 HarmonyOS 的多端协同感知系统开发实践)
-
- 引子：当"单车感知"遇上"空地融合"
- [突破一：重构 UI 架构 ------ 从"适配多端"到"自适应多端"](#突破一：重构 UI 架构 —— 从“适配多端”到“自适应多端”)
- [突破二：拥抱分布式 ------ 让无人机成为"可编程的空中传感器"](#突破二：拥抱分布式 —— 让无人机成为“可编程的空中传感器”)
- 架构演进：从"功能实现"到"体验闭环"
- 结语：技术成长的本质是认知边界的拓展
基于 HarmonyOS 的多端协同感知系统开发实践
作者 ：VON
技术栈 ：Vue 3 + TypeScript + Vite + DevUI
参考文档
- MateChat：https://gitcode.com/DevCloudFE/MateChat
- MateChat官网：https://matechat.gitcode.com
- DevUI官网：https://devui.design/home
引子：当"单车感知"遇上"空地融合"
2024 年底，我接手了一个极具挑战性的项目：构建一套面向道路安全的 车-空协同智能感知系统。目标很明确------通过"无人机 + 车载终端 + 云端地图"的联动，实现对路面风险（如坑洼、障碍物、事故）的秒级发现与预警。
起初，我本能地想到用传统方案：手机 App 接收云端推送，车载屏显示静态地图。但很快意识到，这仍是"单车感知"的延伸，无法发挥 空域视角 与 多设备协同 的真正价值。
直到团队决定全面采用 HarmonyOS NEXT 作为开发底座，我才真正看到了突破口：鸿蒙原生的分布式能力，或许正是打通"空-地"感知链的关键。
突破一：重构 UI 架构 ------ 从"适配多端"到"自适应多端"
过去做跨端开发，我的策略是"一套逻辑，多套界面"------为手机写一套 Vue 页面，为车机另写一套 React Native 组件。这种方式维护成本高，且难以保证体验一致性。
而在 HarmonyOS 中，声明式 UI（ArkTS） + 自适应布局引擎 提供了更优雅的解法。
场景驱动的响应式设计
我们的系统需运行于三类典型设备：
- 车载终端（1080P 横屏，强光环境，操作以语音/物理按键为主）
- 地面站平板（中等尺寸触控屏，用于操控无人机与查看实时识别结果）
- 运维人员手机 （小屏、移动网络波动大，侧重轻量交互）
我摒弃了"按设备类型写分支"的做法，转而采用 基于屏幕特征的动态渲染策略：
ts
// 获取当前设备显示信息
import display from '@ohos.display';
@Entry
@Component
struct RoadRiskDashboard {
build() {
Column({ space: 12 }) {
// 动态标题栏
this.renderHeader()
// 核心内容区：根据宽度决定布局模式
if (display.defaultWidth >= 800) {
// 大屏：左右分栏（地图 + 风险列表）
Row() {
MapView().width('60%')
RiskEventList().width('40%')
}
} else {
// 小屏：上下堆叠，优先保障地图可视性
MapView().height(320)
RiskEventList()
}
// 底部操作栏：仅在触控设备显示
if (this.isTouchDevice()) {
ActionBar()
}
}
.padding(16)
}
renderHeader() {
Text('道路风险预警中心')
.fontSize(display.defaultWidth > 600 ? 24 : 18)
.fontWeight(FontWeight.Bold)
}
isTouchDevice(): boolean {
// 可通过 inputManager 或设备类型判断
return true; // 简化示例
}
}这种模式下，UI 不再绑定具体设备，而是响应环境特征。即使未来接入 AR 眼镜或指挥中心大屏，只需扩展判断逻辑，无需重写整个页面。
突破二：拥抱分布式 ------ 让无人机成为"可编程的空中传感器"
如果说 UI 自适应解决了"看"的问题，那么 分布式软总线（DSoftBus） 则解决了"联"与"算"的问题。
在传统架构中，无人机与车载终端通常通过私有协议通信，开发复杂、延迟高、安全性弱。而 HarmonyOS 的分布式能力，让两者如同"同一台设备的不同模块"。
设备发现与可信组网
我们利用 @ohos.distributedHardware.deviceManager 实现自动发现：
ts
import deviceManager from '@ohos.distributedHardware.deviceManager';
deviceManager.on('deviceFound', (deviceInfo) => {
if (deviceInfo.deviceName.includes('Drone') && deviceInfo.networkId) {
// 自动发起可信认证
deviceManager.authenticateDevice(deviceInfo, (err, token) => {
if (!err) {
console.log('无人机已加入本地设备群');
this.droneNetworkId = deviceInfo.networkId;
}
});
}
});一旦组网成功，无人机便成为车载系统的"远程感知单元"。
跨设备服务调用与数据流转
我们定义了一个 RoadRiskService，部署在无人机端，负责：
- 实时分析摄像头画面（使用 MindSpore Lite 运行轻量模型）
- 识别坑洼、落石、积水等风险
- 生成结构化事件（含 GPS、时间戳、置信度）
车载端通过 分布式 RPC 直接调用该服务：
ts
// 车载端发起巡检任务
async startAerialInspection(targetLocation: GeoPoint) {
const remoteService = await rpc.connectRemoteObject(
this.droneNetworkId,
'com.example.road.RoadRiskService'
);
const result = await remoteService.invoke('scanArea', {
center: targetLocation,
radius: 50 // 米
});
// 结果自动同步至本地数据库
this.updateLocalRiskEvents(result.events);
}得益于 DSoftBus 的 P2P 通信优化 和 QoS 保障机制 ，即使在无蜂窝网络的山区高速，端到端延迟仍控制在 200ms 以内。
分布式数据管理：状态一致性的基石
为避免多端数据冲突，我们采用 分布式数据管理（DDM） 构建统一的风险事件模型：
ts
// 定义分布式数据模型
const riskStore = distributedData.createKVManager({
bundleName: 'com.example.roadguardian',
storeName: 'risk_events'
});
// 任一设备新增事件，自动同步至其他设备
riskStore.put('event_001', JSON.stringify({
id: 'event_001',
type: 'pothole',
location: { lat: 31.23, lng: 121.47 },
timestamp: Date.now(),
source: 'drone_01'
}));这意味着：运维人员在手机上标记"已处理"，车载大屏和指挥中心会实时更新状态，无需手动刷新或轮询。
架构演进：从"功能实现"到"体验闭环"
初期，我们只关注"能不能通"。但随着测试深入，更多工程问题浮现：
- 无人机电量不足时如何优雅降级？
- 车载端网络中断后如何缓存指令？
- 多用户同时操作如何避免冲突？
我们逐步引入：
- 设备能力抽象层：将无人机视为"带摄像头的远程设备"，屏蔽硬件差异
- 离线优先策略：关键指令本地持久化，网络恢复后自动重发
- 操作幂等性设计：确保重复请求不会产生副作用
最终，系统不仅"能用"，更"可靠、可预期、可扩展"。
结语：技术成长的本质是认知边界的拓展
一年前，我对"多端开发"的理解还停留在"写多套 UI"。如今，我学会了用 分布式思维 重新定义应用------设备不再是孤岛，而是可组合、可调度、可协同的资源单元。
HarmonyOS 给我的不仅是工具，更是一种 系统级的协作范式。在这个范式下，"车-空协同"不再是一个炫酷概念，而是一套可落地、可量产、可进化的技术路径。
这条路，我才刚刚启程。但我知道，前方是真正的"万物互联"。
代码终将过时，但协同的思想永存。