ESP32图形界面帧率对比与优化：从测量到提升FPS的完整流程

之前调试 ESP32 图形界面时，经常在帧率上吃暗亏。同样的界面代码，放到不同开发板上，滑动卡顿和动画流畅度差距非常明显。最近手头有两块测试平台，代号分别是 S31 和 P4X，虽然都是 ESP32 家族，但实际跑同一套渲染脚本时帧率却相差不少。这篇文章就把整个帧率对比过程整理出来，从测量方法、驱动配置、图形库选型到优化手段，做成一套可以复用的落地流程。如果你正在做 ESP32 小游戏、LVGL 仪表盘、或者带屏交互项目，这篇文章应该能帮你少走不少弯路。

1. 背景与核心概念

1.1 S31 和 P4X 到底是什么

先澄清一个容易踩坑的问题：ESP32_S31 和 ESP32_P4X 并不是芯片厂商公布的官方型号。乐鑫官方常见的型号是 ESP32、ESP32-S2、ESP32-S3、ESP32-C3、ESP32-C6、ESP32-H2 等，没有 S31 和 P4X 这两个命名。S31 和 P4X 更像是在项目内部使用的开发板代号、定制模块标识，或者是某款非公开开发板的别名。因此在开始对比之前，最好的做法是把它们当作“两个不同的 ESP32 测试平台”，而不是去网上搜索具体的芯片规格。否则很容易把搜索结果当成官方资料，最后做出错误判断。

对比帧率时，真正需要关心的是平台上的主控芯片内核、主频、PSRAM 大小、屏幕接口类型、以及驱动库配置。这些因素决定了实际帧率表现，而不是表面上的型号名称。也就是说，拿到 S31 和 P4X 之后，第一步应该查清楚它们内部是什么芯片、什么屏幕、什么接线方式，然后再开始跑测试。硬件底细没搞清楚之前，所有帧率数据都只能算参考值。

1.2 帧率（FPS）在 ESP32 中的含义

帧率，也就是 FPS（Frames Per Second），表示每秒钟画面可以刷新多少次。在 ESP32 上讨论帧率，通常指某一帧画面从绘制开始到显示完成的周期，对应的帧率就是 1 秒除以单帧耗时。举例来说，如果一帧从软件绘制到屏幕显示总共耗时 33ms，那么帧率大约就是 30FPS。如果优化后单帧耗时降到 16ms，帧率提升到 60FPS，用户会明显感觉到动画更顺滑、触摸跟手。

不过在嵌入式领域，帧率并不是一个固定的物理属性。它受软件绘制方式、屏幕刷新率、通信接口速度、分辨率、色深、缓冲区机制等多方面影响。例如一块只能支持 40MHz SPI 时钟的屏幕，配合 320x240 分辨率，理论刷新时间会受到颜色数据量的限制；如果库内部没有使用双缓冲或者 DMA，CPU 被大量阻塞在搬运数据上，同样会压帧率。所以不要把 FPS 看成“芯片能跑多快”，而要看“整条渲染链路能多快完成一帧”。

1.3 影响 ESP32 帧率的关键因素

从工程角度看，ESP32 帧率主要被以下因素影响：

• 主控主频：ESP32 通常可以配置 80MHz、160MHz、240MHz，更高的主频意味着更短的像素计算时间。对比不同平台时，首先要确认两边的主频配置是否一致。
• 内存与 PSRAM：较大分辨率图像和帧缓冲需要占用内存。没有 PSRAM 时可能只能跑低分辨率；有 PSRAM 后可以放大缓冲，但访问速度可能比内部 SRAM 慢。
• 屏幕接口：常见的有 SPI、并行 RGB、I8080 等。SPI 接口下时钟频率直接决定数据传输上限，RGB 接口往往更依赖 GPIO 数量和时序配置。
• 图形库：裸机直接驱动 LCD 和跑 LVGL、TFT_eSPI、Arduino_GFX 等库，帧率差异很大。库的底层优化程度、DMA 开启情况都会影响结果。
• 缓冲区策略：单缓冲、双缓冲、局部刷新、脏矩形机制对动画场景影响很大。
• 渲染任务优先级：在 ESP-IDF 的 FreeRTOS 环境下，如果渲染任务和网络任务抢占 CPU，帧率会出现周期性抖动。

