鸿蒙仓颉编程语言挑战赛二等奖作品 :以仓颉之码,筑智慧学园——基于仓颉与OpenHarmony的智慧校园协同管控系统实践

珍惜宝贵睡眠：

黄紫妍、韩宗傲、宋瞿律

在数字化浪潮席卷教育行业的今天，智慧校园建设已成为高校提升管理效率、优化师生体验的核心方向。然而，传统校园管理中普遍存在环境监测滞后、设备控制不便、教室状态难感知等痛点，且多数系统依赖国外技术栈，存在安全隐患与适配难题。为此，我们团队以国产化技术为核心，打造了基于仓颉语言与 OpenHarmony 的智慧校园协同管控系统，用自主可控的技术方案破解校园管理痛点，为高校提供高效、安全、智能的管理新范式。

• 环境感知被动：传统教室温湿度、CO₂浓度等数据依赖人工巡检，无法实时预警超标情况，影响师生舒适度；

• 设备控制低效：教室空调、灯光等设备需现场操作，存在 “人走灯不灭” 的资源浪费，且无法远程统一管控；

• 状态管理模糊：教室使用状态缺乏实时可视化手段，师生找空闲教室需逐个排查，管理员难以合理调度资源；

• 技术依赖风险：现有系统多采用国外框架与语言，数据安全与自主可控性不足，适配校园场景的灵活性欠缺。

系统采用 “三层架构 + 全栈国产化技术”，实现从硬件感知到用户交互的全链路高效协同：

cangjieimport mqtt4cj;import tea;// MQTT客户端初始化，连接传感器与执行器func initMqttClient() -> MqttClient {    let config = MqttConfig{        broker: "tcp://192.168.1.100:1883",        clientId: "cangjie-smart-campus",        username: "campus-admin",        password: "xxx123456"    };    let client = MqttClient.create(config);    client.connect();    // 订阅传感器数据主题    client.subscribe("sensor/environment", Qos.AT_LEAST_ONCE, onEnvironmentDataReceived);    // 订阅教室图像主题    client.subscribe("camera/classroom", Qos.AT_LEAST_ONCE, onClassroomImageReceived);    return client;}// 接收环境传感器数据回调函数func onEnvironmentDataReceived(topic: str, payload: ByteBuf) {    let data = Json.parse(payload.toString()) as EnvironmentData;    // 数据清洗：过滤异常值    if data.temperature > -20 && data.temperature < 60 && data.co2 < 5000 {        // 存入MySQL数据库        db.insert("environment_data", data);        // 推送至前端WebSocket        webSocketServer.broadcast(Json.stringify(data));    }}

• 全栈国产化技术融合：首次实现仓颉语言与 OpenHarmony 的深度协同，后端业务 100% 基于仓颉开发，前端依托 OpenHarmony+arkTS 实现跨设备适配，打破国外技术依赖；

• 端到端低延迟管控：通过 “ArkTS 前端→仓颉后端→MQTT 通信→硬件控制器” 的极简链路设计，设备控制延迟低于 1 秒，远优于行业平均水平；

• 智能状态感知闭环：结合图像压缩编码、AI 人脸检测与仓颉后端调度，实现教室状态 “抓拍 - 识别 - 标记 - 同步” 全自动化；

• 安全与体验双重保障：HTTPS + JWT 认证贯穿全链路，用户数据加密存储，同时支持主题切换、操作记录留存等个性化功能，兼顾安全性与易用性。

• 跨层通信一致性难题：不同硬件（传感器、摄像头、执行器）通信协议差异大，通过仓颉语言封装统一的 MQTT 通信抽象层，屏蔽协议差异，实现 “一次开发、多设备适配”；

• AI 识别与后端协同效率：人脸检测微服务与仓颉后端的跨语言调度存在性能瓶颈，优化方案为 “图像压缩 + 异步调用”—— 摄像头端压缩图像后上传，仓颉后端采用异步线程调用 Python 微服务，避免阻塞主线程；

• 高并发数据处理：面对多教室、多传感器的高频数据上报，通过仓颉 tea 框架的协程模型与连接池设计，支撑 100 + 设备同时连接。

项目初期曾考虑使用热门的 Java+Vue 技术栈，但结合 “国产化、低延迟、物联网适配” 需求，最终选择仓颉 + OpenHarmony。实践证明，贴合场景的技术选型能减少后期适配成本 —— 仓颉的内存安全特性降低了后端崩溃风险，OpenHarmony 的跨设备能力让 App 与大屏无需重复开发，这比盲目追求热门技术更高效。

硬件、后端、前端分属不同技术领域，初期曾因数据格式、通信时序不一致导致频繁对接问题。后来我们制定了统一的接口契约（如传感器数据 JSON 格式、MQTT 主题命名规则、API 请求 / 响应规范），并编写接口文档，要求各模块严格遵循，后续协同效率提升 60%，减少了无效沟通。