ESP32 PSRAM优化LVGL显示性能：解决内存不足与卡顿问题

1. 项目概述：当LVGL遇上ESP32的PSRAM

如果你正在用ESP32玩LVGL，并且界面稍微复杂一点就感觉卡顿，或者总提示内存不足，那你大概率是遇到了ESP32内部RAM的瓶颈。ESP32的片上SRAM，对于简单的逻辑控制绰绰有余，但一旦跑起LVGL这种图形库，要加载图片、使用大字体、创建多个复杂控件时，那几百KB的内存就显得捉襟见肘了。这时候，ESP32系列芯片（尤其是ESP32-S3、ESP32-C3某些型号以及带PSRAM的ESP32）外挂的那块SPI PSRAM就成了救命稻草。它通常有4MB或8MB，虽然速度比不上内部RAM，但容量是碾压级的。这个项目的核心，就是教你如何把LVGL的显示缓冲区、图片解码缓存这些“内存大户”，从紧张的内部RAM搬到宽敞的PSRAM里，从而让ESP32能够流畅运行更华丽的UI界面。

我最初在做一个智能家居中控屏项目时，界面用了不少图标和自定义字体，编译时内存占用直接爆红。尝试使用PSRAM后，不仅编译通过了，滑动列表、切换页面的流畅度也有了肉眼可见的提升。这不仅仅是“能用”和“不能用”的区别，更是“卡顿”和“流畅”的体验分水岭。无论你是做穿戴设备、工业HMI还是智能家居面板，只要你的ESP32项目带有PSRAM，并且UI有一定复杂度，掌握这套优化方法都是必经之路。

2. 核心原理：为什么PSRAM能优化LVGL显示

要理解如何优化，首先得明白LVGL在ESP32上运行时，哪些部分最吃内存。LVGL作为一个轻量级图形库，其内存消耗主要来自几个方面：显示缓冲区（Frame Buffer）、样式对象、控件对象本身、以及图片、字体等资源数据。其中，显示缓冲区是绝对的“内存消耗之王”。

2.1 显示缓冲区的内存压力

LVGL的渲染基于一个或多个显示缓冲区。最常见的配置是使用两个缓冲区（双缓冲）：一个用于LCD控制器刷新（通常通过SPI或I2C DMA发送），另一个用于LVGL准备下一帧的图形数据。每个缓冲区的大小取决于你的屏幕分辨率、颜色深度和缓冲策略。

举个例子，如果你的屏幕是320x240（QVGA），颜色深度为16位色（RGB565），那么一帧图像的像素数据量就是 320 * 240 * 2 bytes = 153,600 字节，约150KB。如果使用双缓冲，就需要至少300KB的连续RAM空间。而ESP32常见的片上SRAM（以ESP32-WROOM-32为例）总共也就约520KB，其中一部分还要被系统、Wi-Fi/蓝牙栈、你的应用程序代码和数据占用。直接划出300KB连续内存给显示缓冲区非常困难，甚至会导致内存碎片化，系统不稳定。

2.2 PSRAM的角色与性能权衡

PSRAM（Pseudo Static RAM）通过SPI接口与ESP32主芯片连接。它的优势是容量大、成本低，但缺点是访问速度比内部SRAM慢，且通常不支持像内部RAM那样的高速缓存（Cache）机制。因此，我们不能简单地把所有数据都扔进PSRAM。

优化的核心思路是：将体积庞大但对访问延迟相对不敏感的数据放在PSRAM，而将需要频繁、快速访问的小型数据结构和代码留在内部SRAM。

对于LVGL而言：

  • 适合放在PSRAM的：显示缓冲区、已解码的图片缓存、大型字体位图数据。这些数据块大，且访问模式相对可预测（如顺序填充缓冲区）。
  • 必须留在内部SRAM的：LVGL的核心对象（如lv_disp_t,lv_indev_t）、控件结构体、样式对象、事件回调函数、以及频繁调用的驱动函数（如flush_cb中的像素处理循环）。这些需要极低的访问延迟。