理解这些因素后，之后再对比 S31 和 P4X 时，就能知道要控制哪些变量，避免得出“某一方更强”的错误结论。

2. 环境准备与测试平台

2.1 硬件条件说明

在正式对比前，需要先确定两边的硬件条件。S31 和 P4X 毕竟不是官方型号，所以以下描述以“项目内测试板”为例。建议测试前整理一份硬件清单，包括：

• 开发板/模组主控芯片具体型号
• 主频配置
• 是否带 PSRAM，容量多大
• 屏幕分辨率、驱动 IC、通信接口
• 屏幕驱动引脚号和背光引脚
• 供电方式

将这些信息记录在表格里，可以避免后续排查时来回找资料。S31 与 P4X 两边板子很可能使用不同屏幕，即使帧率有差异也不一定是芯片本身造成的。严谨的做法是尽量让两块板子使用同一型号屏幕、相同接线方式，或者至少使用相同分辨率和相同通信接口的屏幕。很多时候帧率差异来自屏幕型号和 SPI 时钟上限，而不是 MCU 本身。

2.2 软件环境准备

开发 ESP32 图形项目常用的环境有 Arduino IDE、PlatformIO、ESP-IDF 两种思路。对于快速验证帧率，我习惯使用 Arduino IDE 或 PlatformIO，因为它们集成了 TFT_eSPI、LVGL、Adafruit GFX 等库，上手快。

如果是新环境，需要先在 Arduino IDE 中安装 ESP32 开发板支持包。打开 Arduino IDE，进入“文件 -> 首选项 -> 附加开发板管理器网址”，填入乐鑫官方地址：

https://espressif.github.io/arduino-esp32/package_esp32_index.json

然后在“工具 -> 开发板 -> 开发板管理器”中搜索 ESP32，安装对应版本。需要注意，如果你使用的是 Arduino IDE 2.x 或较新的 1.8.x 版本，下载过程受网络环境影响可能失败，常见错误是：

Failed to install platform: 'esp32:3.3.11' 13 internal: download failed

这类错误一般不是开发板配置写错，而是下载源连接不稳定。可以更换网络环境、手动下载离线包，或者使用国内镜像源后再试。更详细排查思路会在后面“常见问题与排查思路”中展开。

2.3 项目目录与库安装

建议用独立文件夹管理测试工程，方便对比不同版本。项目结构可以参考：

fps_compare/ ├── fps_compare.ino ├── FrameCounter.h └── README.md

其中fps_compare.ino是主程序，FrameCounter.h是帧率计数器工具类。如果你使用 PlatformIO，可以创建src目录并把代码放在里面。库方面，推荐安装 TFT_eSPI 或 Arduino_GFX，二者都支持 ESP32 常见屏驱动。安装完成后再根据屏幕型号修改User_Setup.h或构造函数的参数，这一步是图形项目最繁琐但最关键的部分。

3. 帧率测量方法

3.1 方法一：软件帧率计数器

最简单、最常用的方法是软件帧率计数器。在每画完一帧之后调用一次 tick，累计帧数和耗时，每秒计算一次平均值，并通过串口打印。它的优点是几乎不依赖外部设备，只要代码里能区分“一帧结束”和“下一帧开始”即可。缺点是计数器本身会占用一点 CPU，且只能反映平均速率，不能精确记录每帧的卡顿点。

下面是一个简单的帧率计数器头文件：

// 文件路径：FrameCounter.h #ifndef FRAME_COUNTER_H #define FRAME_COUNTER_H #include <Arduino.h> class FrameCounter { public: FrameCounter() : _frameCount(0), _lastTime(0), _fps(0.0f) {} void begin() { _lastTime = millis(); } void tick() { _frameCount++; unsigned long now = millis(); unsigned long elapsed = now - _lastTime; if (elapsed >= 1000) { _fps = _frameCount * 1000.0f / elapsed; _frameCount = 0; _lastTime = now; } } float getFps() const { return _fps; } private: unsigned long _frameCount; unsigned long _lastTime; float _fps; }; #endif

使用方式很简单：在setup()中调用begin()，在渲染循环每完成一帧后调用tick()。需要输出时读取getFps()即可。需要说明的是，millis()返回的是系统开机以来的毫秒数，在长时间运行时会产生溢出问题，但对帧率统计来说每隔一定时间重新计算，影响不大。

