做STM32加屏的项目绕不开LVGL。不管是做仪表盘、智能家居面板还是工业HMI只要界面上跳转一多页面切换必然成为整个工程里最让人头疼的环节。功能逻辑全通了UI一上就崩溃这种场景我见过太多次了。真正把方案想清楚了再动手后面能省一大半调试时间。这篇文章不废话直接讲LVGL页面切换的三种主流方案结合我实际跑过的STM32工程把各自的原理、代码、代价和适用场景全讲透最后再给出一套能直接抄作业的内存优化配置。先说结论页面切换的本质不是“切界面”而是“管内存”。LVGL跑在MCU上RAM就那么大换页的时候你是在重新分配一堆对象还是复用已有的对象直接决定了整个项目的内存水位和交互流畅度。后面所有的方案对比、代码设计、优化手段都是围绕这句核心认知展开的。1. 先搞清楚需求页面切换本质是在管内存很多人一开始接触LVGL习惯性地把页面理解成PC上的“窗口”每切一次就创建一个全新的界面用完就销毁。这个思路在带操作系统的Linux上没问题但在STM32这种内存以KB为单位的芯片上是走不通的。LVGL里创建一个控件哪怕是最简单的标签lv_label也要在LVGL内部管理的内存池lv_mem里分配内存。创建一个按钮需要分配lv_obj_t这个对象结构体再加上样式、布局、事件回调相关的辅助结构。实测下来一次页面切换如果你把整个页面的控件全量重新创建开销通常在几KB到几十KB之间具体取决于页面复杂度。如果一个页面里有图片、有图表、有输入框那一次创建可能直接吃掉十几KB的RAM。这就带来两个问题第一MCU内存不够你同时把所有页面都常驻在内存里第二即便内存够频繁地创建和销毁对象会产生内存碎片跑久了之后LVGL分配内存会越来越慢最终在某一次切页时直接HardFault。所以在动手写代码之前你得先回答三个问题这个设备一共有几个页面页面之间是并列关系还是可以复用同一个布局切换页面的频率高不高需不需要动画过渡这三个问题的答案决定了你该选下面三种方案里的哪一种。我也见过很多初学者上来就写lv_scr_load_anim页面一多内存就不够然后回过头去瞎猜LVGL是不是有bug。不是库的问题是方案没有按需求选。2. 三种页面切换方案效果和代价我都替你们试过了这里我把工程里最常用的三种方案列出来。每一种我都用STM32F407加一块4.3寸RGB屏实际测过包括内存占用和切换体验。先看横向对比再做详细的代码拆解。方案核心思路RAM占用切换动画代码量适用场景A隐藏/显示切换所有页面常驻切页只改visible属性高无最少页面少、内存大、切换频繁Blv_scr_load / lv_scr_load_anim切换屏幕对象旧屏销毁或保留中支持中等2~5个独立页面、需要动画C容器复用 动态创建/销毁一个容器循环利用切页时清掉子控件重画低可模拟中等偏复杂页面结构相似、内存紧张2.1 方案A隐藏/显示切换简单但最吃内存这个方案是很多人最早写对的版本。思路非常直白在初始化阶段把所有页面用lv_obj_create建好每个页面是一个独立的lv_obj然后全部加到屏幕上。切页的时候把当前页设为隐藏lv_obj_add_flag(last_page, LV_OBJ_FLAG_HIDDEN)再把目标页设为可见lv_obj_clear_flag(new_page, LV_OBJ_FLAG_HIDDEN)。代码大概长这样static lv_obj_t *page_main; static lv_obj_t *page_setting; static lv_obj_t *page_about; void ui_init(void) { lv_obj_t *scr lv_scr_act(); page_main lv_obj_create(scr); lv_obj_set_size(page_main, 480, 272); // ...在这里创建主页面上的所有子控件 page_setting lv_obj_create(scr); lv_obj_set_size(page_setting, 480, 272); // ...创建设置页面的子控件 lv_obj_add_flag(page_setting, LV_OBJ_FLAG_HIDDEN); page_about lv_obj_create(scr); lv_obj_set_size(page_about, 480, 272); // ...创建关于页面的子控件 lv_obj_add_flag(page_about, LV_OBJ_FLAG_HIDDEN); } void switch_page(lv_obj_t *page) { lv_obj_add_flag(page_main, LV_OBJ_FLAG_HIDDEN); lv_obj_add_flag(page_setting, LV_OBJ_FLAG_HIDDEN); lv_obj_add_flag(page_about, LV_OBJ_FLAG_HIDDEN); lv_obj_clear_flag(page, LV_OBJ_FLAG_HIDDEN); }优点是代码逻辑最简单不需要在意创建和销毁因为对象一直在。切换速度也很快因为只是改标志位不需要重新布局。缺点同样致命所有页面的所有控件从开机到关机一直占着RAM。哪怕你停在主界面三天不动设置页面上的图标、标签、表盘也都在内存里待着。我实测过一个工程三个页面一共37个控件页面常驻方案比动态方案多占了接近16KB的RAM。对STM32F103这种芯片来说16KB已经是半个天了。这个方案适合什么场景呢我建议只在两种情况下用一是芯片RAM非常充裕比如STM32H743起步UI复杂度又低二是切换极其频繁而且不能有任何重建卡顿的页面关系。如果你的内存小于64KB建议直接跳过这个方案。2.2 方案Blv_scr_load和lv_scr_load_anim官方最推荐的思路方案B的做法是把每个页面做成一个独立的screen对象然后用lv_scr_load_anim(old_scr, new_scr, LV_SCR_LOAD_ANIM_MOVE_LEFT, 300, 0, false)这类接口切换。这是LVGL官方文档里明确的推荐做法也是大多数例程里出现的姿势。核心区别在于screen在LVGL里是一个特殊的对象整个显示器的容器。你切换screen的时候是把整个屏幕的根节点换掉了之前屏幕上的所有控件都跟着一起被卸载。这里有一个非常关键的点lv_scr_load_anim在切换过程中会做一个旧屏的截图备份用来做动画。这意味着动画期间内存峰值会短暂上升。对于内存抠得比较紧的芯片动画时长最好不要超过300ms更不要用复杂的动画路径不然动画刚开始内存就爆了。我自己踩过这个坑在STM32F411上跑200ms的滑动动画动画居然卡成了PPT后来查内存就是动画备份导致瞬时内存用量飙升。下面是一段简化后的工程代码static lv_obj_t *scr_main; static lv_obj_t *scr_setting; void ui_screens_init(void) { scr_main lv_obj_create(NULL); lv_obj_set_style_bg_color(scr_main, lv_color_hex(0x1a1a2e), 0); scr_setting lv_obj_create(NULL); lv_obj_set_style_bg_color(scr_setting, lv_color_hex(0x16213e), 0); } void switch_screen_to_main(void) { lv_scr_load_anim(scr_main, LV_SCR_LOAD_ANIM_MOVE_RIGHT, 300, 0, false); }这里有两个很容易被忽略的细节。第一创建screen的时候父对象必须是NULL而不能是lv_scr_act()。如果你把第二个screen的父对象设成了当前屏幕那这个screen永远只是当前屏幕上的一个子控件切来切去都跳不出去。第二lv_scr_load_anim最后一个参数是auto_del指动画结束后是否自动销毁旧屏。如果你的页面是动态创建出来的临时页比如弹窗、输入密码的页面可以设为true用完全自动释放。如果是主页面、设置页这种需要继续存在的页面必须设为false否则下次切回来就是一个空指针。方案B的建议使用场景页面数量不多2~5个每个页面结构差异大UI有明确的层次关系。这是我在绝大多数项目里的默认选择。2.3 方案C容器复用把内存用到极致的思路方案C是对方案B的进一步优化适合子页面很多但每个页面的“外壳”是一样的场景。比如一个多级菜单系统顶栏、底栏、背景都相同只有中间内容区在变。这种情况下如果每个子页面都单独建一个screen内存浪费非常明显。方案C的做法是只创建一个screen上面放一个固定大小的容器专门用来承载内容区。切换页面的时候先调用lv_obj_clean(content_container)把容器里的旧子控件全部删除再动态创建新页面的控件。核心代码如下static lv_obj_t *content_container; void ui_content_init(void) { lv_obj_t *scr lv_scr_act(); content_container lv_obj_create(scr); lv_obj_set_size(content_container, 480, 220); lv_obj_align(content_container, LV_ALIGN_BOTTOM_MID, 0, 0); } void show_menu_page(uint8_t page_id) { lv_obj_clean(content_container); // 关键先清掉旧内容 if (page_id 0) { create_menu_buttons(content_container); // 在容器里创建按钮 } else if (page_id 1) { create_about_content(content_container); } }这种方案最大的优势是内存占用极低。因为同一时刻内容区只有一份控件对象存在。你从菜单A切到菜单B菜单A的对象已经全部释放内存池重新回收了那一块区域新的控件直接复用这块内存。代价是什么呢第一切页的时候有短暂的重建时间如果页面控件非常多超过30个肉眼可见地顿一下。第二你得自己管理好所有的事件回调、动画、定时器切页清理的时候不能漏否则这些资源没被释放内存还是会被一点一点吃掉。我实际用这个方案做了一个8页的菜单系统内存占用比方案B降低了大概30%。所以如果你的产品是那种菜单嵌套很深、每层页面外观相似、RAM又刚好卡在临界点方案C就是最优解。2.4 三种方案怎么选给一个可直接套用的判断标准我在给团队评审代码的时候一般直接用这个标准来判断页面数量小于等于3且RAM足够方案A。省事代码最不容易出bug。页面数量3~8页面之间是平级关系、内容差异大方案B。动态加载内存可控。页面数量8个以上且很多页面共享同一套骨架方案C。复用容器内存节省最明显。切换必须带流畅动画且动画过程不能消耗过多RAM方案B配短时长动画100~200ms同时把动画路径设为线性。每个页面都有大量相同控件如大量重复的按钮、标签必须用方案C或者结合模板复用否则RAM无解。另外三种方案并不是互斥的。工程里完全可以混用主界面和设置页这种重量级页面用方案B菜单的二级子页面用方案C。我最后做出来的HMI项目就是这种混合结构的。说到底方案是死的RAM是有限的满足需求的前提下只要能省内存怎么组合都合理。3. 内存优化实操把每一字节都用在刀刃上3.1 先给LVGL算一笔内存账在STM32上跑LVGL你首先要对“我的芯片到底能装下多大的UI”有个准确预估。LVGL的内存消耗主要在三块第一块是LVGL的全局工作内存也就是lv_conf.h里LV_MEM_SIZE宏定义的大小。LVGL所有动态对象都从这里分配相当于LVGL自己的堆。第二块是显示缓冲区LVGL渲染UI时要一个显存buffer这个buffer得想办法从LV_MEM_SIZE之外分配通常是一个全局数组。第三块是字模、图片等静态资源如果以C数组形式编译进固件它们占用的是Flash而非RAM但如果你用lv_img_set_src加载图片时选择了解码到RAM的模式那就会额外消耗RAM。一个大概的参考值STM32F407192KB RAM跑LVGLLV_MEM_SIZE设到64KB是比较健康的水平。如果你用的芯片只有32KB RAM那LV_MEM_SIZE最多分到16KB这种情况下UI必须极简控件数量要控制在20个以内。这不是吓唬人是实际经验。RAM计算的经验公式我一般这么用单个控件平均消耗 250 ~ 500字节含对象结构体 基础样式 事件如果页面上有图片、图表、弧线表这类重度控件单个可以吃到1KB以上。页面所有控件加起来就是这一次页面所需的大致RAM。你需要确保同时存在的页面/容器里控件总量消耗不超过LV_MEM_SIZE的三分之二剩下三分之一留给临时分配比如动画备份、弹窗、字符串缓冲区。3.2 lv_conf.h里的关键配置每项都直接决定生死lv_conf.h是整个LVGL工程的命门它的配置直接影响内存表现。我挨个说重要的。LV_MEM_SIZE这是LVGL内部内存池大小。不要设得过大也不需要过小。设大了你会觉得“反正内存够”于是写代码就不克制设小了UI一复杂直接分配失败系统卡死。建议先用保守值跑通功能然后用lv_mem_monitor观察实际峰值再反向调整到最合适的值。这个习惯建议每个项目都保持。LV_MEM_CUSTOM这个宏决定LVGL是使用内置的内存管理器0还是使用C库的malloc/free1。在STM32上我建议保持默认的0也就是内置管理器。LVGL自带的分配器对碎片处理更好而且允许你精确控制内存池大小不依赖C库。LV_USE_LOG开启LVGL日志。建议在开发阶段设为1方便定位内存分配失败的具体位置。max_level设为LV_LOG_LEVEL_WARN足够err级别太少info级别太吵。显示buffer的设置是内存优化里最大的一块肉。LVGL的显示缓冲支持三种模式一块bufferLV_DISP_RENDER_MODE_PARTIAL、两块buffer交替LV_DISP_RENDER_MODE_DOUBLE、一块全屏bufferLV_DISP_RENDER_MODE_FULL。在STM32上全屏buffer代价太高不推荐。我一般用两段式双缓冲Buffer大小按屏幕宽的一行来计算#define MY_DISP_HOR_RES 480 #define MY_DISP_BUF_SIZE (MY_DISP_HOR_RES * 40) // 高度取40行其实就是分块渲染 static lv_disp_draw_buf_t draw_buf; static lv_color_t buf_1[MY_DISP_BUF_SIZE]; static lv_color_t buf_2[MY_DISP_BUF_SIZE];这里有两个考点。第一两段buffer不是“为了流畅”而是为了解决撕裂和DMA传输问题CPU在渲染buffer1的时候DMA可以把buffer2的内容送去屏幕两不耽误。第二如果你开启了颜色深度16bitLV_COLOR_DEPTH 16那lv_color_t是2字节480乘40行一个buffer就是480×40×2等于38400字节约37.5KB两个buffer加起来75KB。这就是为什么很多低端芯片跑不动480分辨率RAM全被显存吃掉了。变通的办法是降低分辨率或者把高度值从40降到20牺牲一点渲染效率换内存。字模也是内存大户。lv_conf.h里默认会启用LV_FONT_MONTSERRAT_14和LV_FONT_MONTSERRAT_16等几个默认字体。如果你用不到全部关掉只保留1~2个需要的。自定义大字体比如24号、32号中文字体不是“加载”进RAM的而是在编译时就转为C数组存在Flash里使用时不占RAM但会在运行时被读取并暂存到LVGL的字体缓存。如果你发现UI跑着跑着字体突然变成方框很可能就是字体缓存不够用此时可以调大LV_FONT_CACHE_DEFER_INIT或者相关缓存配置。3.3 对象复用、图片瘦身这些习惯要刻进肌肉记忆很多内存问题其实不是LVGL的锅而是写代码的人太“大方”。我见过一个工程每秒钟刷新一次时间显示代码是这样写的每次刷新都new一个lv_label然后删掉旧的。跑了半小时内存就爆了。正确做法是初始化时把label建好之后只调用lv_label_set_text去改文本。这是状态刷新和页面切换里最核心的习惯之一能复用的对象绝不多建。再说图片。LVGL加载图片有两种方式一种是把图片转成C数组编译进固件另一种是文件系统读取。在STM32上99%的场景都是第一种。图片转C数组时有一个关键参数是颜色格式。如果你的屏幕是RGB565图片最好也转成RGB565不要用RGB888否则显示接口会做格式转换占用额外内存和时间。一张480×272的全屏图RGB565格式是480×272×2等于261120字节约255KB。这种大图在多数MCU上都是奢侈的要么降低图片尺寸要么拆成小图块要么干脆用纯色和简单图形组合。对于页面切换里的图片还有一个小技巧在页面切换动画结束之后立刻把旧页面的图片缓存释放。LVGL的图片默认有缓存机制在动画期间会保留旧屏的截图。如果你确认动画结束后不会再回到旧页面用lv_img_cache_invalidate_src主动让缓存失效能快速释放内存。3.4 用监控函数掌握内存实时动态LVGL提供了一个非常好用的内存监控APIlv_mem_monitor。把它的结果通过串口打印出来就能看到内存池总大小、空闲大小、碎片率、已分配块数等数据。你不需要猜内存够不够直接看数据说话。void debug_print_mem_info(void) { lv_mem_monitor_t mon; lv_mem_monitor(mon); printf(total: %u, free: %u, used: %u, frag: %u%%\n, (unsigned int)mon.total_size, (unsigned int)mon.free_size, (unsigned int)mon.total_size - mon.free_size, (unsigned int)mon.frag_pct); }我一般会在每次页面切换完成后都调一次这个函数把内存信息打到串口。如果发现free_size在反复切换页面后不断下降说明有内存泄漏需要去查是不是有定时器、动画、事件回调没清理干净。这个方法帮我抓出过很多隐蔽的内存泄漏强烈建议保留在你自己的调试工具集里。4. 关键代码实操把三种方案跑在STM32上4.1 搭建一个可复用的UI初始化骨架在STM32上跑LVGL初始化是有固定套路的。不管你用方案A还是方案C下面这套骨架都通用void lvgl_init_hardware(void) { lv_init(); // 显示缓冲初始化 lv_disp_draw_buf_init(draw_buf, buf_1, buf_2, MY_DISP_BUF_SIZE); // 显示器驱动注册 static lv_disp_drv_t disp_drv; lv_disp_drv_init(disp_drv); disp_drv.hor_res 480; disp_drv.ver_res 272; disp_drv.flush_cb my_disp_flush_cb; disp_drv.draw_buf draw_buf; lv_disp_drv_register(disp_drv); // 触摸屏驱动注册如果有 static lv_indev_drv_t indev_drv; lv_indev_drv_init(indev_drv); indev_drv.type LV_INDEV_TYPE_POINTER; indev_drv.read_cb my_touchpad_read_cb; lv_indev_drv_register(indev_drv); }这里my_disp_flush_cb是你自己的LCD刷屏函数负责把LVGL渲染好的buffer数据写到屏幕。常见的写法是使用DMA把LVGL传入的buffer复制到LCD控制器的GRAM里。void my_disp_flush_cb(lv_disp_drv_t *drv, const lv_area_t *area, lv_color_t *color_p) { uint32_t w lv_area_get_width(area); uint32_t h lv_area_get_height(area); LCD_SetWindow(area-x1, area-y1, area-x2, area-y2); LCD_WriteDataDMA((uint16_t *)color_p, w * h); // 必须在DMA传输完成后调用 lv_disp_flush_ready(drv); }注意最后一个lv_disp_flush_ready一定要等DMA传完了再调不然LVGL会认为数据已经刷完提前把buffer交给渲染器继续往里面画导致画面出现撕裂或者残影。4.2 方案A代码隐藏/显示的具体实现方案A的核心是一个页面管理器结构体。用数组保存页面指针用索引作为切页参数。#define PAGE_COUNT 3 static lv_obj_t *page_list[PAGE_COUNT]; static uint8_t current_page_index 0; void page_register(uint8_t index, lv_obj_t *page) { page_list[index] page; lv_obj_add_flag(page, LV_OBJ_FLAG_HIDDEN); } void page_init(void) { // 创建三个页面并全部注册 page_register(0, create_main_page()); page_register(1, create_setting_page()); page_register(2, create_about_page()); // 显示默认页 lv_obj_clear_flag(page_list[0], LV_OBJ_FLAG_HIDDEN); } void page_switch_to(uint8_t index) { if (index PAGE_COUNT || index current_page_index) return; lv_obj_add_flag(page_list[current_page_index], LV_OBJ_FLAG_HIDDEN); lv_obj_clear_flag(page_list[index], LV_OBJ_FLAG_HIDDEN); current_page_index index; }这段代码的精髓在于用数组抽象了“页面”这个概念之后不管是按键触发还是触摸事件只需调用page_switch_to(page_index)就行了页面管理逻辑和具体UI解耦。4.3 方案B代码带动画的屏幕切换实现方案B在切换时用lv_scr_load_anim其中要注意动画方向和持续时间的参数匹配。我习惯写一个独立的切换函数便于全局统一管理void screen_switch(lv_obj_t *target_scr, lv_scr_load_anim_t anim_type) { lv_scr_load_anim(target_scr, anim_type, 300, 0, false); } // 使用示例点击某个按钮切入设置页面 void setting_btn_event_cb(lv_event_t *e) { lv_event_code_t code lv_event_get_code(e); if (code LV_EVENT_CLICKED) { screen_switch(scr_setting, LV_SCR_LOAD_ANIM_MOVE_LEFT); } }关于auto_del参数我再强调一遍如果你这个screen本身是常驻页面必须传false。如果这个screen是一次性的临时页面比如一个弹出的提醒页传true可以让它在动画结束后自动销毁省去手动释放的步骤。还要注意动画期间LVGL的时间片来自lv_tick_inc。在STM32上用定时器每1ms调用一次lv_tick_inc(1)动画的计时才准确否则动画忽快忽慢甚至在低优先级任务里被卡住。4.4 方案C代码复用容器的动态内容区实现方案C适合内容区结构相似的多页菜单。我在工程里写了一个小框架typedef struct { uint8_t page_id; void (*create_cb)(lv_obj_t *parent); } menu_page_t; static const menu_page_t menu_pages[] { {0, menu_page_main_create}, {1, menu_page_status_create}, {2, menu_page_config_create}, }; void menu_show_page(uint8_t page_id) { if (page_id sizeof(menu_pages) / sizeof(menu_pages[0])) return; lv_obj_clean(content_container); // 调用对应页面的创建函数往公共容器里添加控件 menu_pages[page_id].create_cb(content_container); }每个子页面的create_cb只负责“在当前父容器下创建自己的控件”不关心其他页面。切页时一个lv_obj_clean把旧的清掉再创建新的内存自动复用。这种结构写起来思路清晰也方便后续扩展新页面加一个数组项写一个create函数就行不用改动切换逻辑。有一点要特别叮嘱在创建控件时尽量不要给父容器加LV_OBJ_FLAG_SCROLLABLE以外的“持久化”属性。因为容器里的子控件每次都会被清掉重建如果你在某个子控件上挂了一个lv_timer或者lv_anim一定要在它被清除前主动删除否则这些timer/anim对象依然存在指向已释放的内存轻则内存泄漏重则直接崩溃。安全起见可以把所有需要清理的timer在create函数的末尾用一个全局列表保存在lv_obj_clean之前统一删除。4.5 和FreeRTOS配合时的几个细节很多STM32工程是跑FreeRTOS的LVGL只是其中一个任务。这里有几个坑我一个个说清楚。第一lv_tick_inc必须可靠。LVGL的时基不依赖时钟中断而是靠代码里主动调用lv_tick_inc。在FreeRTOS里我建议在SysTick中断里调用或者用一个1ms周期的高优先级定时器中断调用。不要把它放在LVGL任务里去调因为任务调度有延迟会导致动画时间不准确。第二lv_task_handler只能在一个任务里跑。LVGL不是线程安全的不能在两个任务里同时调用lv_task_handler。一般做法是单独建一个LVGL任务优先级中等比关键控制任务低比后台任务高周期设置成5ms或者10ms调用一次lv_task_handler。如果你有两个地方都在调内存池会被两个线程同时访问跑一会必崩。第三如果你使用双缓冲和DMA刷屏要留意DMA和CPU访问同一块内存的问题。在带Cache的芯片上比如STM32H7刷屏前要做Cache clean操作刷完做Cache invalidate否则屏幕会出现花屏或者颜色错乱。F1/F4没有Cache不用管这个但如果从F4移植到H7这一步忘了屏幕绝对花而且很难排查。5. 切换卡顿、白屏、崩溃问题排查技巧实录5.1 切页卡顿先分清是重建慢还是渲染慢很多人一遇到切页卡顿就怀疑LVGL动画参数不对。其实卡顿一般分两种。第一种是控件创建慢。当你用方案C页面里控件特别多比如一个图表几十个数据点每次lv_obj_clean再重建重建的CPU开销不容忽视。这种情况的卡顿点是“切过去之后界面慢慢出来”不属于动画卡属于创建卡。解决思路是减少控件数量或者把部分静态UI放到容器外常驻只重建数据部分。第二种是渲染慢。卡顿表现为动画过程中画面掉帧、拖动不跟手。这种通常是显示缓冲太小或者刷屏DMA没配好。LVGL的partial渲染模式本来就是一帧分多块刷新的buffer越小刷新的块数越多动画就越容易掉帧。如果你把显示buffer的高度设置成10行那动画效果基本没法看。我的建议是把高度调到40行以上至少覆盖屏幕高度的15%。5.2 切页后白屏先检查screen的父对象白屏或者黑屏90%的情况是screen的父对象设置错了。比如你在创建scr_setting时错误地写了lv_obj_create(lv_scr_act())那这个scr_setting根本不是screen只是当前屏幕上的一个普通子对象。你切到它的时候只是在一个大的暗色背景上显示了一个子区域看起来就像半黑屏。排查方法很简单把代码里所有创建screen的地方找出来确认父对象是NULL。如果创建的是page容器方案A父对象才是lv_scr_act()这两种概念不能混淆。还有一种白屏是显示缓冲不匹配导致的。当你屏幕分辨率设置是480×272但LVGL的hor_res和ver_res没改默认可能还是240×320渲染出来的画面尺寸不对看起来就像只画了屏幕的一小块。5.3 连续切换后内存泄漏用串口抓出来反复切换页面几次后系统越来越卡最后死机。这是最典型的LVGL内存泄漏场景。原因无外乎几个定时器没删、动画回调没清理、子控件没被正确释放、事件回调里new了对象没释放。我的排查流程是固定一套先在每次切页后调用lv_mem_monitor并打印free_size。如果free_size在反复切换后持续下降且不回升就基本确定泄漏。然后用二分法先注释掉一半代码继续切页看free_size是否还下降反复缩小范围直到锁定泄漏的那段代码。这个方法看起来笨但在嵌入式调试里是最行之有效的方法。你甚至可以自己写一个简易的内存标记函数每次切页前记录当前free_size切页后打印差值差值如果是递增的正数就是泄漏无疑。5.4 常见问题速查表问题现象常见原因处理办法切页后白屏screen父对象不是NULL分辨率配置不对检查lv_obj_create(NULL)核对disp_drv的hor_res/ver_res动画卡成PPT显示buffer高度太小动画时长过长增大buffer高度把300ms改到150~200ms反复切页后死机对象或timer泄漏加lv_mem_monitor打印逐段注释定位泄漏切页后点击无反应事件回调注册到了旧screen上新screen没有indev支持检查事件注册对象确认indev驱动注册成功页面重叠显示方案A的父对象都是lv_scr_act()且没有正确隐藏检查HIDDEN标志位确认页面切换时隐藏逻辑正常执行切页后DMA刷屏残留旧画面没有在flush里正确清除屏幕残留buffer在flush_cb里对area之外区域补刷一次背景色检查flush_ready调用时机中文字体变方框字体文件不包含当前字符的glyph字体缓存太小换用包含中文的子集字库增大字体缓存配置另外还有一个容易让人崩溃的问题在动画切换瞬间按下了触摸按键导致正在动画中的页面状态异常。这种问题一般建议在动画期间禁用输入设备或者用一个互斥变量表示“正在切页暂不响应触摸”动画结束后再恢复。这个处理在很多LVGL工程里都被忽略但实际产品里很容易被用户碰到。最后再分享一点个人体会LVGL的页面切换写多了你会发现真正难的从来不是API怎么调用而是你对内存和生命周期的理解程度。方案A、B、C本质上是对“控件创建和销毁时机”的不同安排不存在哪一个绝对最好只有哪一个最适合你这个产品、这块芯片、这批用户。我做过的项目里最终选定方案B为主局部嵌套方案C原因是产品UI既有平级的大板块跳转又有层级深的多级菜单混合使用让RAM从最初方案A的73%降到了58%界面切换还保留着动画用户体验没打折。调试过程中促成我做这些优化的就是那几行lv_mem_monitor打印——你有数据依据改方案才不慌。最后分享一个调试小技巧在工程里保留一个调试页面专门显示内存池信息。这个页面用方案C实现每次进去自动刷新一次内存信息。现场测试的时候随便怎么乱按界面切几百次之后打开这个页面看一眼内存还剩多少有没有泄漏一眼就出来了。这个小页面不占多少代码量但能帮你省出按周计算的排查时间。 
长河君 · 2026/9/28 8:05:51 · 阅读 1.2k STM32 LVGL页面切换方案与内存优化实战
做STM32加屏的项目绕不开LVGL。不管是做仪表盘、智能家居面板还是工业HMI只要界面上跳转一多页面切换必然成为整个工程里最让人头疼的环节。功能逻辑全通了UI一上就崩溃这种场景我见过太多次了。真正把方案想清楚了再动手后面能省一大半调试时间。这篇文章不废话直接讲LVGL页面切换的三种主流方案结合我实际跑过的STM32工程把各自的原理、代码、代价和适用场景全讲透最后再给出一套能直接抄作业的内存优化配置。先说结论页面切换的本质不是“切界面”而是“管内存”。LVGL跑在MCU上RAM就那么大换页的时候你是在重新分配一堆对象还是复用已有的对象直接决定了整个项目的内存水位和交互流畅度。后面所有的方案对比、代码设计、优化手段都是围绕这句核心认知展开的。1. 先搞清楚需求页面切换本质是在管内存很多人一开始接触LVGL习惯性地把页面理解成PC上的“窗口”每切一次就创建一个全新的界面用完就销毁。这个思路在带操作系统的Linux上没问题但在STM32这种内存以KB为单位的芯片上是走不通的。LVGL里创建一个控件哪怕是最简单的标签lv_label也要在LVGL内部管理的内存池lv_mem里分配内存。创建一个按钮需要分配lv_obj_t这个对象结构体再加上样式、布局、事件回调相关的辅助结构。实测下来一次页面切换如果你把整个页面的控件全量重新创建开销通常在几KB到几十KB之间具体取决于页面复杂度。如果一个页面里有图片、有图表、有输入框那一次创建可能直接吃掉十几KB的RAM。这就带来两个问题第一MCU内存不够你同时把所有页面都常驻在内存里第二即便内存够频繁地创建和销毁对象会产生内存碎片跑久了之后LVGL分配内存会越来越慢最终在某一次切页时直接HardFault。所以在动手写代码之前你得先回答三个问题这个设备一共有几个页面页面之间是并列关系还是可以复用同一个布局切换页面的频率高不高需不需要动画过渡这三个问题的答案决定了你该选下面三种方案里的哪一种。我也见过很多初学者上来就写lv_scr_load_anim页面一多内存就不够然后回过头去瞎猜LVGL是不是有bug。不是库的问题是方案没有按需求选。2. 三种页面切换方案效果和代价我都替你们试过了这里我把工程里最常用的三种方案列出来。每一种我都用STM32F407加一块4.3寸RGB屏实际测过包括内存占用和切换体验。先看横向对比再做详细的代码拆解。方案核心思路RAM占用切换动画代码量适用场景A隐藏/显示切换所有页面常驻切页只改visible属性高无最少页面少、内存大、切换频繁Blv_scr_load / lv_scr_load_anim切换屏幕对象旧屏销毁或保留中支持中等2~5个独立页面、需要动画C容器复用 动态创建/销毁一个容器循环利用切页时清掉子控件重画低可模拟中等偏复杂页面结构相似、内存紧张2.1 方案A隐藏/显示切换简单但最吃内存这个方案是很多人最早写对的版本。思路非常直白在初始化阶段把所有页面用lv_obj_create建好每个页面是一个独立的lv_obj然后全部加到屏幕上。切页的时候把当前页设为隐藏lv_obj_add_flag(last_page, LV_OBJ_FLAG_HIDDEN)再把目标页设为可见lv_obj_clear_flag(new_page, LV_OBJ_FLAG_HIDDEN)。代码大概长这样static lv_obj_t *page_main; static lv_obj_t *page_setting; static lv_obj_t *page_about; void ui_init(void) { lv_obj_t *scr lv_scr_act(); page_main lv_obj_create(scr); lv_obj_set_size(page_main, 480, 272); // ...在这里创建主页面上的所有子控件 page_setting lv_obj_create(scr); lv_obj_set_size(page_setting, 480, 272); // ...创建设置页面的子控件 lv_obj_add_flag(page_setting, LV_OBJ_FLAG_HIDDEN); page_about lv_obj_create(scr); lv_obj_set_size(page_about, 480, 272); // ...创建关于页面的子控件 lv_obj_add_flag(page_about, LV_OBJ_FLAG_HIDDEN); } void switch_page(lv_obj_t *page) { lv_obj_add_flag(page_main, LV_OBJ_FLAG_HIDDEN); lv_obj_add_flag(page_setting, LV_OBJ_FLAG_HIDDEN); lv_obj_add_flag(page_about, LV_OBJ_FLAG_HIDDEN); lv_obj_clear_flag(page, LV_OBJ_FLAG_HIDDEN); }优点是代码逻辑最简单不需要在意创建和销毁因为对象一直在。切换速度也很快因为只是改标志位不需要重新布局。缺点同样致命所有页面的所有控件从开机到关机一直占着RAM。哪怕你停在主界面三天不动设置页面上的图标、标签、表盘也都在内存里待着。我实测过一个工程三个页面一共37个控件页面常驻方案比动态方案多占了接近16KB的RAM。对STM32F103这种芯片来说16KB已经是半个天了。这个方案适合什么场景呢我建议只在两种情况下用一是芯片RAM非常充裕比如STM32H743起步UI复杂度又低二是切换极其频繁而且不能有任何重建卡顿的页面关系。如果你的内存小于64KB建议直接跳过这个方案。2.2 方案Blv_scr_load和lv_scr_load_anim官方最推荐的思路方案B的做法是把每个页面做成一个独立的screen对象然后用lv_scr_load_anim(old_scr, new_scr, LV_SCR_LOAD_ANIM_MOVE_LEFT, 300, 0, false)这类接口切换。这是LVGL官方文档里明确的推荐做法也是大多数例程里出现的姿势。核心区别在于screen在LVGL里是一个特殊的对象整个显示器的容器。你切换screen的时候是把整个屏幕的根节点换掉了之前屏幕上的所有控件都跟着一起被卸载。这里有一个非常关键的点lv_scr_load_anim在切换过程中会做一个旧屏的截图备份用来做动画。这意味着动画期间内存峰值会短暂上升。对于内存抠得比较紧的芯片动画时长最好不要超过300ms更不要用复杂的动画路径不然动画刚开始内存就爆了。我自己踩过这个坑在STM32F411上跑200ms的滑动动画动画居然卡成了PPT后来查内存就是动画备份导致瞬时内存用量飙升。下面是一段简化后的工程代码static lv_obj_t *scr_main; static lv_obj_t *scr_setting; void ui_screens_init(void) { scr_main lv_obj_create(NULL); lv_obj_set_style_bg_color(scr_main, lv_color_hex(0x1a1a2e), 0); scr_setting lv_obj_create(NULL); lv_obj_set_style_bg_color(scr_setting, lv_color_hex(0x16213e), 0); } void switch_screen_to_main(void) { lv_scr_load_anim(scr_main, LV_SCR_LOAD_ANIM_MOVE_RIGHT, 300, 0, false); }这里有两个很容易被忽略的细节。第一创建screen的时候父对象必须是NULL而不能是lv_scr_act()。如果你把第二个screen的父对象设成了当前屏幕那这个screen永远只是当前屏幕上的一个子控件切来切去都跳不出去。第二lv_scr_load_anim最后一个参数是auto_del指动画结束后是否自动销毁旧屏。如果你的页面是动态创建出来的临时页比如弹窗、输入密码的页面可以设为true用完全自动释放。如果是主页面、设置页这种需要继续存在的页面必须设为false否则下次切回来就是一个空指针。方案B的建议使用场景页面数量不多2~5个每个页面结构差异大UI有明确的层次关系。这是我在绝大多数项目里的默认选择。2.3 方案C容器复用把内存用到极致的思路方案C是对方案B的进一步优化适合子页面很多但每个页面的“外壳”是一样的场景。比如一个多级菜单系统顶栏、底栏、背景都相同只有中间内容区在变。这种情况下如果每个子页面都单独建一个screen内存浪费非常明显。方案C的做法是只创建一个screen上面放一个固定大小的容器专门用来承载内容区。切换页面的时候先调用lv_obj_clean(content_container)把容器里的旧子控件全部删除再动态创建新页面的控件。核心代码如下static lv_obj_t *content_container; void ui_content_init(void) { lv_obj_t *scr lv_scr_act(); content_container lv_obj_create(scr); lv_obj_set_size(content_container, 480, 220); lv_obj_align(content_container, LV_ALIGN_BOTTOM_MID, 0, 0); } void show_menu_page(uint8_t page_id) { lv_obj_clean(content_container); // 关键先清掉旧内容 if (page_id 0) { create_menu_buttons(content_container); // 在容器里创建按钮 } else if (page_id 1) { create_about_content(content_container); } }这种方案最大的优势是内存占用极低。因为同一时刻内容区只有一份控件对象存在。你从菜单A切到菜单B菜单A的对象已经全部释放内存池重新回收了那一块区域新的控件直接复用这块内存。代价是什么呢第一切页的时候有短暂的重建时间如果页面控件非常多超过30个肉眼可见地顿一下。第二你得自己管理好所有的事件回调、动画、定时器切页清理的时候不能漏否则这些资源没被释放内存还是会被一点一点吃掉。我实际用这个方案做了一个8页的菜单系统内存占用比方案B降低了大概30%。所以如果你的产品是那种菜单嵌套很深、每层页面外观相似、RAM又刚好卡在临界点方案C就是最优解。2.4 三种方案怎么选给一个可直接套用的判断标准我在给团队评审代码的时候一般直接用这个标准来判断页面数量小于等于3且RAM足够方案A。省事代码最不容易出bug。页面数量3~8页面之间是平级关系、内容差异大方案B。动态加载内存可控。页面数量8个以上且很多页面共享同一套骨架方案C。复用容器内存节省最明显。切换必须带流畅动画且动画过程不能消耗过多RAM方案B配短时长动画100~200ms同时把动画路径设为线性。每个页面都有大量相同控件如大量重复的按钮、标签必须用方案C或者结合模板复用否则RAM无解。另外三种方案并不是互斥的。工程里完全可以混用主界面和设置页这种重量级页面用方案B菜单的二级子页面用方案C。我最后做出来的HMI项目就是这种混合结构的。说到底方案是死的RAM是有限的满足需求的前提下只要能省内存怎么组合都合理。3. 内存优化实操把每一字节都用在刀刃上3.1 先给LVGL算一笔内存账在STM32上跑LVGL你首先要对“我的芯片到底能装下多大的UI”有个准确预估。LVGL的内存消耗主要在三块第一块是LVGL的全局工作内存也就是lv_conf.h里LV_MEM_SIZE宏定义的大小。LVGL所有动态对象都从这里分配相当于LVGL自己的堆。第二块是显示缓冲区LVGL渲染UI时要一个显存buffer这个buffer得想办法从LV_MEM_SIZE之外分配通常是一个全局数组。第三块是字模、图片等静态资源如果以C数组形式编译进固件它们占用的是Flash而非RAM但如果你用lv_img_set_src加载图片时选择了解码到RAM的模式那就会额外消耗RAM。一个大概的参考值STM32F407192KB RAM跑LVGLLV_MEM_SIZE设到64KB是比较健康的水平。如果你用的芯片只有32KB RAM那LV_MEM_SIZE最多分到16KB这种情况下UI必须极简控件数量要控制在20个以内。这不是吓唬人是实际经验。RAM计算的经验公式我一般这么用单个控件平均消耗 250 ~ 500字节含对象结构体 基础样式 事件如果页面上有图片、图表、弧线表这类重度控件单个可以吃到1KB以上。页面所有控件加起来就是这一次页面所需的大致RAM。你需要确保同时存在的页面/容器里控件总量消耗不超过LV_MEM_SIZE的三分之二剩下三分之一留给临时分配比如动画备份、弹窗、字符串缓冲区。3.2 lv_conf.h里的关键配置每项都直接决定生死lv_conf.h是整个LVGL工程的命门它的配置直接影响内存表现。我挨个说重要的。LV_MEM_SIZE这是LVGL内部内存池大小。不要设得过大也不需要过小。设大了你会觉得“反正内存够”于是写代码就不克制设小了UI一复杂直接分配失败系统卡死。建议先用保守值跑通功能然后用lv_mem_monitor观察实际峰值再反向调整到最合适的值。这个习惯建议每个项目都保持。LV_MEM_CUSTOM这个宏决定LVGL是使用内置的内存管理器0还是使用C库的malloc/free1。在STM32上我建议保持默认的0也就是内置管理器。LVGL自带的分配器对碎片处理更好而且允许你精确控制内存池大小不依赖C库。LV_USE_LOG开启LVGL日志。建议在开发阶段设为1方便定位内存分配失败的具体位置。max_level设为LV_LOG_LEVEL_WARN足够err级别太少info级别太吵。显示buffer的设置是内存优化里最大的一块肉。LVGL的显示缓冲支持三种模式一块bufferLV_DISP_RENDER_MODE_PARTIAL、两块buffer交替LV_DISP_RENDER_MODE_DOUBLE、一块全屏bufferLV_DISP_RENDER_MODE_FULL。在STM32上全屏buffer代价太高不推荐。我一般用两段式双缓冲Buffer大小按屏幕宽的一行来计算#define MY_DISP_HOR_RES 480 #define MY_DISP_BUF_SIZE (MY_DISP_HOR_RES * 40) // 高度取40行其实就是分块渲染 static lv_disp_draw_buf_t draw_buf; static lv_color_t buf_1[MY_DISP_BUF_SIZE]; static lv_color_t buf_2[MY_DISP_BUF_SIZE];这里有两个考点。第一两段buffer不是“为了流畅”而是为了解决撕裂和DMA传输问题CPU在渲染buffer1的时候DMA可以把buffer2的内容送去屏幕两不耽误。第二如果你开启了颜色深度16bitLV_COLOR_DEPTH 16那lv_color_t是2字节480乘40行一个buffer就是480×40×2等于38400字节约37.5KB两个buffer加起来75KB。这就是为什么很多低端芯片跑不动480分辨率RAM全被显存吃掉了。变通的办法是降低分辨率或者把高度值从40降到20牺牲一点渲染效率换内存。字模也是内存大户。lv_conf.h里默认会启用LV_FONT_MONTSERRAT_14和LV_FONT_MONTSERRAT_16等几个默认字体。如果你用不到全部关掉只保留1~2个需要的。自定义大字体比如24号、32号中文字体不是“加载”进RAM的而是在编译时就转为C数组存在Flash里使用时不占RAM但会在运行时被读取并暂存到LVGL的字体缓存。如果你发现UI跑着跑着字体突然变成方框很可能就是字体缓存不够用此时可以调大LV_FONT_CACHE_DEFER_INIT或者相关缓存配置。3.3 对象复用、图片瘦身这些习惯要刻进肌肉记忆很多内存问题其实不是LVGL的锅而是写代码的人太“大方”。我见过一个工程每秒钟刷新一次时间显示代码是这样写的每次刷新都new一个lv_label然后删掉旧的。跑了半小时内存就爆了。正确做法是初始化时把label建好之后只调用lv_label_set_text去改文本。这是状态刷新和页面切换里最核心的习惯之一能复用的对象绝不多建。再说图片。LVGL加载图片有两种方式一种是把图片转成C数组编译进固件另一种是文件系统读取。在STM32上99%的场景都是第一种。图片转C数组时有一个关键参数是颜色格式。如果你的屏幕是RGB565图片最好也转成RGB565不要用RGB888否则显示接口会做格式转换占用额外内存和时间。一张480×272的全屏图RGB565格式是480×272×2等于261120字节约255KB。这种大图在多数MCU上都是奢侈的要么降低图片尺寸要么拆成小图块要么干脆用纯色和简单图形组合。对于页面切换里的图片还有一个小技巧在页面切换动画结束之后立刻把旧页面的图片缓存释放。LVGL的图片默认有缓存机制在动画期间会保留旧屏的截图。如果你确认动画结束后不会再回到旧页面用lv_img_cache_invalidate_src主动让缓存失效能快速释放内存。3.4 用监控函数掌握内存实时动态LVGL提供了一个非常好用的内存监控APIlv_mem_monitor。把它的结果通过串口打印出来就能看到内存池总大小、空闲大小、碎片率、已分配块数等数据。你不需要猜内存够不够直接看数据说话。void debug_print_mem_info(void) { lv_mem_monitor_t mon; lv_mem_monitor(mon); printf(total: %u, free: %u, used: %u, frag: %u%%\n, (unsigned int)mon.total_size, (unsigned int)mon.free_size, (unsigned int)mon.total_size - mon.free_size, (unsigned int)mon.frag_pct); }我一般会在每次页面切换完成后都调一次这个函数把内存信息打到串口。如果发现free_size在反复切换页面后不断下降说明有内存泄漏需要去查是不是有定时器、动画、事件回调没清理干净。这个方法帮我抓出过很多隐蔽的内存泄漏强烈建议保留在你自己的调试工具集里。4. 关键代码实操把三种方案跑在STM32上4.1 搭建一个可复用的UI初始化骨架在STM32上跑LVGL初始化是有固定套路的。不管你用方案A还是方案C下面这套骨架都通用void lvgl_init_hardware(void) { lv_init(); // 显示缓冲初始化 lv_disp_draw_buf_init(draw_buf, buf_1, buf_2, MY_DISP_BUF_SIZE); // 显示器驱动注册 static lv_disp_drv_t disp_drv; lv_disp_drv_init(disp_drv); disp_drv.hor_res 480; disp_drv.ver_res 272; disp_drv.flush_cb my_disp_flush_cb; disp_drv.draw_buf draw_buf; lv_disp_drv_register(disp_drv); // 触摸屏驱动注册如果有 static lv_indev_drv_t indev_drv; lv_indev_drv_init(indev_drv); indev_drv.type LV_INDEV_TYPE_POINTER; indev_drv.read_cb my_touchpad_read_cb; lv_indev_drv_register(indev_drv); }这里my_disp_flush_cb是你自己的LCD刷屏函数负责把LVGL渲染好的buffer数据写到屏幕。常见的写法是使用DMA把LVGL传入的buffer复制到LCD控制器的GRAM里。void my_disp_flush_cb(lv_disp_drv_t *drv, const lv_area_t *area, lv_color_t *color_p) { uint32_t w lv_area_get_width(area); uint32_t h lv_area_get_height(area); LCD_SetWindow(area-x1, area-y1, area-x2, area-y2); LCD_WriteDataDMA((uint16_t *)color_p, w * h); // 必须在DMA传输完成后调用 lv_disp_flush_ready(drv); }注意最后一个lv_disp_flush_ready一定要等DMA传完了再调不然LVGL会认为数据已经刷完提前把buffer交给渲染器继续往里面画导致画面出现撕裂或者残影。4.2 方案A代码隐藏/显示的具体实现方案A的核心是一个页面管理器结构体。用数组保存页面指针用索引作为切页参数。#define PAGE_COUNT 3 static lv_obj_t *page_list[PAGE_COUNT]; static uint8_t current_page_index 0; void page_register(uint8_t index, lv_obj_t *page) { page_list[index] page; lv_obj_add_flag(page, LV_OBJ_FLAG_HIDDEN); } void page_init(void) { // 创建三个页面并全部注册 page_register(0, create_main_page()); page_register(1, create_setting_page()); page_register(2, create_about_page()); // 显示默认页 lv_obj_clear_flag(page_list[0], LV_OBJ_FLAG_HIDDEN); } void page_switch_to(uint8_t index) { if (index PAGE_COUNT || index current_page_index) return; lv_obj_add_flag(page_list[current_page_index], LV_OBJ_FLAG_HIDDEN); lv_obj_clear_flag(page_list[index], LV_OBJ_FLAG_HIDDEN); current_page_index index; }这段代码的精髓在于用数组抽象了“页面”这个概念之后不管是按键触发还是触摸事件只需调用page_switch_to(page_index)就行了页面管理逻辑和具体UI解耦。4.3 方案B代码带动画的屏幕切换实现方案B在切换时用lv_scr_load_anim其中要注意动画方向和持续时间的参数匹配。我习惯写一个独立的切换函数便于全局统一管理void screen_switch(lv_obj_t *target_scr, lv_scr_load_anim_t anim_type) { lv_scr_load_anim(target_scr, anim_type, 300, 0, false); } // 使用示例点击某个按钮切入设置页面 void setting_btn_event_cb(lv_event_t *e) { lv_event_code_t code lv_event_get_code(e); if (code LV_EVENT_CLICKED) { screen_switch(scr_setting, LV_SCR_LOAD_ANIM_MOVE_LEFT); } }关于auto_del参数我再强调一遍如果你这个screen本身是常驻页面必须传false。如果这个screen是一次性的临时页面比如一个弹出的提醒页传true可以让它在动画结束后自动销毁省去手动释放的步骤。还要注意动画期间LVGL的时间片来自lv_tick_inc。在STM32上用定时器每1ms调用一次lv_tick_inc(1)动画的计时才准确否则动画忽快忽慢甚至在低优先级任务里被卡住。4.4 方案C代码复用容器的动态内容区实现方案C适合内容区结构相似的多页菜单。我在工程里写了一个小框架typedef struct { uint8_t page_id; void (*create_cb)(lv_obj_t *parent); } menu_page_t; static const menu_page_t menu_pages[] { {0, menu_page_main_create}, {1, menu_page_status_create}, {2, menu_page_config_create}, }; void menu_show_page(uint8_t page_id) { if (page_id sizeof(menu_pages) / sizeof(menu_pages[0])) return; lv_obj_clean(content_container); // 调用对应页面的创建函数往公共容器里添加控件 menu_pages[page_id].create_cb(content_container); }每个子页面的create_cb只负责“在当前父容器下创建自己的控件”不关心其他页面。切页时一个lv_obj_clean把旧的清掉再创建新的内存自动复用。这种结构写起来思路清晰也方便后续扩展新页面加一个数组项写一个create函数就行不用改动切换逻辑。有一点要特别叮嘱在创建控件时尽量不要给父容器加LV_OBJ_FLAG_SCROLLABLE以外的“持久化”属性。因为容器里的子控件每次都会被清掉重建如果你在某个子控件上挂了一个lv_timer或者lv_anim一定要在它被清除前主动删除否则这些timer/anim对象依然存在指向已释放的内存轻则内存泄漏重则直接崩溃。安全起见可以把所有需要清理的timer在create函数的末尾用一个全局列表保存在lv_obj_clean之前统一删除。4.5 和FreeRTOS配合时的几个细节很多STM32工程是跑FreeRTOS的LVGL只是其中一个任务。这里有几个坑我一个个说清楚。第一lv_tick_inc必须可靠。LVGL的时基不依赖时钟中断而是靠代码里主动调用lv_tick_inc。在FreeRTOS里我建议在SysTick中断里调用或者用一个1ms周期的高优先级定时器中断调用。不要把它放在LVGL任务里去调因为任务调度有延迟会导致动画时间不准确。第二lv_task_handler只能在一个任务里跑。LVGL不是线程安全的不能在两个任务里同时调用lv_task_handler。一般做法是单独建一个LVGL任务优先级中等比关键控制任务低比后台任务高周期设置成5ms或者10ms调用一次lv_task_handler。如果你有两个地方都在调内存池会被两个线程同时访问跑一会必崩。第三如果你使用双缓冲和DMA刷屏要留意DMA和CPU访问同一块内存的问题。在带Cache的芯片上比如STM32H7刷屏前要做Cache clean操作刷完做Cache invalidate否则屏幕会出现花屏或者颜色错乱。F1/F4没有Cache不用管这个但如果从F4移植到H7这一步忘了屏幕绝对花而且很难排查。5. 切换卡顿、白屏、崩溃问题排查技巧实录5.1 切页卡顿先分清是重建慢还是渲染慢很多人一遇到切页卡顿就怀疑LVGL动画参数不对。其实卡顿一般分两种。第一种是控件创建慢。当你用方案C页面里控件特别多比如一个图表几十个数据点每次lv_obj_clean再重建重建的CPU开销不容忽视。这种情况的卡顿点是“切过去之后界面慢慢出来”不属于动画卡属于创建卡。解决思路是减少控件数量或者把部分静态UI放到容器外常驻只重建数据部分。第二种是渲染慢。卡顿表现为动画过程中画面掉帧、拖动不跟手。这种通常是显示缓冲太小或者刷屏DMA没配好。LVGL的partial渲染模式本来就是一帧分多块刷新的buffer越小刷新的块数越多动画就越容易掉帧。如果你把显示buffer的高度设置成10行那动画效果基本没法看。我的建议是把高度调到40行以上至少覆盖屏幕高度的15%。5.2 切页后白屏先检查screen的父对象白屏或者黑屏90%的情况是screen的父对象设置错了。比如你在创建scr_setting时错误地写了lv_obj_create(lv_scr_act())那这个scr_setting根本不是screen只是当前屏幕上的一个普通子对象。你切到它的时候只是在一个大的暗色背景上显示了一个子区域看起来就像半黑屏。排查方法很简单把代码里所有创建screen的地方找出来确认父对象是NULL。如果创建的是page容器方案A父对象才是lv_scr_act()这两种概念不能混淆。还有一种白屏是显示缓冲不匹配导致的。当你屏幕分辨率设置是480×272但LVGL的hor_res和ver_res没改默认可能还是240×320渲染出来的画面尺寸不对看起来就像只画了屏幕的一小块。5.3 连续切换后内存泄漏用串口抓出来反复切换页面几次后系统越来越卡最后死机。这是最典型的LVGL内存泄漏场景。原因无外乎几个定时器没删、动画回调没清理、子控件没被正确释放、事件回调里new了对象没释放。我的排查流程是固定一套先在每次切页后调用lv_mem_monitor并打印free_size。如果free_size在反复切换后持续下降且不回升就基本确定泄漏。然后用二分法先注释掉一半代码继续切页看free_size是否还下降反复缩小范围直到锁定泄漏的那段代码。这个方法看起来笨但在嵌入式调试里是最行之有效的方法。你甚至可以自己写一个简易的内存标记函数每次切页前记录当前free_size切页后打印差值差值如果是递增的正数就是泄漏无疑。5.4 常见问题速查表问题现象常见原因处理办法切页后白屏screen父对象不是NULL分辨率配置不对检查lv_obj_create(NULL)核对disp_drv的hor_res/ver_res动画卡成PPT显示buffer高度太小动画时长过长增大buffer高度把300ms改到150~200ms反复切页后死机对象或timer泄漏加lv_mem_monitor打印逐段注释定位泄漏切页后点击无反应事件回调注册到了旧screen上新screen没有indev支持检查事件注册对象确认indev驱动注册成功页面重叠显示方案A的父对象都是lv_scr_act()且没有正确隐藏检查HIDDEN标志位确认页面切换时隐藏逻辑正常执行切页后DMA刷屏残留旧画面没有在flush里正确清除屏幕残留buffer在flush_cb里对area之外区域补刷一次背景色检查flush_ready调用时机中文字体变方框字体文件不包含当前字符的glyph字体缓存太小换用包含中文的子集字库增大字体缓存配置另外还有一个容易让人崩溃的问题在动画切换瞬间按下了触摸按键导致正在动画中的页面状态异常。这种问题一般建议在动画期间禁用输入设备或者用一个互斥变量表示“正在切页暂不响应触摸”动画结束后再恢复。这个处理在很多LVGL工程里都被忽略但实际产品里很容易被用户碰到。最后再分享一点个人体会LVGL的页面切换写多了你会发现真正难的从来不是API怎么调用而是你对内存和生命周期的理解程度。方案A、B、C本质上是对“控件创建和销毁时机”的不同安排不存在哪一个绝对最好只有哪一个最适合你这个产品、这块芯片、这批用户。我做过的项目里最终选定方案B为主局部嵌套方案C原因是产品UI既有平级的大板块跳转又有层级深的多级菜单混合使用让RAM从最初方案A的73%降到了58%界面切换还保留着动画用户体验没打折。调试过程中促成我做这些优化的就是那几行lv_mem_monitor打印——你有数据依据改方案才不慌。最后分享一个调试小技巧在工程里保留一个调试页面专门显示内存池信息。这个页面用方案C实现每次进去自动刷新一次内存信息。现场测试的时候随便怎么乱按界面切几百次之后打开这个页面看一眼内存还剩多少有没有泄漏一眼就出来了。这个小页面不占多少代码量但能帮你省出按周计算的排查时间。