Arduino核心和LVGL库已经为我们做好了底层支持。ESP32的Arduino核心提供了ps_malloc()、ps_calloc()等函数，用于在PSRAM中分配内存。而LVGL库则允许我们在初始化显示驱动时，自定义分配显示缓冲区内存的函数。我们的工作，就是正确地连接这两者。

3. 环境准备与基础配置

在开始代码编写前，确保你的开发环境和支持库都已就绪。这一步的疏忽会导致后续各种编译错误和运行时异常。

3.1 硬件与软件清单

  • 硬件：一块带有PSRAM的ESP32开发板。常见的有ESP32-S3-DevKitC-1（带8MB PSRAM）、ESP32-WROVER系列（板载4MB PSRAM）或ESP32-CAM（带PSRAM版本）。请务必确认你的板子型号支持PSRAM。
  • 开发环境：Arduino IDE 2.x 或 VSCode with PlatformIO。我个人更推荐PlatformIO，它在库管理和项目配置上更灵活。
  • 必需库：
    1. LVGL库：在Arduino库管理中搜索“lvgl”并安装。建议安装最新稳定版（如lvgl v8.x或v9.x）。
    2. 显示驱动库：根据你的屏幕接口选择。例如，对于SPI接口的ILI9341屏幕，你需要对应的驱动库（如TFT_eSPI或lvgl_esp32_drivers中的相关组件）。本示例以通用的自定义驱动为例，原理相通。
  • 关键配置（Arduino IDE）：在工具菜单中，选择你的ESP32板型后，确保“PSRAM”选项设置为“Enabled”。在PlatformIO中，这通常在platformio.ini文件里通过board_build.psram配置项启用。

3.2 验证PSRAM是否可用

在开始复杂的LVGL配置前，先写一个简单的测试程序，确认PSRAM能被正确识别和使用。这能避免后续问题定位时绕弯路。

#include <esp_heap_caps.h> void setup() { Serial.begin(115200); delay(1000); // 检查PSRAM是否可用 if (psramFound()) { Serial.println("PSRAM is available."); // 获取PSRAM总大小 Serial.printf("Total PSRAM: %d bytes\n", ESP.getPsramSize()); // 获取当前PSRAM空闲大小 Serial.printf("Free PSRAM: %d bytes\n", ESP.getFreePsram()); } else { Serial.println("No PSRAM found! Please check board selection and PSRAM setting."); while(1); // 停在此处 } // 尝试在PSRAM中分配内存 size_t size_to_alloc = 1024 * 300; // 尝试分配300KB，模拟显示缓冲区 uint8_t* buffer = (uint8_t*)ps_malloc(size_to_alloc); if (buffer == NULL) { Serial.println("Failed to allocate memory in PSRAM!"); } else { Serial.printf("Successfully allocated %d bytes in PSRAM at address: 0x%p\n", size_to_alloc, buffer); // 简单读写测试 buffer[0] = 0xAA; if (buffer[0] == 0xAA) { Serial.println("PSRAM read/write test PASSED."); } else { Serial.println("PSRAM read/write test FAILED!"); } free(buffer); // 释放内存 } } void loop() { // 空循环 }

将这段代码上传到你的开发板，打开串口监视器。如果看到“PSRAM is available”和分配成功的消息，说明硬件和基础环境配置正确。如果提示未找到PSRAM，请返回检查开发板选型和PSRAM启用设置。

4. 将LVGL显示缓冲区分配至PSRAM

这是最核心、效果最显著的一步。我们将替换LVGL默认的内部RAM分配，改为使用PSRAM来创建显示缓冲区。

4.1 理解LVGL显示驱动初始化