3.2 方法二：屏幕刷新标记与逻辑分析仪

软件计数法只能看到平均帧率，如果想观察每一帧的实际刷新时刻、帧间隔是否均匀，可以用逻辑分析仪测量屏幕的 Tearing Effect（TE）引脚或帧同步信号。如果屏幕硬件没有 TE 引脚，也可以测量 VSYNC 或 DC 引脚切换信号。帧率抖动严重的项目，软件计数法看不出问题，但逻辑分析仪能直接显示帧间隔是否有毛刺。

具体操作是：把逻辑分析仪通道接到屏幕 TE 引脚，设置采样率至少 5MHz 以上，然后连续采集几秒。在分析软件中测量相邻两个上升沿之间的时间间隔，取倒数便得到瞬时帧率。如果两个上升沿之间的时间忽大忽小，意味着渲染任务的调度不稳定，需要检查任务优先级、中断和 DMA。

这种测量方式虽然比软件计数法麻烦，但更接近真实画面刷新情况。尤其在对比两块不同平台的帧率时，能准确判断一个平台是整体偏慢，还是仅在某些时刻出现帧率暴跌。

3.3 方法三：利用 GUI 库自带帧率统计

如果你使用的是 LVGL，可以在lv_conf.h中开启帧率监控相关配置，或者在任务中调用lv_snapshot等方式做性能统计。很多显示库也会提供 FPS 示例，例如 TFT_eSPI 社区版本中就有人做过实时帧率绘制小程序。使用库自带统计的好处是不用自己造轮子；缺点是统计口径因库而异，对比时要先确认两边实现一致。

在实际项目中，我通常同时使用软件缓冲计数和库内置统计两套数据。如果两套数据接近，说明测量可靠；如果差异很大，说明某一处统计逻辑有问题。对于 S31 和 P4X 这种多个平台之间的对比而言，统一测量口径比追求“精确到小数点后一位”更重要，只要两边都是同一版本库、同一统计周期，结果就有可比性。

3.4 对比测试设计

帧率对比不能只跑一个画面。建议设计多组固定场景，例如：

• 场景 A：全屏填充纯色，测试像素填充带宽。
• 场景 B：绘制大量圆形，测试图形计算能力。
• 场景 C：连续滚动文字，测试缓冲刷新与滚动速度。
• 场景 D：模拟小游戏动画，包含背景、角色方块和分数文字。

每个场景固定运行 10 秒，记录平均 FPS、最低 FPS、以及 frame time 的 95% 分位。这种多维数据比单个 FPS 数字更有参考价值。如果 S31 在纯色填充场景快 20%，但在图形绘制场景反而慢 15%，说明瓶颈不同，不能简单说“S31 比 P4X 强”。

4. 实战：S31 与 P4X 帧率对比

4.1 编写基础渲染测试

先从一个可运行的基础测试开始。以下代码使用 TFT_eSPI 库，初始化屏幕后循环绘制随机位置的圆形，并用 FrameCounter 统计帧率。这个场景可以同时压测像素填充和图形绘制能力。

// 文件路径：fps_compare.ino #include <Arduino.h> #include <TFT_eSPI.h> #include "FrameCounter.h" TFT_eSPI tft = TFT_eSPI(); FrameCounter fpsCounter; void setup() { Serial.begin(115200); tft.begin(); tft.setRotation(1); tft.fillScreen(TFT_BLACK); fpsCounter.begin(); Serial.println("FPS test start"); } void loop() { uint16_t color = random(0x0000, 0xFFFF); int16_t x = random(0, tft.width()); int16_t y = random(0, tft.height()); tft.fillCircle(x, y, 10, color); fpsCounter.tick(); if (millis() % 500 < 5) { Serial.printf("current FPS: %.1f\n", fpsCounter.getFps()); } }

这里random(0x0000, 0xFFFF)生成随机 16 位颜色值，fillCircle每帧绘制一个半径 10 像素的圆形。由于圆形位置随机，CPU 计算和像素填充都在不断变化，避免了静态画面下帧率虚高的问题。串口每 500ms 采样一次 FPS，方便观察整体趋势。

如果你的屏幕不是使用 TFT_eSPI，或者不打算配置User_Setup.h，也可以改用 Arduino_GFX 库。Arduino_GFX 支持通过构造函数指定屏幕 IC 和引脚，比较灵活。但无论使用哪个库，都要求先完成屏幕初始化，否则后续帧率数据没有意义。

