【OpenHarmony/HarmonyOs 】CheckMe 全场景体验设计：近场快传、实况窗与智慧设备状态流转

【OpenHarmony/HarmonyOs 】CheckMe 全场景体验设计近场快传、实况窗与智慧设备状态流转本文基于CheckMe项目展开重点不是重复服务卡片教程而是讨论一个 HarmonyOS 工具类应用如何围绕“近场、实时、全场景”组织能力。项目中已经实现了蓝牙状态、定位状态、桌面卡片、实时仪表盘等能力近场快传、实况窗等系统级新特性则作为可扩展方向进行设计拆解。HarmonyOS 的应用体验和传统移动应用有一个很大的区别它不应该只存在于“打开 App 的那一刻”。在全场景设备生态里一个应用的状态可以出现在桌面卡片、通知、实况窗、附近设备、平板/手机/二合一设备等多个触点上。CheckMe是一个设备状态监控工具非常适合围绕这个方向展开设备状态适合被桌面前置位置、网络、蓝牙适合表达场景状态硬件检测结果适合被分享或流转实时任务适合用实况窗承载进度这篇文章会从项目现有实现出发设计一套“全场景设备状态流转”的文章思路。一、全场景不是堆 API而是整理用户路径如果只是列几个关键词近场快传实况窗全场景智慧生活桌面卡片文章会很空。真正落到项目里应该先想清楚用户路径。以CheckMe为例用户可能会这样使用在首页查看 CPU、内存、电量、网络状态。在硬件检测页做一次扬声器、麦克风、传感器、GPS、蓝牙测试。把检测结果分享给身边的人或另一台设备。检测过程中不想一直停留在页面希望从系统入口看到进度。平时不打开 App也希望桌面能看到关键状态。对应到 HarmonyOS 的能力设计就是桌面卡片承载长期状态实况窗承载短时进行中的任务近场能力承载设备间协作和结果流转响应式布局承载手机、平板、二合一多形态这比单独讲某个 API 更有项目实战价值。二、项目已有的全场景基础桌面卡片入口CheckMe已经实现了多种桌面卡片包括 CPU、内存、存储、电池、网络等。主 Ability 中维护了一个前台推送定时器constWIDGET_PUSH_INTERVAL_MS:number5000;privatestartWidgetPushTimer():void{constappCtx this.context.getApplicationContext();WidgetDataService.getInstance().startUpdating(WIDGET_PUSH_INTERVAL_MS, ():Promisevoid {returnWidgetFormIdRegistry.pushAllFromPreferences(appCtx); } ); }这段代码体现了卡片体验的本质用户不一定打开 App但状态仍然可以被看到。onForeground()中根据是否存在卡片决定是否启动刷新onForeground():void{ AppLifecycleManager.getInstance().setForegroundState(true);voidWidgetFormIdRegistry .getFormCount(this.context.getApplicationContext()) .then((n: number):void {if(n 0) {this.startWidgetPushTimer();voidWidgetDataService.getInstance().updateAllWidgetData().then(():void {voidWidgetFormIdRegistry.pushAllFromPreferences(this.context.getApplicationContext() ); }); }else{ WidgetDataService.getInstance().stopUpdating(); } }); }这里已经具备“全场景入口”的雏形App 内是完整信息桌面上是轻量状态前后台根据需要启停刷新如果后续扩展实况窗就可以继续沿用这套数据服务而不是重新写一套状态模型。三、实况窗适合承载什么实况窗的价值不是把所有信息都塞进去而是承载“正在发生”的事情。对CheckMe来说比较适合放进实况窗的场景有正在进行硬件检测正在执行性能基准测试正在定位并更新 GPS 精度正在监控网络质量正在进行存储读写测试比如硬件检测页有多个测试状态enumTestStatus {IDLEidle, TESTING testing, PASSED passed, FAILED failed, UNAVAILABLE unavailable}这类状态天然适合映射到实况窗项目状态实况窗展示TESTING检测中、进度、当前模块PASSED检测通过、绿色状态FAILED检测失败、失败原因UNAVAILABLE设备不支持、引导说明这样用户即使切到桌面也能继续看到“硬件检测正在进行到哪一步”。 注意本文不是说项目已经完整接入实况窗而是给出基于现有状态模型的扩展方案。实际接入时需要按照官方 Live View / Push Kit 等能力完成配置、申请和消息更新。四、从硬件检测到实况窗状态模型可以复用硬件检测中项目会根据不同模块更新结果privateasync startBluetoothTest(): Promisevoid {this.bluetoothTesting true;this.bluetoothStatus TestStatus.TESTING;this.updateResult(蓝牙, TestStatus.TESTING,检测中...);try{constcurrentState: bluetooth.BluetoothState bluetooth.getState();this.bluetoothEnabled (currentState bluetooth.BluetoothState.STATE_ON);if(this.bluetoothEnabled) {this.bluetoothStatus TestStatus.PASSED;this.updateResult(蓝牙, TestStatus.PASSED,蓝牙已开启); }else{this.bluetoothStatus TestStatus.FAILED;this.updateResult(蓝牙, TestStatus.FAILED,蓝牙未开启); } }catch(e) {this.bluetoothStatus TestStatus.FAILED;this.updateResult(蓝牙, TestStatus.FAILED,蓝牙不可用); }this.bluetoothTesting false; }这段代码不仅能驱动页面 UI也可以成为实况窗的数据源interfaceLiveCheckState{title:string;moduleName:string;status:TestStatus;message:string;progress:number;updatedAt:number;}未来可以让updateResult()同时触发页面状态刷新本地持久化桌面卡片轻量提示实况窗状态更新这样就形成了一个统一状态流而不是每个场景各写一套。五、近场快传项目可以分享什么CheckMe当前已经具备设备信息、硬件检测、位置、媒体能力等数据基础。近场快传并不一定只传文件也可以传结构化的诊断结果。适合分享的内容包括设备概览报告硬件检测结果网络质量摘要位置信息文本媒体能力列表设备卡片截图或报告 PDF例如硬件检测结果可以整理为interface DeviceCheckReport { deviceName: string; systemVersion: string; generatedAt: number;summary:normal|warning|error; items: Array{ name: string; status: TestStatus; detail: string; }; }然后在近场场景中实现用户点击“分享检测报告”项目生成 JSON、文本或 PDF调用系统分享或近场传输能力接收端打开后可以查看报告这类功能非常适合写成 CSDN 项目扩展文章因为它不只是“传一个文件”而是把项目数据整理成可流转的诊断资产。六、蓝牙状态近场能力的场景入口项目中已经有蓝牙服务BluetoothService它会描述设备类型、连接状态、信号强度等信息publicgetSignalLevel(rssi: number): number {if(rssi -60) {return4; }elseif(rssi -70) {return3; }elseif(rssi -80) {return2; }elseif(rssi -90) {return1; }return0; }在文章写法上可以把这段作为“近场感知”的基础。近场体验不是一上来就传输而是先知道附近有没有设备设备是什么类型信号是否足够稳定当前连接状态是否可用项目中虽然目前使用了演示设备列表但结构上已经具备“设备类型 连接状态 RSSI 信号等级”的表达方式后续替换为真实发现能力时页面层不需要大改。七、位置能力全场景生活服务的另一个入口CheckMe的位置页已经使用 Location Kit 获取真实定位并做了失败原因和提示const locRequest: geoLocationManager.CurrentLocationRequest {priority: geoLocationManager.LocationRequestPriority.ACCURACY, scenario: geoLocationManager.LocationRequestScenario.NAVIGATION, maxAccuracy: 100 };const raw: geoLocationManager.Location await geoLocationManager.getCurrentLocation(locRequest);这类能力可以扩展到全场景智慧生活设备丢失时快速确认最后位置户外场景下记录设备状态和坐标网络异常时结合位置判断环境检测报告中附带位置精度而不是完整隐私地址这里尤其要注意隐私边界全场景并不意味着把所有数据都广播出去。位置能力应该默认本地展示只有用户主动分享时才导出。八、响应式布局全场景不只是在手机上跑项目中抽出了ResponsiveHelper用于识别手机、平板、横竖屏和布局档位privatecalculateLayout(): ResponsiveLayout {constminDim Math.min(this.screenWidthVp,this.screenHeightVp);if(minDim 360) {returnResponsiveLayout.COMPACT; }if(minDim 600) {returnResponsiveLayout.STANDARD; }if(minDim 840) {returnResponsiveLayout.EXPANDED; }returnResponsiveLayout.LARGE; }这也是全场景智慧生活里经常被忽视的一点设备协同不只是通信能力还包括不同屏幕形态下的展示能力。同一个设备报告手机上适合纵向卡片平板上适合多列仪表盘二合一设备上适合大屏趋势图桌面卡片上适合只展示摘要因此项目从一开始就不应该把页面写死在某个尺寸上。九、推荐的扩展架构基于当前项目我会这样扩展“近场 实况窗 全场景”能力DeviceInfoService / HardwareTest |vUnifiedStatusCenter |-- App页面状态 -- Widget 桌面卡片 -- Live View 实况窗 -- Share / Nearby 近场分享 -- Report 导出核心思想是先建立统一状态中心interfaceUnifiedDeviceStatus{cpuUsage:number;memoryUsage:number;batteryLevel:number;networkType:string;checkStatus:TestStatus;checkMessage:string;updatedAt:number;}这样所有外部入口都从同一份状态派生卡片只拿摘要实况窗拿进行中任务近场分享拿报告App 页面拿完整数据架构清晰后文章的技术含量会比“调用某 API”高很多。十、文章小结CheckMe当前已经实现了不少全场景基础能力桌面卡片负责长期状态前置实时仪表盘负责 App 内完整展示蓝牙和位置能力负责场景感知硬件检测结果适合沉淀为可分享报告响应式布局支持手机、平板、二合一等设备形态如果继续扩展实况窗可以承载“正在检测”的过程近场能力可以承载“检测结果的设备间流转”最终形成一个更完整的 HarmonyOS 全场景工具应用。这类文章的重点不是夸新特性而是证明新特性落到项目里应该服务于真实用户路径。参考资料华为开发者文档Push Kit Introduction包含 Live View 相关说明华为开发者文档Location Kit华为开发者文档Form Kit