LVGL初始化显示设备时，需要提供一个lv_disp_draw_buf_t结构体，这个结构体内部包含了指向一个或多个显示缓冲区的指针。通常，我们调用lv_disp_draw_buf_init()函数，并传入在内部RAM中定义的数组作为缓冲区。现在，我们要动态地在PSRAM中分配这个缓冲区。

4.2 实现PSRAM分配的显示缓冲区

下面是一个完整的示例，展示了如何初始化一个使用双缓冲（位于PSRAM中）的LVGL显示驱动。

#include <lvgl.h> #include <TFT_eSPI.h> // 假设使用TFT_eSPI库驱动屏幕，你需要根据实际情况调整 TFT_eSPI tft = TFT_eSPI(); // 屏幕对象 // 定义屏幕分辨率 #define SCREEN_WIDTH 320 #define SCREEN_HEIGHT 240 // 定义颜色深度（LVGL_COLOR_DEPTH 16 对应 RGB565） #define LV_COLOR_DEPTH 16 // 声明显示缓冲区的指针，我们将动态分配 static lv_color_t* buf1 = NULL; static lv_color_t* buf2 = NULL; static lv_disp_draw_buf_t draw_buf; static lv_disp_drv_t disp_drv; // 自定义的Flush回调函数，将LVGL绘制好的区域发送到屏幕 void my_disp_flush(lv_disp_drv_t* disp, const lv_area_t* area, lv_color_t* color_p) { uint32_t w = (area->x2 - area->x1 + 1); uint32_t h = (area->y2 - area->y1 + 1); tft.startWrite(); tft.setAddrWindow(area->x1, area->y1, w, h); // 使用pushPixelsDMA或pushPixels以提高速度（如果驱动支持） tft.pushPixels((uint16_t*)color_p, w * h, /* use_dma */ true); tft.endWrite(); // 告知LVGL刷新完成 lv_disp_flush_ready(disp); } void setup() { Serial.begin(115200); // 初始化屏幕硬件 tft.begin(); tft.setRotation(1); // 根据你的屏幕方向调整 lv_init(); // 初始化LVGL库 // --- 关键步骤1：在PSRAM中分配显示缓冲区 --- size_t buf_size = SCREEN_WIDTH * 20; // 每个缓冲区的大小。这里示例为20行高。 // 使用ps_calloc，它会自动将内存分配在PSRAM（如果可用） buf1 = (lv_color_t*)ps_calloc(buf_size, sizeof(lv_color_t)); buf2 = (lv_color_t*)ps_calloc(buf_size, sizeof(lv_color_t)); if (buf1 == NULL || buf2 == NULL) { Serial.println("Failed to allocate display buffers in PSRAM! Check PSRAM size."); while (1); // 分配失败，停止执行 } Serial.printf("Display buffers allocated in PSRAM. Buf1: 0x%p, Buf2: 0x%p\n", buf1, buf2); // --- 关键步骤2：用PSRAM中的缓冲区初始化LVGL绘制缓冲区 --- lv_disp_draw_buf_init(&draw_buf, buf1, buf2, buf_size); // --- 关键步骤3：初始化并注册显示驱动 --- lv_disp_drv_init(&disp_drv); disp_drv.hor_res = SCREEN_WIDTH; disp_drv.ver_res = SCREEN_HEIGHT; disp_drv.flush_cb = my_disp_flush; // 设置刷新回调 disp_drv.draw_buf = &draw_buf; // 关联我们创建的PSRAM缓冲区 disp_drv.full_refresh = 0; // 通常设为0，使用局部刷新 // 可以设置旋转（如果需要） // disp_drv.sw_rotate = 1; // disp_drv.rotated = LV_DISP_ROT_90; lv_disp_t* disp = lv_disp_drv_register(&disp_drv); // 后续可以创建你的UI了 create_ui(); } void loop() { lv_timer_handler(); // 调用LVGL任务处理器 delay(5); } void create_ui() { // 在这里创建你的LVGL UI对象 lv_obj_t* label = lv_label_create(lv_scr_act()); lv_label_set_text(label, "Hello from PSRAM!"); lv_obj_align(label, LV_ALIGN_CENTER, 0, 0); }