4.2 配置屏幕驱动

屏幕驱动配置是 ESP32 显示项目里最容易出问题的一步。TFT_eSPI 库通常需要在User_Setup.h中修改屏幕类型、SPI 频率、引脚定义。下面是一个示例配置片段，实际值需要根据你的屏幕修改：

// 文件路径：User_Setup.h 片段 #define ILI9341_DRIVER #define TFT_MISO 19 #define TFT_MOSI 23 #define TFT_SCLK 18 #define TFT_CS 5 #define TFT_DC 2 #define TFT_RST 4 #define SPI_FREQUENCY 40000000

需要注意，SPI 频率并不是越高越好。屏幕驱动 IC、杜邦线长度、PCB 布局、逻辑电平都会限制实际可用的最高时钟。强行调高 SPI 频率可能导致花屏或数据错位。在实际对比中，建议先将两块平台都设置成相同 SPI 频率，比如 40MHz，跑完基础数据，再分别尝试更高频率观察差异。

4.3 不同场景下的帧率数据

这里给出一组“示例数据”，只用于说明对比思路，不代表 S31 和 P4X 的真实成绩。实际项目里必须用同一套代码和同一屏幕复测：

从这组示例数据可以看到，P4X 在多个场景下略高一点，但差距并不是特别大。真正重要的是，在读取数据后要分析瓶颈：如果纯色填充 FPS 高，但随机圆形 FPS 低，说明瓶颈可能不在 SPI 传输，而在像素坐标计算、随机函数开销或 fillCircle 的算法效率。反之，如果全屏填充都上不去，就要检查 SPI 时钟、DMA 和颜色深度。

4.4 使用数据对比分析

对比帧率时，不要只记录平均 FPS，还要看最低 FPS。比如 S31 平均 26FPS，但最低只有 12FPS；P4X 平均 30FPS，最低有 25FPS。这种情况下，尽管平均 FPS 差距不大，实际体验 P4X 会明显更顺滑。原因是人眼对帧率波动很敏感，尤其是从 26FPS 突然掉到 12FPS 时，画面会突然卡一下。

可以在代码里增加最小帧率记录：

float minFps = 9999.0f; // 每次需要输出帧率时计算 float current = fpsCounter.getFps(); if (current > 0.1f && current < minFps) { minFps = current; }

串口可以打印平均 FPS、最低 FPS 和运行时间。这样两边的数据更全面，也更容易定位问题。如果某个平台的最低 FPS 异常低，可以进一步用逻辑分析仪观察那段时期的刷新间隔，判断是触发了 GC（垃圾回收）、网络任务抢占了 CPU，还是屏幕刷新过程被中断打断。

5. 帧率优化的常用手段

5.1 调高 SPI 时钟

SPI 屏幕的带宽公式可以近似理解为：一帧彩色图像数据量 = 宽度 x 高度 x 每像素字节数。如果分辨率是 320x240，RGB565 每像素 2 字节，那么一帧数据量是 320 x 240 x 2 = 153600 字节，约 150KB。如果 SPI 时钟是 40MHz，理论峰值带宽约 5MB/s，那么仅传输一帧画面就需要约 30ms，理论 FPS 上不了 33 帧。如果 SPI 时钟提升到 80MHz，理论 FPS 可以翻倍。因此调高 SPI 时钟是最直接的提速手段，前提是屏幕和接线能稳定工作。

在 TFT_eSPI 中，可以这样设置 SPI 频率：

tft.setSPISpeed(80000000);

在普通 Arduino SPI 中，也可以显式声明传输参数：

SPI.beginTransaction(SPISettings(80000000, MSBFIRST, SPI_MODE0));

调高频率后需要观察是否出现花屏、残影、闪烁。如果出现，先降低频率或缩短杜邦线长度，再考虑逻辑电平转换问题。高频信号对硬件布局非常敏感，这也是很多开发板在 40MHz 稳定、80MHz 不稳定的原因。

5.2 使用双缓冲与 DMA

单缓冲模式下，屏幕刷新和绘制过程相互影响。绘制过程中如果屏幕同时需要刷新，就会出现“撕裂（tearing）”。双缓冲则通过两块缓冲区轮流切换，一帧在后台绘制，另一帧用于屏幕刷新，从而减少画面撕裂，也让统计出来的帧率更稳定。

