1. 性能瓶颈诊断：学会使用LVGL内置的帧率监控和CPU负载分析工具，定位界面卡顿的根源

做嵌入式UI开发，最怕什么？

我最怕的就是：界面跑起来了，但一滑动就掉帧，一点击就卡顿。客户走过来看了一眼，说了一句「这反应有点慢啊」——嗯，那种感觉，懂的都懂。

其实卡顿不可怕，可怕的是你不知道它卡在哪。是渲染太慢？是刷新频率不够？还是CPU被别的任务抢走了？

这一章，我就带你用LVGL自带的「诊断工具」，把卡顿的根源揪出来。

1.1 帧率监控：你的界面到底跑多少帧？

LVGL内置了一个非常实用的帧率监控功能。说白了，就是它能告诉你：当前界面每秒刷新了多少次。

人眼看起来流畅的动画，通常需要30帧以上。60帧是理想值。如果掉到20帧以下，你就会明显感觉到「卡」。

  核心概念： LVGL的帧率监控通过 lv_disp_t 结构体中的 refr_period 和 refr_tick 字段实现。每次刷新周期结束后，系统会记录实际耗时。

怎么打开这个功能？很简单，两步走：

使能监控宏：在 lv_conf.h 中打开 LV_USE_PERF_MONITOR。
调用显示函数：在任务循环中调用 lv_refr_get_fps() 获取当前帧率。

// lv_conf.h 中开启性能监控
#define LV_USE_PERF_MONITOR 1

// 主循环中获取帧率
while(1) {
    lv_task_handler();
    uint32_t fps = lv_refr_get_fps();
    printf("当前帧率: %d FPS\n", fps);
    lv_tick_inc(5);
    delay(5);
}

我在项目中遇到过这样的情况：帧率显示一直在55~60之间波动，但用户就是觉得「不跟手」。后来发现，问题不在帧率本身，而在帧率的稳定性——帧率忽高忽低，人眼对「抖动」特别敏感。

我的习惯： 不要只看平均帧率。我会在调试时记录帧率的最小值和最大值。如果最小值低于30，那说明有「掉帧尖峰」，必须排查。

1.2 CPU负载分析：谁抢走了CPU时间？

帧率低，不一定就是LVGL的问题。很多时候，是CPU被别的任务占满了。

LVGL同样提供了CPU负载分析工具。它通过统计 lv_task_handler() 的执行时间，来估算LVGL占用了多少CPU资源。

开启方式跟帧率监控类似：

// lv_conf.h 中开启CPU负载监控
#define LV_USE_PERF_MONITOR 1

// 获取CPU负载百分比
uint32_t cpu_usage = lv_refr_get_cpu_usage();
printf("LVGL CPU负载: %d%%\n", cpu_usage);

这个数值代表什么？

CPU负载	含义	建议
< 30%	LVGL很轻松，CPU有余力	可以增加动画复杂度或帧率
30% ~ 60%	正常范围，但需关注峰值	检查是否有突发高负载操作
60% ~ 80%	负载偏高，可能影响其他任务	需要优化渲染或减少刷新区域
> 80%	危险区，卡顿几乎必然出现	必须立即优化，否则用户体验极差

你想想看，如果你的MCU主频只有200MHz，LVGL就占了80%的CPU，那其他任务（比如通信、传感器采集）怎么办？它们只能「抢」剩下的20%，能不卡吗？

我曾经踩过的坑： 有一次我优化了半天LVGL的渲染代码，帧率就是上不去。后来用CPU负载工具一看，LVGL只占了25%，但系统总CPU负载是95%。原来是一个后台的ADC采样任务用了死循环，把CPU吃死了。所以，先看总负载，再看LVGL负载，这个顺序不能乱。

1.3 可视化诊断：把数据画出来

光看数字不够直观。我个人习惯把帧率和CPU负载实时显示在屏幕上。LVGL官方提供了 lv_demo_benchmark 示例，它会在屏幕上绘制一个实时曲线图。

但如果你不想用整个demo，也可以自己写一个简单的仪表盘：

// 创建一个标签显示帧率
lv_obj_t *fps_label = lv_label_create(lv_scr_act());
lv_label_set_text(fps_label, "FPS: --");
lv_obj_align(fps_label, LV_ALIGN_TOP_LEFT, 10, 10);

// 创建一个标签显示CPU负载
lv_obj_t *cpu_label = lv_label_create(lv_scr_act());
lv_label_set_text(cpu_label, "CPU: --%");
lv_obj_align(cpu_label, LV_ALIGN_TOP_LEFT, 10, 30);

// 定时更新
void monitor_timer_cb(lv_timer_t *timer) {
    char buf[32];
    sprintf(buf, "FPS: %d", lv_refr_get_fps());
    lv_label_set_text(fps_label, buf);

    sprintf(buf, "CPU: %d%%", lv_refr_get_cpu_usage());
    lv_label_set_text(cpu_label, buf);
}
lv_timer_create(monitor_timer_cb, 500, NULL);  // 每500ms更新一次

这样，你在操作界面的时候，就能实时看到帧率和CPU负载的变化。一滑动，帧率掉下去了？CPU负载飙上来了？一目了然。

1.4 知识体系：诊断流程全景图

说了这么多，我们来梳理一下。性能诊断不是瞎猜，而是一个有章可循的流程。下面这张图，就是我总结的「卡顿诊断三步法」：

这张图把诊断流程串起来了。你按照这个顺序走一遍，90%的卡顿问题都能找到根因。

1.5 实战建议：从今天开始养成习惯

嗯，这里我要说点实在的。

很多工程师做UI开发，都是「写完了再调性能」。我的建议是反过来——从一开始就把监控工具打开。就像开车要看仪表盘一样，做UI也要时刻盯着帧率和CPU负载。

开发阶段：在屏幕上常驻显示帧率和CPU负载。每加一个功能，看一眼这两个数值有没有异常变化。
联调阶段：关闭监控显示（避免影响性能测试结果），但通过串口日志记录帧率数据。
发布前：在目标硬件上跑一次完整的性能测试，记录最差情况下的帧率和CPU负载。

一个小技巧： 如果你用的是带RTOS的系统，可以在空闲任务中打印CPU总负载。这样你就能区分「LVGL占了多少」和「系统还剩多少」。我曾经用这个方法发现，一个低优先级的日志打印任务，竟然占用了15%的CPU——关了它，帧率立刻从25帧跳到了45帧。

好了，这一章的内容就到这里。工具已经给你了，方法也讲了。下一步，就是打开你的工程，把帧率和CPU负载监控跑起来。看看你的界面，到底跑在什么水平上。

📚 课程目录

1. 性能瓶颈诊断：学会使用LVGL内置的帧率监控和CPU负载分析工具，定位界面卡顿的根源

1.1 帧率监控：你的界面到底跑多少帧？

1.2 CPU负载分析：谁抢走了CPU时间？

1.3 可视化诊断：把数据画出来

1.4 知识体系：诊断流程全景图

1.5 实战建议：从今天开始养成习惯