代码解析与注意事项：

  1. 缓冲区大小选择：示例中buf_size = SCREEN_WIDTH * 20，意味着每个缓冲区能存储20行屏幕数据。这是一个“部分缓冲”策略。LVGL会轮流使用这两个缓冲区进行绘制和刷新。增大这个值（如设为SCREEN_WIDTH * SCREEN_HEIGHT / 10）可以减少LVGL重绘的频率，但会占用更多PSRAM。你需要根据可用PSRAM大小和性能需求权衡。对于320x240的屏幕，双缓冲各20行大约占用 320202*2 ≈ 25KB，这对PSRAM来说微不足道。
  2. ps_callocvsmalloc：使用ps_calloc而不是ps_malloc，因为calloc会将分配的内存初始化为0，可以避免显示缓冲区出现随机噪点。
  3. 错误处理：务必检查ps_calloc的返回值是否为NULL。分配失败可能意味着PSRAM未启用或空间不足。
  4. Flush回调优化：在my_disp_flush函数中，我使用了pushPixels并建议启用DMA（如果驱动支持）。这是一个重要的性能技巧。因为数据现在位于PSRAM，通过SPI总线传输到屏幕本身就有延迟。使用DMA可以解放CPU，让它在LVGL准备下一帧数据的同时，由DMA控制器在后台完成PSRAM到屏幕的数据搬运，极大提升整体流畅度。请查阅你的具体屏幕驱动库文档，确认如何启用DMA传输。

5. 优化图片与字体资源内存占用

解决了显示缓冲区，接下来处理UI中常见的“内存杀手”——图片和字体。未经处理的图片和字体会被加载到内部RAM，迅速耗尽空间。

5.1 将图片数据放入PSRAM

LVGL支持多种图片源，对于存储在Flash（如SPIFFS、LittleFS）中的图片文件，解码后的位图可以缓存到PSRAM。

方法一：使用LVGL的图片缓存机制（推荐）

LVGL提供了图片解码和缓存API。我们可以创建一个位于PSRAM的缓存。

// 在setup()中，初始化LVGL和显示驱动之后 #define IMG_CACHE_SIZE (1024 * 100) // 为图片缓存分配100KB PSRAM void setup() { // ... 之前的LVGL和显示初始化代码 ... // 初始化图片解码器缓存（使用PSRAM） static uint8_t* img_cache_buf = (uint8_t*)ps_calloc(IMG_CACHE_SIZE, sizeof(uint8_t)); if (img_cache_buf) { lv_img_cache_set_size(IMG_CACHE_SIZE); // 设置缓存大小 // 注意：lv_img_cache_init() 在较新版本中可能不需要显式调用，缓存是自动管理的。 // 关键是确保 lv_img_decoder_t 的 open_cb 中分配的内存来自PSRAM（见方法二）。 Serial.println("Image cache allocated in PSRAM."); } // ... 创建UI，加载图片 ... }

方法二：自定义图片解码器，将解码数据直接放入PSRAM

对于需要完全控制的场景，可以自定义图片解码器的open_cb回调函数，在其中使用PSRAM分配内存来存储解码后的图片数据。

