登录社区云，与社区用户共同成长
邀请您加入社区
一、为什么要区分 BLE 直连与 BLE+Wi-Fi Combo 统一互联 3.0 的应用终端可以采用不同的网络形态，但首次配网通常都从近端 BLE 开始。BLE 的职责是让配置对端发现设备、建立安全会话、完成设备认证并下发长期配置；它并不天然等同于设备后续的运行期网络。 本文以 WS63 应用终端为例，整理两种常见形态： 两种形态不能被理解为“两套完全独立的协议”。它们的前半段应尽可能复用同一套
嵌入式MQTT开发中，通信稳定性往往不取决于协议本身，而取决于数据流如何在不同线程间流动。本文从数据流视角，梳理MQTT语音导航模块的设计思路。 一、整体数据流 云端MQTT Broker↓设备MQTT客户端（tcpip线程回调）↓消息队列↓工作线程↓地图引擎接口↓JSON构造↓tcpip_callback↓MQTT发布↓云端 text 整个链路是单向异步的：下行指令从云端到达设备，在工作线程中完
一、项目背景 最近在做一个车载仪表的语音导航功能，核心需求是通过MQTT协议实现云端与设备的双向通信——云端下发搜索指令，设备端搜索POI后上报结果，再通过语音或旋钮选择目的地和路线，最终完成导航启动。 项目基于OpenHarmony L0轻量系统，跑在D21X开发板上。MQTT作为轻量级物联网协议，天然适合这种资源受限、需要实时通信的场景。 二、整体架构 整个模块分为三层： MQTT通信层：负责
一、前言 & 背景 开发 OpenHarmony 应用时，数据存内存里会碰到三个典型痛点： 进程被杀数据就没了：用户配置的 WiFi 名称、设备参数、开关状态，App 一退出全部丢失，每次都要重新配置；跨页面/跨启动无法共享：A 页面保存的配置，B 页面和下次启动都拿不到；查询效率低：设备列表、历史记录这类结构化数据，如果每次启动都重新扫描/重新组装，体验很差。 OpenHarmony 提
一、为什么需要公共事件？ 开发 OpenHarmony 应用时，组件之间经常需要传递"状态变化"消息，典型场景： 跨页面通知：A 页面设备状态变了，B 页面需要同步刷新，但两个页面没有直接的引用关系；跨 Ability/跨应用广播：一个模块采集到的数据，需要分发给多个订阅方（如测试框架收集用例结果）；监听系统事件：蓝牙开关变化、网络连接变化、屏幕亮灭等系统级事件。 如果全部用全
OpenHarmony 后台服务（ServiceExtensionAbility）开发总结 文档概述 说明： 本文结合 OpenHarmony 官方文档《ServiceExtensionAbility（仅对系统应用开放）》与后台服务工程的开发经验整理而成；以下内容包含了个人理解，仅供参考，如有不合理处，请联系笔者修改。 一、前言 & 背景 在很多 OpenHarmony 产品上，应用需要处
文档概述说明：1.文章由移远通信技术股份有限公司提供2.以下内容包含了个人理解，仅供参考，如有不合理处，请联系笔者修改 引言：标准系统启动与孵化问题的排查往往令人望而生畏——链条长、模块多、现象相似但根因各异。本文提供一套经过实战检验的排查方法论，通过「先定链、再定阶段、最后定代码点」的三步法，帮助开发者快速将复杂问题收敛到具体模块和失败点。无论您是面对 SA 起不来、appspawn 超时还是
OpenHarmony 采用 repo 工具统一管理数百个 Git 子仓库，掌握 repo 的拉取与编译流程是参与 OpenHarmony 开发的第一步。本文从环境准备、源码拉取、编译构建到常见问题排查，带你完整走通全流程。 一、环境准备 1.1 宿主机要求 推荐使用 Ubuntu 20.04 LTS 或 Ubuntu 22.04 LTS，这是社区
ARGB8888 → RGB565 像素格式转换详解 在嵌入式 Linux 显示开发中，ARGB8888 到 RGB565 的像素格式转换是一项高频操作。无论是帧缓冲区（framebuffer）输出、DRM/KMS 显示管线，还是 GUI 渲染引擎，都可能涉及这一转换。本文从原理到实现，系统梳理这一转换的方方面面。 一、两种格式的基本结构 ARGB8888（32位/像素） 每个像素占用 4 字节，
1. 为什么“编译成功”仍可能烧出错误镜像 OpenHarmony 设备开发中，经常出现一种看似矛盾的现象：源码已经修改，完整构建也输出 build success，烧录后板端却仍表现为旧问题。 原因通常不在编译器，而在交付链路： 源码 -> GN/Ninja 中间产物 -> kernel / rootfs / FIT -> 产品 OUT -> Windows 烧录目录 -
