登录社区云，与社区用户共同成长
邀请您加入社区
在 OpenHarmony 的应用开发和系统适配过程中，回调函数是一种非常常见的编程方式。它可以将“事件发生之后要执行什么操作”交给调用方定义，从而降低模块之间的耦合度。 通过对 OpenHarmony 地图模块中 POI 搜索、网络适配和渲染流程的分析，我对回调函数的理解更加具体。回调函数并不只是“把一个函数传给另一个函数”，它实际上包含了接口设计、函数实现、回调注册、事件触发和结果处理等完整流
数据传输改造小记：从等推送，到自己出门打饭 做嵌入式久了，多少都有点"队列情结"。数据嘛，天经地义应该从串口那头流过来，进队列，后面慢慢消费。我一开始也是这么想的，直到这套东西在 MH1000 上开始作妖。 以前的队列是怎么干活的 老路子很标准：MCU 主动推 CMC 帧，串口收进来塞进队列，数据中心的解析任务用 xQueueReceive 一条条掏出来解，解完往 field_
概述 在某些系统版本中，设备系统时间设置为 12 小时制，下午 13:00 发起一条通知，通知栏中显示的时间却是 01:00。这是一个时间格式转换的 bug——系统按 24 小时制处理了时间，但没有根据用户的 12 小时制设置做格式化，导致下午 13点被错误地显示为 01 点。 说明 这个问题的根源在于时间格式化时没有读取系统的时间制式配置。HarmonyOS 中获取系统时间格式的接口是
WSL2 Ubuntu 22.04 开发环境配置指南 在上一期文章中，我们已经完成了 WSL（Windows Subsystem for Linux）的安装以及 Ubuntu 22.04 操作系统的安装。本期将继续深入，对刚安装好的 Ubuntu 环境进行一系列基础配置，包括新建用户、设置默认登录用户、修改主机名、查看安装位置、切换镜像源、资源配置以及 pyenv 安装等，帮助你将 WSL 环境
修改了一段 C++ 代码，编译没有报错，设备上的行为却没有变化。遇到这种情况，很容易先怀疑缓存，再重新编译整个系统。但如果改动没有进入当前产品的构建链路，重复编译只会再次得到相同结果。 阅读 Laval 社区的编译构建、clangd 配置和产物命名文章后，我把这个问题整理成五个连续的检查点：改的是哪份源码，文件属于哪个目标，实际使用什么编译参数，更新了哪个产物，运行时是否执行到新代码。 本文面向使
在适配轻量地图渲染时，我遇到过一类很有迷惑性的现象：路名文字有时接近黑色，有时偏红，重新进入页面后颜色还可能变化。第一反应通常是字体绘制或屏幕像素格式有问题，但沿渲染链继续检查后，真正的异常出现在更早的颜色数据边界。 这次排查最重要的收获，是要把“缓冲区像素格式”和“画笔颜色格式”分开理解。 两种格式描述的不是同一件事 RGB565 描述的是像素缓冲区布局。一个像素占 16 位，红色 5 位、绿色
在完善轻量地图组件的异步网络能力时，我遇到的核心问题并不是“怎样发出一个异步请求”，而是请求完成以后，怎样安全地把结果交还给地图引擎。 网络回调可能运行在协议栈线程，地图状态却通常要求在固定任务线程中串行修改。如果直接从网络线程进入地图引擎，短期内可能看不出问题，但在并发请求、页面退出或重复回调时，很容易出现数据竞争和生命周期错误。 地图线程在框架中的作用 轻量地图内部会同时维护视图状态、瓦片缓存
在参与 OpenHarmony 轻量地图组件共建时，我尝试为地图模块补充离线资源管理能力。最初看起来，这项工作只是增加查询、下载、暂停和删除接口，但真正开始梳理后，我发现难点并不在函数数量，而在于如何让新能力自然地进入原有框架，同时不破坏已有实现。 这次修改让我对轻量地图组件的分层、代理线程和公共接口兼容有了更具体的认识。 从现有调用链开始轻量地图组件并不是应用直接调用某个地图 SDK，而是通过一
OpenHarmony L0 与 L1 的 BMS / AMS 区别详解 本文基于对两套真实源码树的逐文件阅读整理而成： 系统级别源码路径（WSL）目标板内核产品类型L0（轻量系统 / mini）/home/gaoxining/openharmonyArtInChip D21XLiteOS-M"type": "mini"L1（小型系统 / small）/ho
差分升级全流程说明：通路验证 → OTA 收包 → 写分区/解包 差分升级 = 设备端把「当前运行的 old 镜像 + 收到的差分包」合并出 new 镜像写入备份槽。整条链路分三个阶段，下面按数据流顺序描述。 一、验证通路：蓝牙 / 天眼 / 总线 三条通道互不干扰，各自"硬件收字节 → 进队列 → 帧解析 → 进协议栈"。 1.1 蓝牙（USART1，PA9/PA10，DMA
