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 中的含义帧率也就是 FPSFrames Per Second表示每秒钟画面可以刷新多少次。在 ESP32 上讨论帧率通常指某一帧画面从绘制开始到显示完成的周期对应的帧率就是 1 秒除以单帧耗时。举例来说如果一帧从软件绘制到屏幕显示总共耗时 33ms那么帧率大约就是 30FPS。如果优化后单帧耗时降到 16ms帧率提升到 60FPS用户会明显感觉到动画更顺滑、触摸跟手。不过在嵌入式领域帧率并不是一个固定的物理属性。它受软件绘制方式、屏幕刷新率、通信接口速度、分辨率、色深、缓冲区机制等多方面影响。例如一块只能支持 40MHz SPI 时钟的屏幕配合 320x240 分辨率理论刷新时间会受到颜色数据量的限制如果库内部没有使用双缓冲或者 DMACPU 被大量阻塞在搬运数据上同样会压帧率。所以不要把 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 EffectTE引脚或帧同步信号。如果屏幕硬件没有 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 的真实成绩。实际项目里必须用同一套代码和同一屏幕复测测试场景S31 平均 FPSP4X 平均 FPS说明全屏纯色填充5560受像素填充带宽影响随机圆形绘制3136受图形计算与 SPI 传输影响滚动文字4245文字清屏开销较大模拟动画2630包含背景重绘与精灵移动从这组示例数据可以看到P4X 在多个场景下略高一点但差距并不是特别大。真正重要的是在读取数据后要分析瓶颈如果纯色填充 FPS 高但随机圆形 FPS 低说明瓶颈可能不在 SPI 传输而在像素坐标计算、随机函数开销或 fillCircle 的算法效率。反之如果全屏填充都上不去就要检查 SPI 时钟、DMA 和颜色深度。4.4 使用数据对比分析对比帧率时不要只记录平均 FPS还要看最低 FPS。比如 S31 平均 26FPS但最低只有 12FPSP4X 平均 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 每像素字节数。如果分辨率是 320x240RGB565 每像素 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。DMADirect 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渲染任务可以固定到核心 1xTaskCreatePinnedToCore(renderTask, render, 8192, NULL, 5, renderTaskHandle, 1);如果渲染任务和网络任务在同一个核心上抢占网络拥塞时画面帧率会出现周期性抖动。VHvideo hardware相关的计时器、中断也可能影响刷新节奏。项目里的任务数量越多越需要靠帧率曲线来判断调度是否合理。通过vTaskDelay或freertos调度配置让渲染任务在关键刷新期间不被抢占能显著减少卡顿。6. 常见问题与排查思路问题现象常见原因解决思路帧率很低全屏填充都不到 20FPSSPI 时钟过低或屏幕接线过长检查 SPI 频率设置缩短杜邦线尝试 40MHz/80MHz画面闪烁、花屏SPI 频率超出屏幕驱动能力降低 SPI 频率检查 MISO/MOSI 接线换更短导线同一代码两个平台帧率差异大屏幕型号/分辨率/SPI 配置不一致先统一屏幕、时钟、色深后再对比动画突然卡顿平均 FPS 高但最低 FPS 低WiFi/蓝牙任务抢占 CPU 或中断频繁固定渲染任务核心提高渲染任务优先级减少中断Arduino IDE 安装 ESP32 包失败下载源不稳定或网络受限更换镜像源、手动安装离线包、检查防火墙编译报错找不到 TFT_eSPI.h库未安装或安装版本冲突重新安装 TFT_eSPI确认库目录位置LVGL 界面滑动不流畅单缓冲、未开局部刷新、任务间隔太大开启双缓冲检查脏矩形刷新缩短 LVGL timer 周期排查帧率问题建议按“数据 - 硬件 - 驱动 - 软件”的顺序来。不要一上来就改代码而是先用量化工具确认帧率到底是多少、卡顿点在哪个时间段发生。如果手头没有逻辑分析仪也可以先打印每一帧的开始和结束时间戳观察耗时集中在哪个环节。很多问题其实在 SPI 配置和屏幕驱动初始化阶段就已经存在改优化代码反而只能起到微调作用。另外安装 ESP32 开发板包时的失败比例并不低。很多时候提示download failed但换个网络节点重试就成功。手动安装时可以从 GitHub Releases 下载对应版本然后解压到 Arduino 的硬件目录这种方式的成功率更高也更可控。对于团队项目建议把固定版本的 ESP32 包和库依赖整理成文档避免不同成员因为环境差异得到完全不同的帧率测量结果。7. 最佳实践与工程建议7.1 测试前固定环境变量帧率对比最容易犯的错误是“控制变量没有做好”。两边使用不同屏幕、不同颜色模式、不同库版本最后比较 FPS 数字意义不大。建议在测试文档中明确记录以下内容主控芯片型号和主频。屏幕分辨率、驱动 IC、接口类型。SPI 时钟、颜色格式、是否开启 DMA。图形库名称和版本号。测试场景的具体描述。测试时最好在相同供电条件下进行。ESP32 在高负载渲染时功耗会波动如果 S31 供电不足帧率会明显下降却不能说明芯片本身性能差。所以先测量核心电压和电流再记录帧率数据。7.2 用帧时间分析替代单一 FPSFPS 很容易让人忽略一帧耗时的分布。建议在代码中记录每帧耗时的最大值、平均值、标准差而不仅仅是 FPS。因为 FPS1000/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 调优。每完成一个优化项再对比一次帧率基线用数据决定是否保留。这样一步步叠加下来的优化比盲目抄一段“高性能显示代码”要可靠得多。