// 定义一个自定义的用户数据结构，用来存储我们分配的PSRAM内存指针 typedef struct { lv_color_t* pixel_map; // 指向PSRAM中图片数据的指针 // 其他信息... } my_img_decoder_user_data_t; // 在自定义的 open_cb 函数中 static lv_res_t decoder_open(lv_img_decoder_t* decoder, lv_img_decoder_dsc_t* dsc) { // 检查图片格式...（省略） // 计算解码后所需内存 uint32_t px_size = lv_color_format_get_size(dsc->header.cf); uint32_t data_size = dsc->header.w * dsc->header.h * px_size; // 在PSRAM中分配内存 my_img_decoder_user_data_t* user_data = (my_img_decoder_user_data_t*)lv_malloc(sizeof(my_img_decoder_user_data_t)); user_data->pixel_map = (lv_color_t*)ps_malloc(data_size); if (user_data->pixel_map == NULL) { lv_free(user_data); return LV_RES_INV; } // 进行图片解码，将像素数据填充到 user_data->pixel_map ...（省略，依赖具体解码库） dsc->img_data = (uint8_t*)user_data->pixel_map; dsc->user_data = user_data; // 保存指针，以便在close_cb中释放 return LV_RES_OK; } // 在 close_cb 中释放PSRAM内存 static void decoder_close(lv_img_decoder_t* decoder, lv_img_decoder_dsc_t* dsc) { if (dsc->user_data) { my_img_decoder_user_data_t* user_data = (my_img_decoder_user_data_t*)dsc->user_data; if (user_data->pixel_map) { free(user_data->pixel_map); // 释放PSRAM内存 } lv_free(user_data); dsc->user_data = NULL; dsc->img_data = NULL; } } // 注册自定义解码器 void register_custom_decoder() { lv_img_decoder_t* dec = lv_img_decoder_create(); lv_img_decoder_set_info_cb(dec, decoder_info); lv_img_decoder_set_open_cb(dec, decoder_open); lv_img_decoder_set_close_cb(dec, decoder_close); }

这种方法更底层，控制力强，但实现也更复杂。对于大多数应用，使用方法一（增大缓存）并确保图片文件本身存储在Flash中，已经能有效缓解内存压力。

5.2 处理大字体文件

如果使用了大型中文字库（如从外部Flash加载的.bin字体文件），LVGL在渲染时可能会在内部RAM中创建字体的位图缓存。我们可以通过配置，将这个缓存也导向PSRAM。

这通常需要在初始化字体时，使用LVGL的lv_font_t结构体相关的函数，并指定自定义的内存分配函数。然而，LVGL内置字体的缓存管理不如图片缓存那么直接暴露。一个更实用的方法是：

优先使用“外部加载”字体：将字体文件存储在SPIFFS/LittleFS中，并使用lv_font_load相关API（如果LVGL版本支持）动态加载。虽然加载速度稍慢，但避免了将整个字库一次性加载到RAM（无论是内部还是外部）。对于ESP32+PSRAM的方案，如果必须缓存，可以尝试修改LVGL字体库的源码，将其内部lv_malloc调用替换为ps_malloc，但这属于高级hack，需要谨慎操作。

一个更简单的建议是：精简你的字体。只包含UI实际用到的字符（Glyph），使用LVGL官方工具lv_font_conv来生成高度定制化的字体C文件，这能从根本上减少内存占用，比任何缓存技巧都有效。

6. 性能调优与监控

将内存移到PSRAM解决了容量问题，但引入了速度延迟。我们需要通过一些手段来监控和优化性能，确保UI依然流畅。

6.1 监控内存使用情况

在开发过程中，定期打印内存信息，有助于了解优化效果和发现内存泄漏。