ESP32 的 SPICAM / PSRAM 可以用来充当大块帧缓冲，但访问速度不如内部 SRAM。DMA（Direct Memory Access）可以把 SPI 数据搬运交给硬件，CPU 不必逐字节等待，提高了并行度。在 TFT_eSPI 中，可以使用setSwapBytes和 DMA 相关 API 来优化数据写入。不过，DMA 功能依赖底层驱动支持，不同库的表现差异很大。

使用 ESP-IDF 时，可以考虑spi_device_interface_config_t中配置 DMA 通道：

spi_device_interface_config_t devcfg = { .mode = 0, .clock_speed_hz = SPI_CLOCK_HZ, .spics_io_num = PIN_NUM_CS, .queue_size = 7, .flags = SPI_DEVICE_HALFDUPLEX, };

具体 API 要根据 ESP-IDF 版本和项目代码调整，不能直接复用。这里强调的是思路：先测出 DMA 开启前后的帧率差异，再决定是否值得为 DMA 增加复杂度。

5.3 降低分辨率与色深

如果项目不是必须满分辨率显示，降低分辨率是性价比最高的优化方案。比如从 320x240 降到 240x240，或者降到 160x128，像素数据量显著减少，SPI 传输时间下降，帧率自然提升。色深方面，从 RGB565 降到 RGB332 或 8 位调色板模式，能减少每像素字节数，但色彩表现会变差，适合简单游戏或仪表盘场景。

很多屏幕驱动库支持局部窗口刷新。比如只需更新一个温度数值，就不需要整屏重绘，而只更新温度文字所在的矩形区域。这个优化在 GUI 场景中非常重要，LVGL 的脏矩形机制就是做类似的事情。如果每次变化都刷全屏，即使主频再高，帧率提升空间也有限。

5.4 图形绘制优化

图形绘制优化的常见方向包括：

• 避免频繁使用大面积fillScreen。清屏操作代价很高，尽量维护背景层，只重绘变化区域。
• 提前计算不需要每帧变化的图形，例如静态背景图直接缓存成 Sprite 或图像数组。
• 使用整数运算替代浮点运算。ESP32 虽然有 FPU，但大量浮点计算仍会拖慢渲染循环。
• 合理选择颜色模式，避免运行时做不同格式之间的颜色转换。
• 减少random、sin等函数在每帧循环中的调用次数，需要时用预生成表。

对于小游戏场景，建议把游戏逻辑更新和画面绘制分开。逻辑更新可以放在固定时间片，例如每 33ms 一次；画面绘制则根据实际帧率决定是否合并。这样做能避免逻辑更新次数波动导致画面忽快忽慢。

5.5 合理选择 RTOS 任务与优先级

在 ESP-IDF 环境下，常用的方式是创建独立任务来渲染。任务优先级和 CPU 核心选择会影响帧率稳定性。比如 WiFi 任务可能跑在核心 0，渲染任务可以固定到核心 1：

xTaskCreatePinnedToCore(renderTask, "render", 8192, NULL, 5, &renderTaskHandle, 1);

如果渲染任务和网络任务在同一个核心上抢占，网络拥塞时画面帧率会出现周期性抖动。VH（video hardware）相关的计时器、中断也可能影响刷新节奏。项目里的任务数量越多，越需要靠帧率曲线来判断调度是否合理。通过vTaskDelay或freertos调度配置，让渲染任务在关键刷新期间不被抢占，能显著减少卡顿。

6. 常见问题与排查思路

排查帧率问题建议按“数据 -> 硬件 -> 驱动 -> 软件”的顺序来。不要一上来就改代码，而是先用量化工具确认帧率到底是多少、卡顿点在哪个时间段发生。如果手头没有逻辑分析仪，也可以先打印每一帧的开始和结束时间戳，观察耗时集中在哪个环节。很多问题其实在 SPI 配置和屏幕驱动初始化阶段就已经存在，改优化代码反而只能起到微调作用。

另外，安装 ESP32 开发板包时的失败比例并不低。很多时候提示download failed，但换个网络节点重试就成功。手动安装时，可以从 GitHub Releases 下载对应版本，然后解压到 Arduino 的硬件目录，这种方式的成功率更高，也更可控。对于团队项目，建议把固定版本的 ESP32 包和库依赖整理成文档，避免不同成员因为环境差异得到完全不同的帧率测量结果。

