给轻量地图算一笔内存账：三层统计、退图归零与一次所有权误判 在资源受限设备上，地图往往是整机内存占用最大的单个业务模块。但“地图占多少内存”这个问题，如果只回答一个总数，既没法指导优化，也没法证明没有泄漏。 我在地图组件上做了一轮分层内存统计，并借这套账本抓到一个真实存在的泄漏。更有意思的是，泄漏最初被错误地归因给了地图 SDK，真正的问题出在适配层的所有权约定上。 为什么要把内存按层分账 地图链

“进入地图页时画面闪一下”——这类问题最容易被归到渲染优化或动画参数上。我第一次看到日志时也这么想，但把时间线摊开之后，问题其实出在调度时机：一次延迟重绘恰好落进了入场动画的窗口，而它来自一个不具备 UI 线程亲和性的定时器线程。 这次排查的完整链路值得记录，因为它同时涉及生命周期、线程模型和一个需要反汇编才能确认的 SDK 行为。 先描述清楚现象 半屏地图在最小缩放级别、拖动到数据边缘后退出，再

一个编译开关引发的静默卡死：C++ 全局构造与 4KB 主线程栈 在 RTOS 上做 C++ 开发，很容易产生一种错觉：既然代码一直是 C++ 写的，把运行时的 C++ 支持宏打开应该只会“更完整”。 我做过一次验证性实验：在配置文件里加了一行，打开 RT-Thread 的 C++ 支持。编译通过，链接通过，烧录后开机日志停在设备驱动初始化之后，没有任何错误打印，系统静默停摆。回退这一行，一切恢复

在适配轻量地图渲染时，我遇到过一类很有迷惑性的现象：路名文字有时接近黑色，有时偏红，重新进入页面后颜色还可能变化。第一反应通常是字体绘制或屏幕像素格式有问题，但沿渲染链继续检查后，真正的异常出现在更早的颜色数据边界。 这次排查最重要的收获，是要把“缓冲区像素格式”和“画笔颜色格式”分开理解。 两种格式描述的不是同一件事 RGB565 描述的是像素缓冲区布局。一个像素占 16 位，红色 5 位、绿色

在完善轻量地图组件的异步网络能力时，我遇到的核心问题并不是“怎样发出一个异步请求”，而是请求完成以后，怎样安全地把结果交还给地图引擎。 网络回调可能运行在协议栈线程，地图状态却通常要求在固定任务线程中串行修改。如果直接从网络线程进入地图引擎，短期内可能看不出问题，但在并发请求、页面退出或重复回调时，很容易出现数据竞争和生命周期错误。 地图线程在框架中的作用 轻量地图内部会同时维护视图状态、瓦片缓存

在参与 OpenHarmony 轻量地图组件共建时，我尝试为地图模块补充离线资源管理能力。最初看起来，这项工作只是增加查询、下载、暂停和删除接口，但真正开始梳理后，我发现难点并不在函数数量，而在于如何让新能力自然地进入原有框架，同时不破坏已有实现。 这次修改让我对轻量地图组件的分层、代理线程和公共接口兼容有了更具体的认识。 从现有调用链开始轻量地图组件并不是应用直接调用某个地图 SDK，而是通过一