void print_memory_info(const char* tag) { static uint32_t last_print = 0; uint32_t now = millis(); if (now - last_print < 5000) return; // 每5秒打印一次 last_print = now; Serial.printf("[%s] Heap: Total=%d, Free=%d, MinEver=%d | ", tag, ESP.getHeapSize(), ESP.getFreeHeap(), ESP.getMinFreeHeap()); if (psramFound()) { Serial.printf("PSRAM: Total=%d, Free=%d\n", ESP.getPsramSize(), ESP.getFreePsram()); } else { Serial.println("No PSRAM"); } } // 在loop()中调用 void loop() { lv_timer_handler(); print_memory_info("Loop"); delay(5); }

观察Free Heap和Free PSRAM的变化。在UI加载完成后，这两个值应该稳定在一个水平。如果持续下降，说明可能存在内存泄漏，需要检查图片、字体等资源的创建和销毁逻辑。

6.2 优化LVGL刷新与渲染性能

  1. 调整LVGL任务周期：lv_timer_handler()的调用频率直接影响UI响应速度。在loop()中delay(5)意味着大约200Hz的调用频率，这对大多数应用足够了。如果你的UI非常复杂，可以尝试减少延迟，但注意不要阻塞其他任务（如Wi-Fi、蓝牙）。
  2. 启用LVGL的渲染缓存：对于复杂的、不常变化的控件（如带渐变的背景），可以将其设置为LV_OBJ_FLAG_HIDDEN以外的缓存标志（如LV_OBJ_FLAG_FLEX_IN_NEW_TRACK？更正：应为LV_OBJ_FLAG_CLICKABLE等，具体缓存机制需查LVGL文档）。较新版本的LVGL有更智能的局部重绘和缓存策略。
  3. 降低颜色深度：如果屏幕支持且视觉可接受，将LV_COLOR_DEPTH从16改为8（索引色）或1（单色），可以立即将显示缓冲区和图片缓存的内存占用减半或更多，同时提升SPI传输速度。
  4. 使用硬件加速：如果ESP32-S3和你的屏幕驱动支持，探索使用SPI DMA、甚至LCD专用接口（如8080并行接口）来传输数据，这能极大缓解CPU压力。

6.3 实测：优化前后的性能对比

为了量化优化效果，我曾在同一个ESP32-S3-DevKitC-1（8MB PSRAM）和320x240 SPI屏幕上进行测试，UI包含一个滑动列表（20个项）、一个背景图和几种字体。

  • 优化前（全部使用内部RAM）：

    • 启动后Free Heap：~250KB
    • 创建完整UI后Free Heap：~30KB（濒临崩溃边缘）
    • 快速滑动列表时，明显掉帧，FPS估计低于15。
    • 偶尔出现内存分配失败，导致系统重启。

  • 优化后（显示缓冲区、图片缓存放入PSRAM）：

    • 启动后Free Heap：~250KB（不变）
    • 创建完整UI后Free Heap：~220KB（内部RAM消耗极少）
    • Free PSRAM：从8192KB减少到约7900KB（使用了约300KB PSRAM）。
    • 滑动列表流畅，FPS稳定在30以上（受限于SPI刷新率）。
    • 系统运行稳定，可长时间工作。

这个对比清晰地展示了PSRAM优化带来的巨大收益：它将内存瓶颈从内部RAM转移到了容量大得多的PSRAM，从而为复杂的UI提供了可能。

7. 常见问题与排查技巧实录

在实际操作中，你可能会遇到以下问题。这里记录了我踩过的坑和解决方法。

7.1 编译通过，但运行时黑屏或花屏

  • 可能原因1：PSRAM未正确启用或初始化顺序错误。

    • 排查：确保在lv_init()和分配缓冲区之前，PSRAM已经可用。ESP32的Arduino核心会在setup()函数执行前自动初始化PSRAM，所以通常没问题。但如果你在全局变量中过早调用ps_malloc，可能会失败。最佳实践：在setup()函数内，lv_init()之后，再进行PSRAM内存分配。
    • 检查：运行前面提到的PSRAM测试代码，确认能正常分配和读写。

  • 可能原因2：显示缓冲区指针传递或大小计算错误。

    • 排查：仔细检查lv_disp_draw_buf_init(&draw_buf, buf1, buf2, buf_size);中的buf_size。它指的是每个缓冲区能容纳的像素点数，而不是字节数。如果你的缓冲区是lv_color_t buf1[SCREEN_WIDTH * 20]，那么buf_size就是SCREEN_WIDTH * 20。如果传成了字节数，会导致LVGL内存越界，引发花屏或崩溃。
    • 技巧：在分配后，用memset给缓冲区填充一个测试色（如红色），然后在Flush函数里打印前几个像素值，看是否一致。

  • 可能原因3：屏幕驱动初始化或Flush函数有误。

    • 排查：PSRAM优化不改变屏幕驱动本身。首先，注释掉PSRAM分配代码，换回内部RAM的小缓冲区测试最基本的LVGL显示（如一个“Hello World”标签），确保驱动本身是正确的。
    • 检查：Flush函数中的setAddrWindow坐标和pushPixels的长度计算是否正确。PSRAM的引入不改变这部分逻辑。

7.2 UI响应缓慢，感觉比用内部RAM还卡

  • 可能原因：PSRAM访问速度慢，且未启用DMA。
    • 解决方案：这是性能问题的核心。务必确保你的屏幕驱动库支持并启用了DMA。对于TFT_eSPI库，需要在用户配置文件中（如User_Setup.h）定义#define USE_DMA，并且根据你的ESP32型号和SPI引脚定义正确的DMA通道。DMA能显著降低CPU占用，让LVGL有更多时间进行渲染计算。
    • 优化：尝试增大LVGL的缓冲区大小。虽然这会占用更多PSRAM，但减少了LVGL需要重绘的频率。例如，将行缓冲改为1/4或1/2屏幕大小的缓冲。在PSRAM充足的情况下，用空间换时间是值得的。
    • 检查：降低屏幕的SPI时钟频率（SPI_FREQUENCY）。有时过高的SPI频率在长线连接或质量一般的屏幕上会导致数据错误，驱动库不得不重试，反而更慢。尝试逐步降低频率测试。

7.3 系统随机重启或出现Guru Meditation Error

  • 可能原因1：内存分配失败或指针错误。

    • 排查：严格检查所有ps_malloc/ps_calloc的返回值是否为NULL。PSRAM虽然大，但也不是无限的。如果分配了超过其大小的内存，会返回NULL，后续使用该指针会导致崩溃。
    • 排查：确保在close_cb或对象删除回调中，正确释放了所有在PSRAM中分配的内存。LVGL的对象删除可能会触发相关回调。

  • 可能原因2：堆栈溢出或任务优先级问题。

    • 排查：LVGL的lv_timer_handler()不应该在中断服务程序（ISR）中调用。确保它在主循环loop()或一个独立的FreeRTOS任务中调用。
    • 排查：如果使用了FreeRTOS，确保分配给LVGL任务（或loop()所在任务）的堆栈足够大。PSRAM相关的操作可能需要在任务栈上分配一些临时变量。可以尝试增大任务的堆栈大小。
    • 检查：使用xPortGetFreeHeapSize()和uxTaskGetStackHighWaterMark()等函数监控堆栈使用情况。

7.4 图片显示异常或字体缺失

  • 可能原因：图片/字体数据在PSRAM中损坏或访问越界。
    • 排查：如果使用了自定义解码器并将解码数据放在PSRAM，确保在close_cb中释放内存后，将dsc->img_data和dsc->user_data置为NULL，防止LVGL后续访问野指针。
    • 排查：对于从文件系统加载的图片，确保文件读取和PSRAM内存写入的代码是正确的，没有出现缓冲区溢出。可以在解码完成后，校验PSRAM中数据的头几个和尾几个字节。
    • 字体问题：如果字体显示为方框，首先检查字体文件是否成功加载到LVGL。PSRAM优化主要针对缓存，字体本身的加载路径（Flash）是否正确是前提。

一个实用的调试技巧：分段注释法。当你遇到复杂问题时，不要一次性把所有优化代码都加上。先让最基本的LVGL显示（用内部RAM小缓冲区）工作。然后，只启用PSRAM显示缓冲区，测试。通过后再加入图片PSRAM缓存测试。这样能快速定位问题出现在哪个环节。