1. 为什么STM32上做页面切换容易翻车：从一次卡死说起
先讲个真实的经历。之前做一个基于STM32H750的智能家居中控屏，界面大概五六个页面，用LVGL 8.3版本，跑在FreeRTOS上。前期在PC模拟器里调试一切正常，切页动画流畅得不行，结果一烧到板子上，跑个十几分钟，切页偶尔会直接卡死，有时候是黑屏，有时候是页面元素残缺不全，触摸还有反应但画面不动。当时第一反应是LVGL配置的问题，查了半天没头绪，后来用lv_mem_monitor一看，内存碎片化严重，可用堆从最初的48KB一路掉到只剩几KB，某些页面反复切换几次之后大块内存根本分配不出来，lv_obj_create返回NULL，UI逻辑直接崩了。
这个问题其实非常典型。STM32这类MCU和PC模拟器的最大差异就是内存资源。模拟器上你能随便new对象、删除对象，内存不够了操作系统帮你兜底，但单片机上LVGL默认用的是一块固定的静态内存池，分配和释放全靠自己管理。页面切换的本质就是不断创建控件、销毁控件，在这个过程中如果方案设计得不好，轻则内存碎片化，重则内存泄漏，最终表现出来的就是上述那些诡异现象。
所以这篇文章我想系统梳理一下LVGL页面切换的三种主流方案，把它们的原理、代码、适用场景、内存开销一次性讲清楚。文章里的代码基于LVGL 8.3版本，STM32侧用的是STM32F407和STM32H750两个典型平台，分别代表中低端和中高端资源规格，方便你对号入座。无论你是刚开始接触LVGL的初学者，还是已经在产品上踩过内存坑的开发者，这篇内容都能给你一些实际参考。
在开始之前，先明确一个概念：LVGL里所谓“页面切换”，本质上就是一组控件的显示/隐藏、创建/销毁，或者屏幕对象的加载与卸载。同一个目标可以由完全不同的技术路径达成，而不同路径对内存、CPU、代码复杂度和用户体验的影响截然不同。后面三个章节我会分别拆解。
2. 方案一：删除重建——最直接也最容易踩内存坑
2.1 基本思路与代码实现
删除重建是最容易理解的方式：每次切换页面时，把当前页面的所有控件删除，然后重新创建目标页面的所有控件。代码逻辑上像这样：
// 页面1的创建函数 void page1_create(lv_obj_t *parent) { lv_obj_t *btn = lv_btn_create(parent); lv_obj_set_pos(btn, 20, 30); lv_obj_set_size(btn, 120, 50); lv_obj_t *label = lv_label_create(btn); lv_label_set_text(label, "Page 1 Button"); } // 切换到页面2 void switch_to_page2(lv_obj_t *scr) { lv_obj_clean(scr); // 删除当前屏幕上的所有子控件 page2_create(scr); // 创建页面2的控件 }这里有两个关键函数需要区分：lv_obj_clean()只删除传入对象的子对象，lv_obj_del()删除对象本身及其所有子对象。如果你用lv_scr_act()获取当前活动屏幕，然后想清空它，用lv_obj_clean(lv_scr_act())是对的。
2.2 优势在哪里
这个方案最大的优点是逻辑简单、代码直观。每个页面是独立的创建函数，页面之间的数据耦合度低，写起来基本不用动脑子。对于只有两三个页面、每个页面控件数量在十几个以内的简单界面，这是一个完全够用的方案。
另一个隐藏优势是不常驻内存。页面切换完成之后，上一个页面的所有控件都被销毁了，它们占用的内存全部归还给LVGL的内存池。对于RAM非常紧张的芯片（比如STM32F103C8T6这种只有20KB RAM的），这可能是唯一可行的方案。
2.3 致命问题：内存碎片化
但恰恰是这个方案，最容易踩碎片化的坑。LVGL默认的内存管理方式是动态分配、按需释放，如果你反复创建和删除大小不一的控件，内存池里就会出现很多零散的小空闲块。新页面需要一个比较大的连续内存块时，明明总空闲内存充足，但就是分配不出来。用lv_mem_monitor()能看到这样的数据：
Size: 32768 bytes Used: 12000 bytes Free: 20768 bytes Fragmentation: 42%空闲内存还有20KB，但碎片率42%，如果页面创建需要一次性分配一块8KB的大块（比如加载一张全屏图片），很可能就分配失败了。
经验分享：在开发阶段，我会在切页函数里主动加一个检查：
lv_mem_monitor_t mon; lv_mem_monitor(&mon); if (mon.free_size < 4096) { LV_LOG_WARN("Low memory: free=%d, frag=%d%%", mon.free_size, mon.frag_pct); }这样在反复测试切页时，日志里能第一时间看出内存是否异常下降。别等到产品死机了再排查，那时候就晚了。
2.4 删除重建方案的改进版：预创建 + 隐藏
为了缓解碎片化问题，一个常见的改进思路是预创建所有页面，切换时只改可见性：
// 初始化时一次性创建三个页面 page1 = lv_obj_create(app_scr); page2 = lv_obj_create(app_scr); page3 = lv_obj_create(app_scr); // 切换页面的函数 void switch_page(lv_obj_t *target_page) { lv_obj_add_flag(page1, LV_OBJ_FLAG_HIDDEN); lv_obj_add_flag(page2, LV_OBJ_FLAG_HIDDEN); lv_obj_add_flag(page3, LV_OBJ_FLAG_HIDDEN); lv_obj_clear_flag(target_page, LV_OBJ_FLAG_HIDDEN); }这种方案从根本上避免了反复创建和删除，内存只在系统启动时分配一次，之后不再变化。代价是所有页面的内存常驻，内存占用会一直处于高位。如果页面数量多、控件复杂，RAM紧张的情况下一样很危险。我一般建议在RAM大于64KB的芯片上才考虑这种思路，而且页面间如果涉及大图片资源，还是要想办法精简。
3. 方案二：容器切换——用父子关系实现低成本页面管理
3.1 核心原理：lv_obj_set_parent的妙用
第二种方案是使用LVGL的容器嵌套机制。简单来说，就是预先创建好几个平级的容器页面（可以理解为“底板”），每个容器承载一个页面的所有内容。切换时把目标容器移到最顶层显示，其他容器隐藏或置于底层。
这里最关键的API是lv_obj_set_parent()。它的作用是把控件从一个父对象移动到另一个父对象下，移动到新父对象后，控件会自动出现在新容器的内容区域中。利用这个特性，可以实现一种非常灵活的页面方案：所有页面素材共享同一个显示区域，切换时只移动目标页面到这个区域，其他页面放到一个隐藏的“仓库”容器里。
// 仓库容器，所有非活动页面都放在这里 static lv_obj_t *page_store; // 显示区域容器 static lv_obj_t *page_display; void page_init(lv_obj_t *scr) { // 创建仓库和显示区 page_store = lv_obj_create(scr); lv_obj_set_size(page_store, 1, 1); lv_obj_add_flag(page_store, LV_OBJ_FLAG_HIDDEN); page_display = lv_obj_create(scr); lv_obj_set_size(page_display, 240, 320); lv_obj_align(page_display, LV_ALIGN_CENTER, 0, 0); // 创建三个页面，初始都放在仓库里 page1 = create_page1(page_store); page2 = create_page2(page_store); page3 = create_page3(page_store); // 启动时显示页面1 lv_obj_set_parent(page1, page_display); } void switch_page(lv_obj_t *target_page) { lv_obj_t *current = lv_obj_get_child(page_display, 0); if (current) { lv_obj_set_parent(current, page_store); } lv_obj_set_parent(target_page, page_display); }3.2 这个方案解决了什么问题
容器切换方案最大的价值在于规避了反复创建销毁带来的碎片化，同时比“全量隐藏”方案更省内存。因为它可以精确控制内存中驻留的页面数量——只保留当前页面在显示区，其他页面放进隐藏仓库。尤其适合那种“页面数量不多但每个页面控件很多”的场景，比如仪表盘、设置界面、数据展示页。
相比方案一的“预创建+隐藏”，容器切换的另一个优势是页面切换时不会触发LVGL的全局重绘。因为所有控件都还挂在对象树上，只是换了父容器，LVGL的脏矩形机制能更精准地定位需要重绘的区域，整体刷新开销小很多。在低主频的STM32F103上，如果页面切换需要全屏重绘，体感延迟会非常明显，而容器切换基本可以做到瞬时响应。
3.3 数据保持和细节问题
由于页面控件一直存活，页面内的状态（比如输入框内容、开关状态、滚动条位置）天然得到保留，这是方案一需要额外处理的问题。方案一里每次重建页面，控件状态全部归零，你得用全局变量或者静态变量手动保存再恢复，代码写起来相当啰嗦。
容器方案还有一个值得注意的点：控件移动后，原页面里使用绝对定位的坐标体系会失效。因为lv_obj_set_parent()改变的是控件的相对坐标系。如果你的页面控件用了lv_obj_align(btn, LV_ALIGN_CENTER, 0, 0)这种相对父容器的对齐方式，移动后需要重新对齐。我的习惯是在创建页面时就全部用相对对齐，而不是写死x=20, y=30这样的绝对坐标，这样移动父容器后布局不会乱。
这一点在团队协作时尤其重要，因为不同开发者的编码习惯差异很大，有人喜欢拖拽式的绝对坐标开发，切页时页面控件全乱，排查起来非常痛苦。
3.4 容器切换的边界和限制
必须承认，容器切换方案也不是没有缺点。它依赖一个唯一的显示容器，多个页面不能同时可见，如果需要实现“页面A边缘露出页面B的一部分”这种效果，这个方案就不太方便了。另外，如果页面本身是滚动视图（lv_roller、lv_list等），容器嵌套层级深了之后，滚动事件的传递偶尔会出现不灵敏的情况。这个跟LVGL的事件冒泡机制有关，页面层级越深，触摸事件命中检测链条越长，测试时要注意重点验证。
4. 方案三：屏幕级切换——最接近手机App体验的方案
4.1 用lv_scr_load实现真正的页面切换
第三种方案是屏幕级切换，这是LVGL官方力推的做法。它把每个页面做成一个独立的lv_obj屏幕对象，切换时直接加载新屏幕。核心API有两个：
// 非动画方式，瞬时切换 lv_scr_load(new_scr); // 带动画方式，切换过程有过渡效果 lv_scr_load_anim(new_scr, LV_SCR_LOAD_ANIM_MOVE_LEFT, 300, 0, false);lv_scr_load_anim的各个参数含义：第二个参数指定动画类型，LV_SCR_LOAD_ANIM_MOVE_LEFT表示新页面从右侧滑入、旧页面向左侧滑出；第三个参数是动画时长（毫秒）；第四个参数是延迟开始时间；第五个参数表示动画是否自动删除旧屏幕（true表示自动删除，false表示保留）。
// 创建两个屏幕 lv_obj_t *scr_main = lv_obj_create(NULL); lv_obj_t *scr_settings = lv_obj_create(NULL); // 在屏幕上添加控件 lv_obj_t *btn = lv_btn_create(scr_main); lv_obj_set_pos(btn, 10, 10); // 切换到设置页，带滑动动画 lv_scr_load_anim(scr_settings, LV_SCR_LOAD_ANIM_MOVE_LEFT, 300, 0, false);4.2 为什么它是“最佳体验”
屏幕级切换之所以在体验上最好，是因为LVGL的内核本身就针对屏幕切换做了优化。动画效果极其顺滑，页面滑动效果和手机上App切换几乎无差别。而且LVGL原生支持多种动画类型：左移右移、上下滑动、淡入淡出、圆形展开等，你只要换一个参数就能得到完全不同的过渡效果，代码量几乎为零。
更重要的一个特性是：屏幕级切换时，旧屏幕的销毁是异步的，由动画回调释放内存。这意味着动画播放期间新旧两个屏幕同时驻留内存，动画结束后旧屏幕才被清理。这个特性在视觉上很丝滑，但也在切换瞬间把内存需求推高一倍——这是很多人在低配芯片上采用此方案失败的根本原因。后面内存优化章节我会专门讲怎么应对。
4.3 配套的事件机制
屏幕级切换有一个隐性好处：它天然提供了页面生命周期回调。LVGL在屏幕加载时会发送LV_EVENT_SCREEN_LOADED事件，卸载时发送LV_EVENT_SCREEN_UNLOADED事件，你可以在这两个事件里做数据初始化、释放临时资源、暂停后台任务等操作：
void scr_settings_event_cb(lv_event_t *e) { lv_event_code_t code = lv_event_get_code(e); if (code == LV_EVENT_SCREEN_LOADED) { // 页面加载完成，初始化数据 settings_page_refresh(); } else if (code == LV_EVENT_SCREEN_UNLOADED) { // 页面被切走，释放临时资源 settings_page_cleanup(); } }这个机制在方案一和方案二里就得完全靠手动管理了，类似switch_page里自己调初始化函数、在每个页面里注册页面的退出回调。代码一旦多了之后，很容易漏掉某个页面的释放逻辑，这就是内存泄漏的源头。
4.4 什么情况下适合用屏幕级切换
方案三最适合的场景是页面本身是“全屏独立内容”，每个页面之间没有明显的父子包含关系，比如主界面、二级详情页、设置页。这类页面通常控件数量多，页面逻辑独立，需要动画过渡来提升用户体验。STM32F407以上主频168MHz，配有外部SRAM或者内部RAM超过128KB的情况下，屏幕级切换是完全可行的。
但如果你做的是那种“主界面 + 侧边栏 + 状态栏 + 弹窗”整体框架，就不适合把每个部分都做成独立屏幕，而是应该用方案二做区域切换，屏幕级只做最顶层的页面跳转。
5. 内存优化的核心方法论：把不必要的内存开销砍掉
5.1 精准定位内存分配问题
不管采用哪种方案，内存优化都是绕不开的话题。我强烈建议在开发阶段就启用LVGL自带的内存监控工具，在lv_conf.h中开启：
#define LV_MEM_CUSTOM 0 #define LV_MEM_SIZE (64U * 1024U) // 根据芯片实际情况配置 #define LV_MEM_MONITOR 1 // 开启内存监控 #define LV_MEM_STATS 1 // 开启动态分配统计启动后，可以在RTOS的任务里周期调用以下代码，把内存使用数据打印出来：
void memory_debug_task(void *param) { while (1) { lv_mem_monitor_t mon; lv_mem_monitor(&mon); printf("total=%d, free=%d, used=%d, frag=%d%%\n", mon.total_size, mon.free_size, mon.used_size, mon.frag_pct); vTaskDelay(pdMS_TO_TICKS(2000)); } }观察这几个数在页面切换前后的变化，你立刻就能定位问题：如果切换10次页面后free_size单调下降且不回升，说明有内存泄漏；如果free_size波动很大但frag_pct不断攀升，说明碎片化严重，就要考虑换方案。
5.2 局部变量和临时对象的处理
在嵌入式C代码里，一个容易被忽视的内存浪费点是在一个函数里临时创建LVGL对象。比如：
void update_status_bar(const char *text) { lv_obj_t *label = lv_label_create(status_bar); lv_label_set_text(label, text); lv_obj_align(label, LV_ALIGN_RIGHT, -10, 0); }每调用一次就创建一个新的标签控件，旧的没人管，慢慢就泄漏了。正确做法是把label声明为static，只创建一次，后续只更新文本：
void update_status_bar(const char *text) { static lv_obj_t *label = NULL; if (!label) { label = lv_label_create(status_bar); lv_obj_align(label, LV_ALIGN_RIGHT, -10, 0); } lv_label_set_text(label, text); }5.3 图片资源的处理策略
图片是内存开销的大头，尤其在STM32这种没有GPU、显存共享RAM的环境下。一张240x320的RGB565全屏图片，裸数据就占240*320*2 = 153600字节，也就是150KB。放在内部RAM里，H750的片上RAM也只剩一半了。这里分享几个实际有效的策略：
策略一：使用LVGL内置图片转换工具（LVGL Image Converter）把图片转成C数组，并按RGB565格式存储，而不是用PNG或JPEG解码。后者需要解码缓冲区，解码过程中内存占用非常恐怖。
策略二：使用LVGL的图片缓存机制。对于重复切换的页面背景，可以利用lv_img_set_src()配合LV_IMG_CACHE_DEF_SIZE，让图片数据被缓存复用，而不是每次加载时都重新解析。
策略三：如果图片带透明通道，优先使用LV_COLOR_FORMAT_ARGB8888之外的格式。例如LV_COLOR_FORMAT_RGB565A8，透明度单独用一张8位图，实际内存占用比ARGB8888少了整整一半。
我实际测试过一个案例：同样的界面背景图，ARGB8888格式占300KB内存，改成RGB565A8后只占150KB，视觉效果几乎没有差别。这个优化幅度是立竿见影的，强烈建议你审查项目里的每张大图资源。
5.4 FreeRTOS任务栈和LVGL堆的平衡
如果你在STM32上跑FreeRTOS + LVGL，内存还涉及另一个分配维度：任务栈。
LVGL的主循环可以在一个独立任务中运行：
void lvgl_task(void *param) { while (1) { lv_timer_handler(); vTaskDelay(pdMS_TO_TICKS(5)); // 5ms周期，约200Hz刷新率 } }这个任务栈大小默认给多大？我见过很多人在RTOS里无脑给2048字（8KB），其实LVGL内部大量的临时变量都在这个任务栈上分配。如果栈给太小，运行一段时间后会莫名其妙HardFault。根据我的测试经验，LVGL任务栈至少给4096字（16KB），如果页面复杂、有大量中文字体，建议给8192字（32KB）才稳妥。你要知道，任务栈大小直接影响lv_timer_handler()内部执行时的局部变量空间，而这个栈本身不占用LVGL内存池，所以该大方的时候别抠。
另外，LVGL的lv_tick_inc()心跳函数，建议放在一个高优先级定时器中断或者单独的低优先级任务里调用。如果放在和lv_timer_handler()同一个任务里交替执行，会导致动画计时不准、切页动画忽快忽慢。
5.5 字体和中文显示的内存策略
中文字体是另一个RAM杀手。LVGL默认的字体是ASCII编码，要显示中文必须加载中文字体。LVGL的字体本质上是用位图数组存储的，一个汉字在16x16点阵下需要32字节，如果你用24x24字体，单个汉字要72字节，一套常用3000个汉字就是216KB的Flash消耗，并且LVGL渲染时会把这部分位图加载到RAM中，内存压力很大。
我的做法是动态加载字体：只在需要显示文字的页面加载对应字体，页面切换后立刻释放。具体用lv_font_load()和lv_font_free()配合：
lv_font_t *my_font = lv_font_load("A:font_24.bin"); ... // 页面卸载时 lv_font_free(my_font);在方案三的屏幕级切换中，可以在LV_EVENT_SCREEN_UNLOADED事件里释放字体资源，这样内存就能在不同页面间动态复用。你的页面风格差异大（比如主界面用大号时间字体，设置页用小号列表字体），这个技巧特别管用。
6. 实测中的高发问题：一个完整的排查链路复现
6.1 症状：切页一段时间后界面卡住无响应
这个故障在方案一里非常常见。我当时的具体环境：STM32F407，FreeRTOS，LVGL 8.3，内存池48KB，页面3个，各页面控件约20个。测试流程是反复按按键切页，大约几百次之后界面卡死。
6.2 排查步骤一：先确认是LVGL卡死还是任务卡死
我用调试器的办法：暂停程序，查看当前PC指针停在哪个函数。发现停在lv_mem_alloc内部。这就说明问题的根源在内存分配——要么内存耗尽，要么碎片化导致无法分配大块连续内存。如果PC指针停在vTaskDelay或者空闲任务里，那大概率是任务调度问题，方向就不同了。
6.3 排查步骤二：用内存监控定位分配失败的具体点位
在LVGL源码里，lv_mem_alloc分配失败时会触发LV_LOG_ERROR日志。我开启了LV_LOG_LEVEL LV_LOG_LEVEL_WARN后，日志输出里有这样的记录：
lv_mem_alloc: Out of memory, requested size: 520, free: 1024这说明实际剩余内存还有1KB，但要分配520字节时还是失败了，因为连续的520字节块不存在了。这就是典型的碎片化问题。
6.4 排查步骤三：检查哪个控件的内存被反复分配不释放
在切页函数里，每切换一次就调用一次lv_mem_monitor()，记录每次切换前后的内存变化。我用一个全局变量追踪切换次数，并定期把数据输出到串口。结果发现每次从页面A切换到页面B时，内存减少约320字节，从页面B切回页面A时，内存并没有完全恢复。这说明页面A的创建或页面B的销毁逻辑中有对象漏删了。
逐行排查后发现问题出在我自己在页面B里创建了一个lv_chart，但没有把图表的数据系列（series）删除干净。LVGL的lv_chart和lv_table这类控件内部还有二级对象，不能仅靠lv_obj_del()删除根控件，必须逐个删除子对象或使用lv_obj_clean()清空内部，这算是LVGL控件使用的一个经典坑。
6.5 排查步骤四：换方案后对比数据
最后我把方案一改成方案三（屏幕级切换），并把低内存页面的历史数据不用常驻控件保存、改为本地静态数组。同样的切换循环测试跑了一万次，内存曲线平稳，再没有分配失败的情况。对比数据如下：
| 指标 | 方案一（删除重建） | 方案二（容器切换） | 方案三（屏幕级切换） |
|---|---|---|---|
| 代码复杂度 | 低 | 中 | 中 |
| 内存碎片风险 | 高 | 低 | 中 |
| 页面切换动画 | 需自绘 | 有限支持 | 原生支持 |
| 页面状态保持 | 需手动 | 自动 | 自动 |
| 适合芯片RAM | <64KB | 32~128KB | >64KB |
| 切换瞬间内存峰值 | 低 | 低 | 高（新旧屏幕并存） |
6.6 这类问题的“举一反三”
从这次排查里我总结出一个规律：凡是运行一段时间后“随机”出现的卡死、花屏、控件缺失，90%优先怀疑内存问题，不要先去查时序和外设。排查流程固定为：看一眼内存监控、关掉动画测试、替换控件类型、反复开关页面压测。这四个动作能定位绝大多数LVGL在MCU上的疑难杂症。
7. 选型决策：三个方案怎么选更合理
7.1 按芯片资源选型
内存资源是决定性因素。如果你用的是STM32F103C8T6这类RAM约20KB的芯片，方案一几乎是唯一选择，但建议用“预创建+隐藏”的改进版，因为纯删除重建的碎片化在这个资源级别基本撑不过长时间运行。
如果RAM在64KB上下，方案二（容器切换）是最稳的。它平衡了内存峰值、代码复杂度和功能灵活性。页面不超过5页，每页控件不超过30个，方案二能做到完全无感知切换。
如果RAM ≥ 128KB，或者你挂了外部SRAM/PSRAM（比如F407挂IS62WV51216），方案三放心用。动画体验最好，生命周期管理最清晰，代码也最贴近LVGL官方推荐用法。
7.2 按产品场景选型
如果是工业仪表类，界面变化少，交互简单，优先方案一（改进版），稳定压倒一切。如果是智能家居中控屏，页面多、动画要求高，方案三是首选，RAM不够就外挂PSRAM，别在内部RAM里硬撑。如果是手持设备，页面切换频繁且要省电，方案二最合理——容器切换不触发全局重绘，CPU占用低，自然更省电。
7.3 混用也是常见做法
实际产品中我经常把三种方案组合使用：底部导航栏本身是一个容器，常驻内存；点击不同Tab时用容器切换方案切换内容区；点击列表项进入详情页时用屏幕级切换方案加载新屏幕并带动画。这样各取所长，既保证操作流畅，又控制内存峰值。混用时的核心原则是：分清“页面框架”和“内容页面”两个层级。框架用容器方案，内容跳转用屏幕方案，这样代码结构也非常清晰。
7.4 附一个完整的最小代码骨架
这里给出一段基于STM32 + FreeRTOS + LVGL 8.3的屏幕级切换最小示例，你直接照着搭就能跑通：
// main.c 中初始化 LVGL 后 static lv_obj_t *scr_home; static lv_obj_t *scr_detail; void ui_init(void) { // 创建主屏幕 scr_home = lv_obj_create(NULL); lv_obj_t *btn = lv_btn_create(scr_home); lv_obj_set_size(btn, 120, 50); lv_obj_align(btn, LV_ALIGN_CENTER, 0, -40); lv_obj_add_event_cb(btn, home_btn_cb, LV_EVENT_CLICKED, NULL); lv_obj_t *lbl = lv_label_create(btn); lv_label_set_text(lbl, "Open Detail"); lv_obj_center(lbl); // 创建详情屏幕 scr_detail = lv_obj_create(NULL); lv_obj_t *back_btn = lv_btn_create(scr_detail); lv_obj_set_size(back_btn, 80, 40); lv_obj_align(back_btn, LV_ALIGN_BOTTOM_MID, 0, -20); lv_obj_add_event_cb(back_btn, back_btn_cb, LV_EVENT_CLICKED, NULL); lv_obj_t *back_lbl = lv_label_create(back_btn); lv_label_set_text(back_lbl, "Back"); lv_obj_center(back_lbl); lv_scr_load(scr_home); } void home_btn_cb(lv_event_t *e) { // 切换到详情页，带左滑动画 lv_scr_load_anim(scr_detail, LV_SCR_LOAD_ANIM_MOVE_LEFT, 300, 0, false); } void back_btn_cb(lv_event_t *e) { // 返回主页，带右滑动画 lv_scr_load_anim(scr_home, LV_SCR_LOAD_ANIM_MOVE_RIGHT, 300, 0, false); }这段代码跑通后，你可以在两个屏幕里分别添加更多控件，逐步扩展成完整的多页面应用。切换动画里的300是毫秒数，实际产品按调试手感调整，我一般控制在200~350ms之间，太短显得生硬，太长用户会觉得卡。
8. 结合FreeRTOS的几点额外建议
8.1 任务优先级不要忽高忽低
LVGL任务优先级建议设置在中低水平（比如FreeRTOS默认的tskIDLE_PRIORITY + 1或tskIDLE_PRIORITY + 2），不要设置成最高。因为LVGL的lv_timer_handler()内部会执行大量UI回调，如果优先级高于实时控制任务（比如电机控制、ADC采样），UI卡顿时会阻塞关键业务，这属于非常经典的RTOS任务设计问题。
8.2 在LVGL任务里不能阻塞
这个要反复强调：LVGL主循环里不能有任何阻塞性调用，包括HAL_Delay()、vTaskDelay()超过一个tick、fread()读SD卡等待等。否则整个UI直接冻结。如果页面有从SD卡读取图片这类耗时操作，一定要放到低优先级任务里，读取完成后通过消息队列或标志通知LVGL任务刷新页面。
8.3 动画期间的内存压力
方案三的两个问题叠加之下，如果你在动画切换期间还要加载图片资源，内存压力会很大。我的策略是：切页动画启动前，先主动释放目标页面不需要的资源；动画执行期间不加载重资源，延迟到LV_EVENT_SCREEN_LOADED事件里再加载。这样能有效避免动画中途因内存不足导致的卡顿。
9. 从模拟器到真机的最后一公里
很多人在PC模拟器上调好的UI一上STM32就出问题，原因往往不是LVGL本身，而是开发环境差异。
PC模拟器的LVGL默认内存管理走的是malloc，堆大小受系统限制但基本管够；STM32上LVGL默认走静态数组内存池，大小在lv_conf.h里配置。两者的内存特性完全不同，模拟器上30KB的动态内存随意分配毫无压力，到了STM32上同样操作就可能失败。
所以我强烈建议：从第一天就在STM32的真实硬件上开LVGL调内存，模拟器只用来快速验证布局和交互逻辑，内存优化和压力测试必须真机上做。移植LVGL时，直接把lv_conf.h里的LV_MEM_SIZE设为你芯片实际承受范围的一半作为起点。为啥是一半？因为你要留出运行时临时缓冲的余量，满了就得优化代码而不是堆大内存。
平时用Keil，头大LVGL移植配置的，也可以去LVGL官方下载中心找现成的STM32移植工程模板，比自己从零配置少踩很多坑。LVGL 9.x之后官方对底层驱动接口做了调整，如果你用经典屏幕驱动IC（ILI9341、ST7789），建议优先选LVGL 8.3 LTS版本，社区资料最多，遇到问题搜答案也最快。9.x版本虽然新增了更多特性，但在STM32这类小资源平台上，稳定性未必比8.3更好。
写到这里，页面切换的三种主流方案、内存优化的核心手段、实际排查过程，基本都说透了。如果你正在做一个基于STM32的LVGL项目，我的最终建议是：先在真机上跑通方案三的最小例子，然后开启内存监控反复切换压测，用数据说话决定最终选型。不要凭感觉选方案，更不要盲目追新版本，扎实的内存数据比任何理论推演都可靠。
