登录社区云，与社区用户共同成长
邀请您加入社区
概述 把一段重复的界面抽成 @Builder自定义构建函数，是 ArkUI 里最常用的复用手段之一。但很多人抽完之后会撞上一个奇怪的现象：某个 @Builder里展示的文字，在别处把对应的数据改了之后，这里就是不刷新——日志里数据变了，界面纹丝不动。 这通常不是 @Builder写错了，而是传参方式用错了。@Builder的参数传递分两种：默认的"按值传递"和需要用 `$$`
概述 做 ArkUI 开发的人几乎都踩过同一个坑：组件上 `@State` 装饰了一个对象数组，列表也能正常显示，可在某个 `onClick` 回调里把数组里某个元素的属性改了——`this.list[0].votes += 1`，日志里值明明变了，页面却纹丝不动。 这是状态管理 V1 的观测边界在起作用：`@State` 默认只能看到"第一层"的数据变化，数组元素内部的属性属
一、为什么要区分 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，这是社区
