很多用 LVGL 做嵌入式界面的朋友最终都会遇到一个看似和 GUI 无关的需求在开机页、加载页或者节日主题里放一段烟火效果。我第一次接到这个需求时第一反应是去 LVGL 的控件列表里找一个“烟花控件”结果当然是没有。接着想用动画 API 实现又发现lv_anim擅长的是单个对象的属性插值面对“一个爆炸点放出几十颗火星每颗都要独立飞行、变色、消失”这种需求默认动画模型并不够用。这篇文章不是要给你一段能直接复制粘贴后就完事的完整代码而是想把 LVGL 放烟火效果从最底层到工程落地拆开讲清楚它真正解决的是什么问题、有哪几条实现路线、内存和刷新机制会怎样影响最终效果以及真机上卡死时应该按什么顺序排查。先给一个核心判断LVGL 放烟火效果表面看是图形动画问题实际上是在有限内存、有限 CPU 和帧率约束下管理大量临时活跃粒子的资源问题。谁能把“粒子状态更新”和“屏幕绘制”分开谁就能在低性能 MCU 上做出流畅效果谁把这个边界搞错了哪怕模拟器上跑得再漂亮换到真实板子也会立刻露馅。1. 先想清楚放烟火效果真正要解决的是哪类问题1.1 效果看起来很炫核心却是一帧内要更新和绘制多少对象LVGL 的动画能力并不弱支持定时器、曲线、属性插值。一个圆环从 0 到 360 度旋转一个进度条从空到满一个标签平滑移动这些事情交给lv_anim都很自然。但烟火效果有一个明显差异它不是单对象属性变化而是多个粒子同时拥有位置、速度、生命周期、颜色、透明度、尺寸并且彼此独立。如果你用“控件动画”的思路硬堆比如每颗火星都创建一个lv_obj那么一颗烟花爆炸出 30 个粒子屏幕上同时有 3 颗烟花就是 90 个控件。LVGL 要维护的就不再是简单的一两次重绘而是一整棵控件树的样式计算、布局、事件分发、命中测试和绘制裁剪。控件数量从个位数涨到几十位每一帧的固定成本会被急剧放大。在低主频 MCU 上这会直接表现为画面卡顿、刷新率跳水甚至触发看门狗超时。1.2 为什么不能用常规控件动画硬堆每个lv_obj都不是一个简单的坐标点它除了位置和尺寸还有父对象、子对象链表、样式、事件、状态位、布局相关字段。哪怕它只是一个小到看不见的圆点也要付出对象的完整开销。更麻烦的是LVGL 刷新机制基于脏矩形区域你用几十个控件散布在屏幕不同位置LVGL 需要把多个 invalidate 区域合并再重绘绘制任务会变得非常零碎。真正适合烟花的做法是把问题拆成两层状态层用普通 C 结构体数组维护粒子包括坐标、速度、生命值、颜色、是否激活。表现层用 LVGL 的绘制能力或预渲染缓冲区把粒子状态刷到屏幕上。状态更新和绘制渲染分离后系统里的“活对象”数量永远可控不会因为粒子数量变多而让 LVGL 控件树爆炸。这个思路不只适合烟花凡是“大量独立小元素同时运动”的 LVGL 特效例如粒子雨、星空漂移、加载动画都可以走同一套骨架。所以它值得沉淀成一个组件而不是一次性脚本。2. LVGL 实现烟花的三种路线以及我为什么优先推荐 draw 路线2.1 路线一用 lv_canvas 画布粒子lv_canvas允许你把数据写入一块 buffer再把这个缓冲区显示到屏幕上。它的优点是像素操作直观你可以按坐标把某个点涂成火星的颜色适合需要精细像素效果的场景。缺点是内存开销很大。一块 320x240 的 RGB565 画布需要的缓冲就有 150KB 左右即使只用半屏也要额外吃掉几十 KB。嵌入式 GUI 项目的 RAM 通常十分紧张画布越多越难接受。而且如果所有粒子都画在同一块画布上每帧要先把上一帧全部清掉再重新画新帧很容易产生闪烁刷新策略要花不少心思去调。2.2 路线二每个粒子用一个 lv_obj 精灵把每颗火星实现成一个小控件比如一个带圆角样式的实心小方块或者一个带透明度的 label然后用lv_anim或手动更新坐标。这个方案代码量最少也最容易理解适合颗粒数很少的简化效果。比如只有两三颗火星在屏幕上掉落用lv_obj完全没问题。但粒子数量一旦上到 20 颗这个方案就会开始吃力。虽然单颗控件的绘制本身不算重但控件管理、样式计算、事件分发这些额外成本会被放大。更要命的是你很难精确控制绘制顺序和刷新合并某些硬件上会出现明显的逐片刷新闪烁。2.3 路线三用 draw callback 或自定义绘制事件直接画LVGL 提供了事件系统你可以在控件绘制阶段插入自定义绘制逻辑例如LV_EVENT_DRAW_MAIN。在回调里遍历粒子数组用 draw rect、draw arc 或 draw line 把火星画出来。这样粒子只是普通 C 数组不需要成为 LVGL 对象内存开销会小很多。这也是我最推荐的路线。它既保留了粒子系统的灵活性又避开了大量控件带来的额外开销。你要承担的成本是要理解 LVGL 的绘制回调机制以及不同版本之间的接口差异。LVGL 8 的绘制上下文和 LVGL 9 的 draw task 不是一回事落地前要先确认你用的是哪个大版本。2.4 三条路线的选型对比路线内存开销粒子数量上限实现难度适合场景lv_canvas 画布高需要额外画布缓冲区中等受画布刷新策略影响中需要精确定位像素、可接受额外内存lv_obj 精灵中每个粒子都有对象开销低10~20 个以内比较稳低极简效果、快速验证draw callback 自定义绘制低只需粒子数据数组高几十上百个可撑住中高正式产品质量、批量粒子、嵌入式真实平台这张表的数值是经验值不是绝对标准。不同屏幕分辨率、不同 MCU 主频、不同色彩格式下结果差异都会很大。选型不如先用一个最小样例验证。3. 从零实现一个可运行的放烟火效果3.1 最小工程粒子结构体与状态机先从一颗粒子开始建结构。不要让它依赖 LVGL 控件保持为普通 C 结构体#define MAX_PARTICLES 128 typedef struct { int16_t x; int16_t y; float vx; float vy; int16_t life; int16_t max_life; lv_color_t color; bool active; } firework_particle_t; static firework_particle_t particles[MAX_PARTICLES];“一帧”的推进我们交给定时器回调所以结构体里用“帧号”来表示生命周期。life从max_life递减到 0active表示这个粒子是否正在飞行。爆炸时从数组里找一个active false的槽位填入初始状态粒子生命结束后再把active改回 false。一个完整的烟火状态机至少包含三个阶段IDLE还没有触发。EXPLODE在某个坐标释放一批粒子。FLY / FADE粒子飞行同时生命周期递减颜色或透明度慢慢变化。3.2 用 lv_timer 驱动粒子更新LVGL 有自己的时间基准和定时器系统推荐使用lv_timer_create注册周期回调不要在应用层再用HAL_Delay或vTaskDelay自己控制时机。lv_timer_t *timer lv_timer_create(firework_timer_cb, 30, NULL);回调里做三件事遍历粒子数组更新位置x vx; y vy; vy gravity;生命周期减一粒子消亡后标记为不活跃。调用lv_obj_invalidate通知 LVGL 重绘对应区域。这里要注意粒子更新周期不一定等于屏幕真正完成刷新的周期。如果你的 timer 更新得太快而底层刷新任务还在处理上一帧那你其实是在制造大量无效的绘制请求如果更新得太慢又会看到明显的跳帧。常见做法是把更新周期设置在 30ms 到 50ms 之间再根据真机表现微调。3.3 绘制把粒子状态变成像素或小色块如果你走 draw callback 路线可以在一个全屏透明对象的绘制事件里遍历粒子数组用lv_draw_rect或lv_draw_arc画小方块或小圆点。下面是一个简化示意接口以你实际使用的 LVGL 版本为准static void firework_draw_cb(lv_event_t *e) { lv_obj_t *obj lv_event_get_target(e); lv_draw_ctx_t *draw_ctx lv_event_get_draw_ctx(e); for (int i 0; i MAX_PARTICLES; i) { if (!particles[i].active) continue; lv_draw_rect_dsc_t rect_dsc; lv_draw_rect_dsc_init(rect_dsc); rect_dsc.bg_color particles[i].color; rect_dsc.radius 0; lv_area_t area; area.x1 particles[i].x - 1; area.y1 particles[i].y - 1; area.x2 particles[i].x 1; area.y2 particles[i].y 1; lv_draw_rect(draw_ctx, rect_dsc, area); } }从性能角度看绘制 2x2 或 3x3 的实心方块永远比画圆点快。圆点在视觉上更接近传统烟花火星但代价是需要额外处理抗锯齿或半透明低端 MCU 上会明显拖慢帧率。第一次跑通时先画方块效果好看了再去优化形状。3.4 关键参数粒子数量、爆炸数据、重力、衰减一组适合多数 320x240 屏幕的起点参数参数建议值说明单个爆炸点粒子数20~40 颗太少没气氛太多会卡同时爆炸点2~3 个再多会超过屏幕信息量粒子初始速度2~5 像素/帧按刷新周期和分辨率调整重力系数0.05~0.15 像素/帧²太大会很快坠地太小会飘生命周期30~70 帧决定火星消失速度这里的“像素/帧”里的帧指lv_timer的更新周期而不是屏幕硬件刷新率。要形成自然的抛物线应该在vy上累加重力而不是直接给一个固定下落速度。爆炸点产生粒子时速度方向最好带随机角度和随机幅度否则每次烟花都一模一样视觉上非常死板。MCU 上常用的rand()通常够用如果你发现随机质量太差可以用一个简单的线性同余生成器或者预置一张随机数查找表。4. 内存优化与平台适配STM32 和 ESP32 上的落地差异4.1 内存管理避免每帧 malloc/freeLVGL 有自带的内存池比如lv_mem_alloc、lv_mem_free每块内存都带管理信息调用很方便。但粒子系统如果每一帧都在创建和释放粒子对象会产生大量碎片和性能抖动长期运行会越来越卡。更好的方式是一开始就预分配一个全局静态粒子数组。数组容量可以是 128 或 256烟花爆发时从空闲槽位分配粒子生命结束就把槽位归还。这里说的“分配”和“归还”只是修改一个active布尔值不需要真的调用内存分配函数。你可以调用lv_mem_monitor查看当前内存剩余和碎片率尤其在做完一轮爆炸后再看一次确认没有内存持续减少。如果发现 free size 一点点被吞掉基本可以判断是某些路径在反复进行小对象分配。4.2 色彩格式RGB565 下怎么让烟花更好看很多廉价 RGB 屏幕默认是 RGB565颜色分量分布是 5 位红、6 位绿、5 位蓝。用lv_color_make(r, g, b)来生成颜色即可但要理解色阶的粗糙度。纯白是lv_color_make(255, 255, 255)而在 RGB565 里实际能表达的分量远少于 8 位。暖色烟花更容易在现有屏上显得鲜艳因为红色和绿色分量占的位更多。蓝色烟花在 RGB565 下相对吃亏容易显得偏暗。真机上第一版可以先选暖色系比如橙红、金黄、亮白。另一个容易踩的坑是直接拿0xRRGGBB整数赋给lv_color_t有些版本上会得到错误颜色应该统一用lv_color_make或对应版本的构造方式。4.3 屏幕刷新与 invalidate 区域LVGL 的刷新模型是脏矩形机制你告诉它哪些区域需要重绘刷新任务会把这些区域合并后绘制到缓冲再通过 flush 回调发送给屏幕。粒子分散在屏幕多个方向时LVGL 会合并多个区域。如果合并后的区域接近全屏本质上你就等于在全屏重绘。全屏重绘本身不是问题问题在于频率。如果 timer 在 30ms 内触发了一次 invalidate而屏幕刷新任务还没完成上一帧工作任务就会积压。这种情况下可以看两个调节方向增大粒子更新的周期比如从 30ms 调整到 50ms。检查 LVGL 的刷新缓冲大小确保它足够容纳单次重绘区域。4.4 模拟器没问题真机卡顿的排查顺序模拟器通常跑在 PC 上CPU、内存和模拟显示都远强于 MCU很多问题不会暴露。真机卡顿时按下面这个顺序排查最有效顺序检查项动作1粒子数量先降到 10 颗看是否还卡2刷新周期调大lv_timer周期比如 50ms看负载3缓冲配置检查 LVGL 的 buffer 大小是否开了双缓冲4半透明混合暂时去掉所有半透明改用实心色块5日志和内存开启 LVGL 日志看是否有内存不足或任务超时6MCU 性能初步评估主频和 RAM必要时降低画质和粒子密度这里最容易被忽略的是半透明混合。RGB565 下的半透明需要逐像素做颜色混合运算低端 MCU 上做一次全屏半透明绘制可能比画 100 个实心粒子还贵。第一版效果请尽量用“实心小方块 颜色变化”来模拟火光而不是叠加一层半透明光晕。5. 把烟花效果沉淀成可复用组件5.1 设计一个简单的 ui_firework 模块为了让效果可以复用到多个页面我建议把烟火逻辑独立成一个模块不依赖具体 UI 页面的状态。对外暴露的接口可以很简洁void firework_init(void); void firework_launch(lv_coord_t x, lv_coord_t y, lv_color_t color); void firework_update(void); void firework_draw(lv_draw_ctx_t *draw_ctx);firework_init初始化粒子池把所有粒子标记为 inactive。firework_launch在指定坐标触发一次爆炸从粒子池里领取粒子设置初始速度和颜色。firework_update每帧调用更新所有粒子位置、速度、生命周期。firework_draw在绘制事件里把存活粒子绘制到屏幕。页面层只需要做两件事把firework_draw挂到某个对象的 draw 事件上在需要放烟花的时机调用firework_launch。这个模块天然可测试你可以在 PC 模拟器里纯日志模式跑一轮确认粒子生命周期和坐标范围都正常再接入界面。5.2 在加载页、节日页面、开机动画中的组合方式把效果绑定到具体页面上并不优雅。更好的做法是提供firework_start和firework_stop这样的开关页面在显示时启动隐藏时停止。开机动画里你可以先展示品牌 logo再在屏幕中央或偏下位置触发 2 到 3 次连续爆炸。加载页里粒子更新周期要避开耗时初始化函数的主循环确保 LVGL 的lv_timer_handler仍然能被正常调用。节日弹窗和普通 App 页面同理打开弹窗时启动关闭弹窗时停止不要让失效粒子继续占用 CPU。5.3 参数化和可配置化不要把粒子数、爆炸点坐标、颜色、重力、打击间隔写死在计算函数里。把它们整理成一个配置结构体不同屏和不同性能目标只需要改参数表typedef struct { uint16_t max_particles; uint8_t particles_per_burst; uint8_t max_bursts; int16_t gravity_x10; lv_color_t colors[4]; uint16_t update_period_ms; } firework_config_t;例如在 320x240 的 RGB565 屏幕上重力用 0.08 像素/帧²到了 480x272 的屏幕上分辨率变大后重力可能调整为 0.12否则火星下落速度看起来会太慢。颜色表里放 4 种主要花色每次爆炸随机选一种既丰富了画面又能保证色系在可控范围内。6. 常见坑点与完整排查链路6.1 先看清现象再判断方向同样一个“效果不对”背后的原因差很多。先做好分类再动手排查。现象可能原因卡顿粒子过多、刷新区域过大、半透明混合过多、timer 周期过短花屏内存越界、色彩格式不一致、刷新 buffer 大小不匹配闪烁单缓冲全屏刷新、刷新和绘制不同步、清屏时机不对无输出坐标越界、粒子生命周期为 0、draw 回调未注册、invalidate 区域不对屏幕闪烁这个问题很特殊。如果用了单缓冲全屏 invalidate 时刷新任务边擦边写很容易看到撕裂和闪光。双缓冲能显著缓解代价是内存翻倍。在 RAM 允许的情况下双缓冲是烟火效果更顺滑的基础但你要是想省内存就得接受闪烁风险。6.2 排查顺序输入、环境、内存、刷新、参数、日志当你遇到问题时按下面链路逐层排查不要在“参数”这一层反复纠结输入确认粒子坐标是否在屏幕范围内粒子数组有没有越界。环境确认 LVGL 版本、模拟器和真机色彩格式是否一致有没有开双缓冲。内存用lv_mem_monitor查看内存余量和碎片率如果使用静态数组重点排查数组越界。刷新检查是否一直有区域被持续 invalidate刷新周期是否设置合理是否有大量全屏刷新。参数把粒子数、速度、生命周期先调小再逐步加参数找到临界点。日志打开 LVGL 日志检查是否有内存不足、任务超时和绘制失败的提示。6.3 不要让 LVGL 主循环被粒子逻辑阻塞很多新手会把粒子更新放在自己写的while循环里或者用HAL_Delay等待若干毫秒再更新位置。这在裸机工程里会严重干扰 LVGL 的任务调度。LVGL 需要周期性调用lv_timer_handler然后分发到各类定时器和刷新任务。如果你在主循环里用 delay 卡死输入处理、动画、绘制全部会被阻塞最终表现是画面原地卡死或者出现不可预测的跳变。更稳妥的做法是粒子更新或者放一个lv_timer或者放进你自己的非阻塞状态机里确保每次回调都快速返回。不要让单次回调做太多耗时操作比如在回调里做全屏缓冲清理、大范围 memcpy 或打印大量日志这些都会拉长回调执行时间阻塞后续任务。收尾想回到一个更底层的经验这个效果做完之后给我留下的最深印象不是烟花本身而是一套在有限资源下管理大量临时活跃元素的通用方法。以后不管是要做粒子雨、动态星空、加载动画还是某种形式的“光点追踪”都可以复用同一套骨架纯数据粒子池、预设参数、独立更新周期、统一绘制入口。如果你想进阶还可以在骨架之上做彩色渐变、爆炸点之间的连锁触发、持续时间衰减、音量联动。但不管后面加多少功能第一步永远是先把一颗粒子跑通让它在屏幕上完整走过“出生、飞行、消失”的整个生命周期再考虑满屏炸开。别急着一次做一百朵烟花先从最小可用版本开始。
很多用 LVGL 做嵌入式界面的朋友最终都会遇到一个看似和 GUI 无关的需求在开机页、加载页或者节日主题里放一段烟火效果。我第一次接到这个需求时第一反应是去 LVGL 的控件列表里找一个“烟花控件”结果当然是没有。接着想用动画 API 实现又发现lv_anim擅长的是单个对象的属性插值面对“一个爆炸点放出几十颗火星每颗都要独立飞行、变色、消失”这种需求默认动画模型并不够用。这篇文章不是要给你一段能直接复制粘贴后就完事的完整代码而是想把 LVGL 放烟火效果从最底层到工程落地拆开讲清楚它真正解决的是什么问题、有哪几条实现路线、内存和刷新机制会怎样影响最终效果以及真机上卡死时应该按什么顺序排查。先给一个核心判断LVGL 放烟火效果表面看是图形动画问题实际上是在有限内存、有限 CPU 和帧率约束下管理大量临时活跃粒子的资源问题。谁能把“粒子状态更新”和“屏幕绘制”分开谁就能在低性能 MCU 上做出流畅效果谁把这个边界搞错了哪怕模拟器上跑得再漂亮换到真实板子也会立刻露馅。1. 先想清楚放烟火效果真正要解决的是哪类问题1.1 效果看起来很炫核心却是一帧内要更新和绘制多少对象LVGL 的动画能力并不弱支持定时器、曲线、属性插值。一个圆环从 0 到 360 度旋转一个进度条从空到满一个标签平滑移动这些事情交给lv_anim都很自然。但烟火效果有一个明显差异它不是单对象属性变化而是多个粒子同时拥有位置、速度、生命周期、颜色、透明度、尺寸并且彼此独立。如果你用“控件动画”的思路硬堆比如每颗火星都创建一个lv_obj那么一颗烟花爆炸出 30 个粒子屏幕上同时有 3 颗烟花就是 90 个控件。LVGL 要维护的就不再是简单的一两次重绘而是一整棵控件树的样式计算、布局、事件分发、命中测试和绘制裁剪。控件数量从个位数涨到几十位每一帧的固定成本会被急剧放大。在低主频 MCU 上这会直接表现为画面卡顿、刷新率跳水甚至触发看门狗超时。1.2 为什么不能用常规控件动画硬堆每个lv_obj都不是一个简单的坐标点它除了位置和尺寸还有父对象、子对象链表、样式、事件、状态位、布局相关字段。哪怕它只是一个小到看不见的圆点也要付出对象的完整开销。更麻烦的是LVGL 刷新机制基于脏矩形区域你用几十个控件散布在屏幕不同位置LVGL 需要把多个 invalidate 区域合并再重绘绘制任务会变得非常零碎。真正适合烟花的做法是把问题拆成两层状态层用普通 C 结构体数组维护粒子包括坐标、速度、生命值、颜色、是否激活。表现层用 LVGL 的绘制能力或预渲染缓冲区把粒子状态刷到屏幕上。状态更新和绘制渲染分离后系统里的“活对象”数量永远可控不会因为粒子数量变多而让 LVGL 控件树爆炸。这个思路不只适合烟花凡是“大量独立小元素同时运动”的 LVGL 特效例如粒子雨、星空漂移、加载动画都可以走同一套骨架。所以它值得沉淀成一个组件而不是一次性脚本。2. LVGL 实现烟花的三种路线以及我为什么优先推荐 draw 路线2.1 路线一用 lv_canvas 画布粒子lv_canvas允许你把数据写入一块 buffer再把这个缓冲区显示到屏幕上。它的优点是像素操作直观你可以按坐标把某个点涂成火星的颜色适合需要精细像素效果的场景。缺点是内存开销很大。一块 320x240 的 RGB565 画布需要的缓冲就有 150KB 左右即使只用半屏也要额外吃掉几十 KB。嵌入式 GUI 项目的 RAM 通常十分紧张画布越多越难接受。而且如果所有粒子都画在同一块画布上每帧要先把上一帧全部清掉再重新画新帧很容易产生闪烁刷新策略要花不少心思去调。2.2 路线二每个粒子用一个 lv_obj 精灵把每颗火星实现成一个小控件比如一个带圆角样式的实心小方块或者一个带透明度的 label然后用lv_anim或手动更新坐标。这个方案代码量最少也最容易理解适合颗粒数很少的简化效果。比如只有两三颗火星在屏幕上掉落用lv_obj完全没问题。但粒子数量一旦上到 20 颗这个方案就会开始吃力。虽然单颗控件的绘制本身不算重但控件管理、样式计算、事件分发这些额外成本会被放大。更要命的是你很难精确控制绘制顺序和刷新合并某些硬件上会出现明显的逐片刷新闪烁。2.3 路线三用 draw callback 或自定义绘制事件直接画LVGL 提供了事件系统你可以在控件绘制阶段插入自定义绘制逻辑例如LV_EVENT_DRAW_MAIN。在回调里遍历粒子数组用 draw rect、draw arc 或 draw line 把火星画出来。这样粒子只是普通 C 数组不需要成为 LVGL 对象内存开销会小很多。这也是我最推荐的路线。它既保留了粒子系统的灵活性又避开了大量控件带来的额外开销。你要承担的成本是要理解 LVGL 的绘制回调机制以及不同版本之间的接口差异。LVGL 8 的绘制上下文和 LVGL 9 的 draw task 不是一回事落地前要先确认你用的是哪个大版本。2.4 三条路线的选型对比路线内存开销粒子数量上限实现难度适合场景lv_canvas 画布高需要额外画布缓冲区中等受画布刷新策略影响中需要精确定位像素、可接受额外内存lv_obj 精灵中每个粒子都有对象开销低10~20 个以内比较稳低极简效果、快速验证draw callback 自定义绘制低只需粒子数据数组高几十上百个可撑住中高正式产品质量、批量粒子、嵌入式真实平台这张表的数值是经验值不是绝对标准。不同屏幕分辨率、不同 MCU 主频、不同色彩格式下结果差异都会很大。选型不如先用一个最小样例验证。3. 从零实现一个可运行的放烟火效果3.1 最小工程粒子结构体与状态机先从一颗粒子开始建结构。不要让它依赖 LVGL 控件保持为普通 C 结构体#define MAX_PARTICLES 128 typedef struct { int16_t x; int16_t y; float vx; float vy; int16_t life; int16_t max_life; lv_color_t color; bool active; } firework_particle_t; static firework_particle_t particles[MAX_PARTICLES];“一帧”的推进我们交给定时器回调所以结构体里用“帧号”来表示生命周期。life从max_life递减到 0active表示这个粒子是否正在飞行。爆炸时从数组里找一个active false的槽位填入初始状态粒子生命结束后再把active改回 false。一个完整的烟火状态机至少包含三个阶段IDLE还没有触发。EXPLODE在某个坐标释放一批粒子。FLY / FADE粒子飞行同时生命周期递减颜色或透明度慢慢变化。3.2 用 lv_timer 驱动粒子更新LVGL 有自己的时间基准和定时器系统推荐使用lv_timer_create注册周期回调不要在应用层再用HAL_Delay或vTaskDelay自己控制时机。lv_timer_t *timer lv_timer_create(firework_timer_cb, 30, NULL);回调里做三件事遍历粒子数组更新位置x vx; y vy; vy gravity;生命周期减一粒子消亡后标记为不活跃。调用lv_obj_invalidate通知 LVGL 重绘对应区域。这里要注意粒子更新周期不一定等于屏幕真正完成刷新的周期。如果你的 timer 更新得太快而底层刷新任务还在处理上一帧那你其实是在制造大量无效的绘制请求如果更新得太慢又会看到明显的跳帧。常见做法是把更新周期设置在 30ms 到 50ms 之间再根据真机表现微调。3.3 绘制把粒子状态变成像素或小色块如果你走 draw callback 路线可以在一个全屏透明对象的绘制事件里遍历粒子数组用lv_draw_rect或lv_draw_arc画小方块或小圆点。下面是一个简化示意接口以你实际使用的 LVGL 版本为准static void firework_draw_cb(lv_event_t *e) { lv_obj_t *obj lv_event_get_target(e); lv_draw_ctx_t *draw_ctx lv_event_get_draw_ctx(e); for (int i 0; i MAX_PARTICLES; i) { if (!particles[i].active) continue; lv_draw_rect_dsc_t rect_dsc; lv_draw_rect_dsc_init(rect_dsc); rect_dsc.bg_color particles[i].color; rect_dsc.radius 0; lv_area_t area; area.x1 particles[i].x - 1; area.y1 particles[i].y - 1; area.x2 particles[i].x 1; area.y2 particles[i].y 1; lv_draw_rect(draw_ctx, rect_dsc, area); } }从性能角度看绘制 2x2 或 3x3 的实心方块永远比画圆点快。圆点在视觉上更接近传统烟花火星但代价是需要额外处理抗锯齿或半透明低端 MCU 上会明显拖慢帧率。第一次跑通时先画方块效果好看了再去优化形状。3.4 关键参数粒子数量、爆炸数据、重力、衰减一组适合多数 320x240 屏幕的起点参数参数建议值说明单个爆炸点粒子数20~40 颗太少没气氛太多会卡同时爆炸点2~3 个再多会超过屏幕信息量粒子初始速度2~5 像素/帧按刷新周期和分辨率调整重力系数0.05~0.15 像素/帧²太大会很快坠地太小会飘生命周期30~70 帧决定火星消失速度这里的“像素/帧”里的帧指lv_timer的更新周期而不是屏幕硬件刷新率。要形成自然的抛物线应该在vy上累加重力而不是直接给一个固定下落速度。爆炸点产生粒子时速度方向最好带随机角度和随机幅度否则每次烟花都一模一样视觉上非常死板。MCU 上常用的rand()通常够用如果你发现随机质量太差可以用一个简单的线性同余生成器或者预置一张随机数查找表。4. 内存优化与平台适配STM32 和 ESP32 上的落地差异4.1 内存管理避免每帧 malloc/freeLVGL 有自带的内存池比如lv_mem_alloc、lv_mem_free每块内存都带管理信息调用很方便。但粒子系统如果每一帧都在创建和释放粒子对象会产生大量碎片和性能抖动长期运行会越来越卡。更好的方式是一开始就预分配一个全局静态粒子数组。数组容量可以是 128 或 256烟花爆发时从空闲槽位分配粒子生命结束就把槽位归还。这里说的“分配”和“归还”只是修改一个active布尔值不需要真的调用内存分配函数。你可以调用lv_mem_monitor查看当前内存剩余和碎片率尤其在做完一轮爆炸后再看一次确认没有内存持续减少。如果发现 free size 一点点被吞掉基本可以判断是某些路径在反复进行小对象分配。4.2 色彩格式RGB565 下怎么让烟花更好看很多廉价 RGB 屏幕默认是 RGB565颜色分量分布是 5 位红、6 位绿、5 位蓝。用lv_color_make(r, g, b)来生成颜色即可但要理解色阶的粗糙度。纯白是lv_color_make(255, 255, 255)而在 RGB565 里实际能表达的分量远少于 8 位。暖色烟花更容易在现有屏上显得鲜艳因为红色和绿色分量占的位更多。蓝色烟花在 RGB565 下相对吃亏容易显得偏暗。真机上第一版可以先选暖色系比如橙红、金黄、亮白。另一个容易踩的坑是直接拿0xRRGGBB整数赋给lv_color_t有些版本上会得到错误颜色应该统一用lv_color_make或对应版本的构造方式。4.3 屏幕刷新与 invalidate 区域LVGL 的刷新模型是脏矩形机制你告诉它哪些区域需要重绘刷新任务会把这些区域合并后绘制到缓冲再通过 flush 回调发送给屏幕。粒子分散在屏幕多个方向时LVGL 会合并多个区域。如果合并后的区域接近全屏本质上你就等于在全屏重绘。全屏重绘本身不是问题问题在于频率。如果 timer 在 30ms 内触发了一次 invalidate而屏幕刷新任务还没完成上一帧工作任务就会积压。这种情况下可以看两个调节方向增大粒子更新的周期比如从 30ms 调整到 50ms。检查 LVGL 的刷新缓冲大小确保它足够容纳单次重绘区域。4.4 模拟器没问题真机卡顿的排查顺序模拟器通常跑在 PC 上CPU、内存和模拟显示都远强于 MCU很多问题不会暴露。真机卡顿时按下面这个顺序排查最有效顺序检查项动作1粒子数量先降到 10 颗看是否还卡2刷新周期调大lv_timer周期比如 50ms看负载3缓冲配置检查 LVGL 的 buffer 大小是否开了双缓冲4半透明混合暂时去掉所有半透明改用实心色块5日志和内存开启 LVGL 日志看是否有内存不足或任务超时6MCU 性能初步评估主频和 RAM必要时降低画质和粒子密度这里最容易被忽略的是半透明混合。RGB565 下的半透明需要逐像素做颜色混合运算低端 MCU 上做一次全屏半透明绘制可能比画 100 个实心粒子还贵。第一版效果请尽量用“实心小方块 颜色变化”来模拟火光而不是叠加一层半透明光晕。5. 把烟花效果沉淀成可复用组件5.1 设计一个简单的 ui_firework 模块为了让效果可以复用到多个页面我建议把烟火逻辑独立成一个模块不依赖具体 UI 页面的状态。对外暴露的接口可以很简洁void firework_init(void); void firework_launch(lv_coord_t x, lv_coord_t y, lv_color_t color); void firework_update(void); void firework_draw(lv_draw_ctx_t *draw_ctx);firework_init初始化粒子池把所有粒子标记为 inactive。firework_launch在指定坐标触发一次爆炸从粒子池里领取粒子设置初始速度和颜色。firework_update每帧调用更新所有粒子位置、速度、生命周期。firework_draw在绘制事件里把存活粒子绘制到屏幕。页面层只需要做两件事把firework_draw挂到某个对象的 draw 事件上在需要放烟花的时机调用firework_launch。这个模块天然可测试你可以在 PC 模拟器里纯日志模式跑一轮确认粒子生命周期和坐标范围都正常再接入界面。5.2 在加载页、节日页面、开机动画中的组合方式把效果绑定到具体页面上并不优雅。更好的做法是提供firework_start和firework_stop这样的开关页面在显示时启动隐藏时停止。开机动画里你可以先展示品牌 logo再在屏幕中央或偏下位置触发 2 到 3 次连续爆炸。加载页里粒子更新周期要避开耗时初始化函数的主循环确保 LVGL 的lv_timer_handler仍然能被正常调用。节日弹窗和普通 App 页面同理打开弹窗时启动关闭弹窗时停止不要让失效粒子继续占用 CPU。5.3 参数化和可配置化不要把粒子数、爆炸点坐标、颜色、重力、打击间隔写死在计算函数里。把它们整理成一个配置结构体不同屏和不同性能目标只需要改参数表typedef struct { uint16_t max_particles; uint8_t particles_per_burst; uint8_t max_bursts; int16_t gravity_x10; lv_color_t colors[4]; uint16_t update_period_ms; } firework_config_t;例如在 320x240 的 RGB565 屏幕上重力用 0.08 像素/帧²到了 480x272 的屏幕上分辨率变大后重力可能调整为 0.12否则火星下落速度看起来会太慢。颜色表里放 4 种主要花色每次爆炸随机选一种既丰富了画面又能保证色系在可控范围内。6. 常见坑点与完整排查链路6.1 先看清现象再判断方向同样一个“效果不对”背后的原因差很多。先做好分类再动手排查。现象可能原因卡顿粒子过多、刷新区域过大、半透明混合过多、timer 周期过短花屏内存越界、色彩格式不一致、刷新 buffer 大小不匹配闪烁单缓冲全屏刷新、刷新和绘制不同步、清屏时机不对无输出坐标越界、粒子生命周期为 0、draw 回调未注册、invalidate 区域不对屏幕闪烁这个问题很特殊。如果用了单缓冲全屏 invalidate 时刷新任务边擦边写很容易看到撕裂和闪光。双缓冲能显著缓解代价是内存翻倍。在 RAM 允许的情况下双缓冲是烟火效果更顺滑的基础但你要是想省内存就得接受闪烁风险。6.2 排查顺序输入、环境、内存、刷新、参数、日志当你遇到问题时按下面链路逐层排查不要在“参数”这一层反复纠结输入确认粒子坐标是否在屏幕范围内粒子数组有没有越界。环境确认 LVGL 版本、模拟器和真机色彩格式是否一致有没有开双缓冲。内存用lv_mem_monitor查看内存余量和碎片率如果使用静态数组重点排查数组越界。刷新检查是否一直有区域被持续 invalidate刷新周期是否设置合理是否有大量全屏刷新。参数把粒子数、速度、生命周期先调小再逐步加参数找到临界点。日志打开 LVGL 日志检查是否有内存不足、任务超时和绘制失败的提示。6.3 不要让 LVGL 主循环被粒子逻辑阻塞很多新手会把粒子更新放在自己写的while循环里或者用HAL_Delay等待若干毫秒再更新位置。这在裸机工程里会严重干扰 LVGL 的任务调度。LVGL 需要周期性调用lv_timer_handler然后分发到各类定时器和刷新任务。如果你在主循环里用 delay 卡死输入处理、动画、绘制全部会被阻塞最终表现是画面原地卡死或者出现不可预测的跳变。更稳妥的做法是粒子更新或者放一个lv_timer或者放进你自己的非阻塞状态机里确保每次回调都快速返回。不要让单次回调做太多耗时操作比如在回调里做全屏缓冲清理、大范围 memcpy 或打印大量日志这些都会拉长回调执行时间阻塞后续任务。收尾想回到一个更底层的经验这个效果做完之后给我留下的最深印象不是烟花本身而是一套在有限资源下管理大量临时活跃元素的通用方法。以后不管是要做粒子雨、动态星空、加载动画还是某种形式的“光点追踪”都可以复用同一套骨架纯数据粒子池、预设参数、独立更新周期、统一绘制入口。如果你想进阶还可以在骨架之上做彩色渐变、爆炸点之间的连锁触发、持续时间衰减、音量联动。但不管后面加多少功能第一步永远是先把一颗粒子跑通让它在屏幕上完整走过“出生、飞行、消失”的整个生命周期再考虑满屏炸开。别急着一次做一百朵烟花先从最小可用版本开始。