7. 最佳实践与工程建议

7.1 测试前固定环境变量

帧率对比最容易犯的错误是“控制变量没有做好”。两边使用不同屏幕、不同颜色模式、不同库版本，最后比较 FPS 数字意义不大。建议在测试文档中明确记录以下内容：

• 主控芯片型号和主频。
• 屏幕分辨率、驱动 IC、接口类型。
• SPI 时钟、颜色格式、是否开启 DMA。
• 图形库名称和版本号。
• 测试场景的具体描述。

测试时最好在相同供电条件下进行。ESP32 在高负载渲染时功耗会波动，如果 S31 供电不足，帧率会明显下降，却不能说明芯片本身性能差。所以先测量核心电压和电流，再记录帧率数据。

7.2 用帧时间分析替代单一 FPS

FPS 很容易让人忽略一帧耗时的分布。建议在代码中记录每帧耗时的最大值、平均值、标准差，而不仅仅是 FPS。因为 FPS=1000/frame_time，平均值相近的两个平台，帧耗时的波动可能完全不同。帧耗时更稳定的一方，即使平均 FPS 略低，实际动画效果也可能更好。可以在每次渲染循环开头获取micros()，循环结束时再取一次时间，计算单帧耗时，再在一秒内做统计。

帧时间统计可以这样写：

unsigned long frameStart = micros(); // 渲染一帧 tft.fillCircle(x, y, 10, color); unsigned long frameCost = micros() - frameStart;

这里micros()是微秒计时，适合 16ms 到 50ms 级别的单帧耗时统计。如果有比微秒精度更高的需求，需要依赖 ESP32 内部的硬件定时器，但一般情况下micros()已经够用。

7.3 记录基线数据并持续回归

在项目初期就建立基线数据，是防止后期“越优化越乱”的关键。每当更新驱动库、修改屏幕驱动配置、调整任务调度算法后，都重新跑一遍相同的测试场景，并对比原有基线。如果帧率突然下降，回退版本或修改项就很容易定位。没有基线数据时，性能优化很容易变成凭感觉调整，最后可能花费大量时间却看不到稳定提升。

7.4 代码结构上预留可配置项

屏幕引脚、SPI 频率、分辨率、颜色格式这类参数，建议放在统一配置文件中，不要散落在主程序里。这样在对比 S31 和 P4X 时，可以快速切换配置，而不是反复修改代码再编译。比如可以定义一组宏：

#define LCD_SPI_FREQ_HZ 40000000 #define LCD_WIDTH 240 #define LCD_HEIGHT 320 #define LCD_COLOR_BITS 16

在后续维护中，只要改这几个宏就能适配新屏幕。尤其是在多块开发板之间做性能测试时，统一配置能大幅减少工作量和出错概率。

7.5 安全与电源注意事项

在开发板上做高频 SPI 和长时间满负荷渲染测试时，芯片和屏幕的发热量会上升。如果发现屏幕出现偏色、花屏或随机重启，除了检查软件，还要确认电源是否稳定。建议使用质量可靠的 USB 线或外部 5V 供电，并测量开发板 3.3V 引脚电压是否跌落太多。长时间运行测试时，可以加一个小风扇辅助散热，避免温度升高导致芯片降频或数据不稳定。

8. 从测试到优化的后续方向

S31 和 P4X 的帧率对比，本质上不是比较两个“型号”谁更强，而是验证一套测试流程是否足够可靠。只要测量方法统一、控制变量做到位，即使最终结果和预期不一样，也能从帧耗时、SPI 配置、内存占用等维度解释原因。之后继续做 LVGL 界面、ESP32 小游戏、或接入更多传感器显示项目时，这套帧率测试和优化流程可以重复使用。

下一步可以尝试的方向包括：在 LVGL 中开启双缓冲并把渲染任务固定到某个核心；用 Sprite 或局部刷新优化小游戏的背景滚动；给屏幕增加 TE 引脚检测，实现真正的垂直同步；或者在 ESP-IDF 环境下对 SPI 驱动做更细粒度的 DMA 调优。每完成一个优化项，再对比一次帧率基线，用数据决定是否保留。这样一步步叠加下来的优化，比盲目抄一段“高性能显示代码”要可靠得多。