LVGL PC仿真环境搭建指南：SDL2+CMake实现嵌入式UI高效开发

最近给一个带3.5寸屏的小设备做界面主控是STM32F4级别的MCUGUI库选了LVGL。界面需求不算复杂一个主页面、几个参数设置页、弹窗提示、中文字体显示。但真正上手之后才发现UI这东西想在板子上直接调好太难了——焊上屏、烧录一次固件、上电观察、再改代码一个循环下来十几分钟就没了大多数时间都耗在无意义的等待上。于是我把开发流程改成了先在PC上搭一套LVGL仿真环境把界面和交互逻辑全部在电脑上验证稳定之后再回板子做驱动适配和性能调优。LVGL本身是纯C的嵌入式GUI库底层只依赖有限的硬件回调天生就适合做跨平台仿真。这篇文章写的就是这套PC仿真环境的搭建过程、关键配置和一路踩过的坑不光是能跑的步骤还包括为什么这么配、配置背后的逻辑、以及真机移植时怎么衔接。适用人群我也说下刚接触LVGL想快速上手的推荐从第一章完整看到编译运行已经在产品上用LVGL的可以直接跳去第四章和第五章很多坑我自己踩过写成速查表了照着排查能省不少时间。1. PC仿真环境的价值与方案选型1.1 为什么要在PC上搭仿真环境做嵌入式GUI的兄弟应该都有这种感觉在板子上调界面烧录一次固件的成本实在太高。我这里说的是最普通的上位机下载、复位、观察这套流程一次怎么也得十几秒如果界面里要调几个控件的坐标、字体大小、间距这类细活一上午改下来大部分时间都在等下载。更难受的是有些问题只有交互操作到特定步骤才会暴露比如弹窗显示位置、键盘焦点切换、点击区域偏移在PC仿真的窗口里一眼就能看出来在板子上可能要反复操作好久才能复现。PC仿真环境解决的正是这个问题。LVGL在架构上把硬件相关部分抽象成了显示驱动、输入设备和系统时钟三个接口只要把这三个接口接到PC的资源上LVGL的大部分功能就能在电脑上原样跑起来。官方提供的lv_sim_vscode_sdl就是基于这个思路实现的显示输出接到SDL2窗口鼠标事件当作触摸输入SDL的计时器作为LVGL的时钟源。这样一套环境跑起来之后改一个界面坐标编译运行几乎是马上就能看到效果整个开发节奏完全不一样。不过也要提醒一句PC仿真解决的是“UI逻辑对不对、布局好不好看、交互顺不顺”的问题不能替代真机的性能测试。同一套界面在PC上跑得飞快不代表在STM32上也能保持流畅尤其是动画、阴影、模糊这类吃资源的效果最终一定要到真机上评估。这个边界心里有数仿真环境才不会被误用。1.2 主流仿真方案横向对比我给四套方案做了个对比方便不同需求的人直接选择方案适用场景优点缺点官方SDL模拟器lv_sim_vscode_sdlPC上快速验证UI逻辑、布局、交互API与官方最新版本同步可自定义分辨率/色深可跑官方示例需要自己搭建SDL2环境不涉及真实外设时序PlatformIO LVGL TFT_eSPIESP32等平台开发时顺带做界面验证集成度高能直接编译真机固件一套环境两用仿真体验受插件限制版本升级不如官方工程及时QEMU 嵌入式Linux方案需要验证驱动级行为、整机启动流程最接近真机能模拟完整SoC和外设环境搭建非常复杂启动慢通常只用于系统级调试真机反复烧录最终性能验证和驱动联调结果最真实与外设配合最准确迭代效率极低不适合做前期布局调整我的判断是如果目标只是把LVGL的界面和交互逻辑调顺官方SDL模拟器是性价比最高的选择没有之一。QEMU那套东西适合玩LinuxLVGL或者要模拟整个SoC的场景普通嵌入式项目用不上折腾成本远远大于收益。最理想的工作流其实是“PC仿真调UI 真机烧录调性能”双管齐下两个环节各有分工谁也替代不了谁。1.3 我最终定下来的组合我最终选了“LVGL官方SDL模拟器工程 VS Code CMake Ninja MSYS2/MinGW”这套组合。选择它主要有三个原因第一官方模拟器工程lv_sim_vscode_sdl跟LVGL主仓库保持同步API不会出现滞后问题不用担心自己花一周搭好的环境突然不能跑最新版特性。第二工程基于CMake构建换平台成本极低项目组其他人用Ubuntu还是macOS拉下来加两个依赖就能编译不需要每个人各自维护一套奇怪的环境。第三VS Code在这里只当编辑器用实际编译在终端执行行为透明出了问题一眼能看出是哪一步挂了不需要黑盒式的IDE工程。如果你在Windows上开发建议直接用MSYS2的MinGW-w64工具链而不是去折腾Visual Studio的MSVC。原因后面会详细说但简单提一句MSYS2装SDL2只需要一条pacman命令而MSVC配SDL2的库路径、运行库选项、头文件目录每一步都可能踩坑不值得。2. 环境准备与核心配置2.1 工具链准备与平台差异先说工具链里最容易被忽略的一件事SDL2必须装“开发库”不是运行库。很多人以为装个SDL2就能编译结果报SDL.h找不到其实就是缺headers。Windows下我推荐MSYS2装完MSYS2之后打开“MSYS2 MINGW64”终端依次执行这三条命令pacman -S mingw-w64-x86_64-toolchain pacman -S mingw-w64-x86_64-cmake mingw-w64-x86_64-ninja pacman -S mingw-w64-x86_64-SDL2第一条是编译器工具链第二条是CMake和Ninja构建工具第三条是SDL2开发库。装完之后在同一个MINGW64终端里进入工程目录后续所有编译命令都在这个终端里跑cmake和ninja会自动识别编译器路径不需要额外配置环境变量。Ubuntu下更简单sudo apt update sudo apt install build-essential cmake ninja-build libsdl2-devmacOS则是brew install cmake ninja sdl2编译器的选择上Windows下我不推荐MSVC的原因很直接lv_sim_vscode_sdl的CMakeLists默认从系统环境里找SDL2MSVC下你还需要手动指定SDL2的路径而且SDL2官方预编译库的MT/MD运行库选项经常跟工程冲突改起来非常烦。MinGW-w64则没有这个问题因为这个工程的Maintainer主要就是按MSYS2环境来验证的跟着官方路线走踩坑最少。2.2 拉取工程与目录结构工具链准备好之后拉代码这一步有一个大坑必须带子模块一起拉。LVGL的核心源码和驱动层都是git submodule如果只git clone主目录后续编译会直接报fatal error: lvgl.h找不到。正确命令是git clone --recurse-submodules https://github.com/lvgl/lv_sim_vscode_sdl.git如果你已经拉到了没有子模块的目录可以用下面这条补救git submodule update --init --recursive拉完之后进入工程目录里面长这样lv_sim_vscode_sdl/ ├── lvgl/ # LVGL核心库子模块 ├── lv_drivers/ # SDL显示/输入驱动子模块 ├── lv_conf.h # LVGL全局配置重点修改对象 ├── lv_drv_conf.h # SDL驱动配置注意分辨率开关 ├── main.c # 主入口调用demo或自定义UI ├── CMakeLists.txt # CMake构建脚本 └── lv_demos/ # 官方示例widgets/music/benchmark等理解目录结构很重要因为后面几乎所有调试工作都在两个文件里展开lv_conf.h负责LVGL内部功能开关lv_drv_conf.h负责SDL窗口和输入设备参数。改错文件或者两个文件参数不一致会出现“界面能跑但显示区域不对”这种诡异问题。2.3 lv_conf.h和lv_drv_conf.h关键配置项逐条说打开lv_conf.h这个文件一开头有一段“Copy this file as lv_conf.h”的注释不用管它这个工程已经放好位置了。关键是下面这些宏我按优先级排个序LV_COLOR_DEPTH色彩深度一般设16或32。如果你的目标屏幕是RGB565接口就设16颜色渲染最接近真机如果是RGB888的屏幕建议设32。这个参数直接影响颜色缓冲区的内存占用和显色效果仿真阶段尽早和真机对齐否则后期会现出“PC上颜色很漂亮上真机发现颜色不对”的问题。LV_HOR_RES / LV_VER_RES逻辑分辨率也就是你要模拟的那块屏幕的分辨率。比如3.5寸屏常见320x480你就在lv_conf.h里设置#define LV_HOR_RES 320 #define LV_VER_RES 480但注意这还只是LVGL内部知道的大小SDL窗口实际开多大还由lv_drv_conf.h里的SDL_HOR_RES和SDL_VER_RES决定。这两处必须保持一致否则要么窗口显示不全要么LVGL渲染区域和窗口尺寸错位。这个“两处都要改”的问题是我见过最多的低级错误之一。LV_DPI这一项很多人忽略其实是模拟器里最容易影响观感的参数。DPI直接影响LVGL控件的默认尺寸缩放比如同样的分辨率DPI设100和设160按钮看起来大小差很多。一般根据屏幕物理尺寸估算3.5寸320x480的屏幕DPI设130到160之间比较合理。如果仿真窗口里的按钮、文字总是显得特别小而挤先检查这里。LV_MEM_SIZELVGL内部动态内存池大小。PC仿真时内存不是瓶颈可以把LV_MEM_SIZE设大一点比如64KB甚至128KB避免界面对象创建多的时候分配失败。真机移植时再根据实际RAM重新收紧。LV_FONT_SIMSUN_16_CJK内置宋体16像素CJK字体开关。在验证中文显示时建议先打开#define LV_FONT_SIMSUN_16_CJK 1这个字体包含常用简体中文字库前期用它快速验证中文显示逻辑非常方便后期再换自定义字体。LV_USE_PERF_MONITOR和LV_USE_MEM_MONITOR两个开关也建议打开一个在界面右上角显示帧率和CPU占用一个显示内存占用这对判断界面复杂度非常有用后面第四章专门讲。demo相关的开关在文件后面LV_USE_DEMO_*部分默认widgets demo是开的其他可以按需打开。lv_drv_conf.h里除了分辨率还有一个SDL_ZOOM和SDL_TRUE_COLOR需要注意。SDL_ZOOM是窗口缩放倍数如果屏幕分辨率是320x480你觉得窗口太小可以设2甚至3逻辑分辨率不变窗口显示更大。SDL_TRUE_COLOR跟色深联动一般保持默认。3. 编译运行与第一个界面3.1 编译命令逐条说明在MSYS2 MINGW64终端Windows或普通终端Linux/macOS里进入工程目录然后执行mkdir build cd build cmake .. -G Ninja ninja我给每条命令做个注释方便你排查问题。mkdir和cd就是创建编译目录并进去这是为了把编译产物跟源码分开避免污染源码树。cmake .. -G Ninja是让CMake读取上一级目录的CMakeLists.txt生成Ninja构建规则-G Ninja可以省略让CMake自动选择生成器但显式指定Ninja在Windows下最省心编译速度也比默认的MinGW Makefiles快不少。ninja就是真正执行编译等价于make第一次编译会拉取并编译LVGL源码大概几分钟之后增量编译就很快了。如果CMake报找不到SDL2先把报错信息完整读一遍多半是下面两种情况你用的是MSVCSDL2没有加入系统PATH你用MSYS2时忘了装mingw-w64-x86_64-SDL2装成了别的版本MSYS2的软件包分MSYS和MINGW两套必须装mingw-w64-x86_64前缀的那个SDL2否则终端里编译时头文件路径对不上。如果你是从系统路径手动引入SDL2可以临时指定CMAKE_PREFIX_PATH来告诉CMake去哪里找cmake .. -DCMAKE_PREFIX_PATH/path/to/your/SDL2一般情况下不建议走这一步MSYS2装好之后CMake自己就能找到。3.2 运行验证与交互操作编译完成之后会在build目录下生成一个可执行文件名字通常是main或者带.exe后缀取决于平台。直接运行./main等一下一个带LVGL默认widgets demo的窗口就会弹出来。能看到这个窗口意味着整条链路已经通了。你可以用鼠标在窗口里点选、滑动、拖动滚动条体验一下LVGL控件的实际手感。窗口里的鼠标行为基本等价于真机上的触摸行为这也是PC仿真最方便的地方——鼠标够精确什么控件都能试到。运行的过程中注意观察右上角如果你的LV_USE_PERF_MONITOR打开了会看到FPS和CPU占用率实时刷新。在自带demo里FPS一般很高至少几十帧这是PC的资源差不代表真机效果参考价值在于“这个demo在你的目标真机配置下能不能跑得动”等移植到真机再实测一遍。退出程序直接关窗口或者CtrlC结束终端进程都行。这套验证流程跑通之后你已经拥有一个“一次配置、长期复用”的LVGL调试环境了。接下来最重要的一件事是把默认demo换成你自己真正的UI代码进入实际项目开发节奏。3.3 把默认Demo换成自己的测试页面main.c里的核心逻辑大致是int main(int argc, char *argv[]) { lv_init(); // 初始化SDL显示和输入驱动 // 调用 lv_demo_widgets() 或 lv_demo_music() while (1) { uint32_t time_till_next lv_timer_handler(); SDL_Delay(time_till_next); } }把lv_demo_widgets()这一行注释掉换成你自己写的UI初始化函数即可。我建议先写一个最小页面验证工程链路没问题再逐步往里加内容。比如在工程里新建一个my_ui.c或者直接在main.c里加函数都可以先放一个最简单的页面#include lvgl/lvgl.h static void btn_event_cb(lv_event_t *e) { lv_obj_t *state_label lv_event_get_user_data(e); lv_label_set_text(state_label, Clicked!); } void my_ui_init(void) { lv_obj_t *scr lv_scr_act(); lv_obj_t *container lv_obj_create(scr); lv_obj_set_size(container, 280, 420); lv_obj_center(container); lv_obj_t *title lv_label_create(container); lv_label_set_text(title, PC Simulator Test); lv_obj_align(title, LV_ALIGN_TOP_MID, 0, 20); lv_obj_t *state lv_label_create(container); lv_label_set_text(state, No click yet); lv_obj_align(state, LV_ALIGN_CENTER, 0, 0); lv_obj_t *btn lv_btn_create(container); lv_obj_align(btn, LV_ALIGN_BOTTOM_MID, 0, -30); lv_obj_add_event_cb(btn, btn_event_cb, LV_EVENT_CLICKED, state); lv_obj_t *btn_label lv_label_create(btn); lv_label_set_text(btn_label, Click me); lv_obj_center(btn_label); }这段代码创建了一个容器容器里放了一个标题、一个状态标签和一个按钮按钮点击后状态标签的文本会改变。把它接到main.c里重新编译运行就能看到一个可交互的页面了。这里提醒一句API版本问题LVGL 8.x和9.x在部分控件上有差异比如lv_btn_create在9.x里改名成了lv_button_create。我上面这段是按较新的LVGL写的如果你的工程拉下来的版本不同编译报错时先查一下当前代码版本不要硬改。你可以看lvgl/version.h里的宏LVGL_VERSION_MAJOR是多少就按哪个版本来写API。这个小页面跑通之后你就可以把真实项目里的页面一个个搬进来调试了整个环境的搭建到此基本完成后面就是纯业务开发。4. PC仿真调试的核心操作技巧4.1 分辨率、色彩深度和缓冲区配置很多人搭好环境之后以为改分辨率就是在lv_conf.h里把LV_HOR_RES改成目标值就完事然后编译运行发现窗口大小没变化或者显示区域只有左上角一小块就开始怀疑人生。实际上前面已经提过SDL窗口的实际大小由lv_drv_conf.h决定这两个文件的改动必须成对出现。具体来说假如目标屏幕是800x480你需要lv_conf.hLV_HOR_RES改成800LV_VER_RES改成480LV_COLOR_DEPTH根据屏幕接口改成16或32lv_drv_conf.hSDL_HOR_RES改成800SDL_VER_RES改成480改了之后重新编译才是一次完整的分辨率切换。缓冲区这边说明一下LVGL内部通常需要至少一个屏幕大小的颜色缓冲区LV_COLOR_DEPTH16时320x480的屏幕一个缓冲就是320x480x2字节约300KB。PC仿真时这个内存不值一提但在STM32这类MCU上300KB可能整个RAM都不够了。所以仿真阶段验证到UI没问题后真机上要重点检查这几百KB的缓冲与MCU RAM的匹配情况必要时通过减少分屏刷新区域LVGL支持部分flush、降低色深来缓解。PC仿真虽然不会暴露这个问题但你可以通过LV_MEM_MONITOR和LV_USE_MEM_MONITOR观察界面对象本身消耗的内存这有助于预估真机内存需求。4.2 中文字体显示全流程中文字体是LVGL开发里绕不开的一关也是PC仿真阶段最应该提前解决的问题。如果不做任何处理界面上所有中文都会变成方块。原因不复杂LVGL自带的默认字体是英文的Montserrat字库里根本没有中文字符的glyph渲染时自然只能画个方块占位。最快验证中文是否可行的办法是打开lv_conf.h里的这个宏#define LV_FONT_SIMSUN_16_CJK 1然后在你需要显示中文的label上把字体设为这个内置字体lv_obj_set_style_text_font(label, lv_font_simsun_16_cjk, 0);重新编译运行中文就能正常显示了。但注意宋体16px的效果比较朴素而且只有一种字号不适合最终产品。所以这个宏一般只用来“验证中文功能通没通”后续需要换更好看的字体、更灵活的字号就用字体转换工具生成自定义字体。LVGL官方提供了在线字体转换工具和命令行工具lv_font_conv核心参数有三个字体文件选择一个ttf/woff字体注意版权推荐思源黑体、阿里巴巴普惠体这类开源字体字符范围不要全选全选意味着把几万个常用汉字全部转成glyph生成的C文件巨大编译时间暴涨MCU的Flash也扛不住。正确做法是只包含你用到的汉字加上ASCII再加上可能需要的标点符号。如果界面里有几百个汉字就挑这几百个字符用工具里的字符预览逐个加上去BPP抗锯齿级别bpp1是纯黑白体积最小bpp4是最高抗锯齿体积最大。一般bpp2或4即可看你的显示效果要求转换完成后会生成一个C文件像my_font_16.c里面定义了一个lv_font_t结构体把这个文件加入工程编译然后在代码里extern声明再通过lv_obj_set_style_text_font调用即可。仿真阶段推荐先在PC上确认字体效果和大小都满意了再去真机上适配否则真机上每次烧录看效果太痛苦。4.3 打开性能监视器评估界面复杂度lv_conf.h里有这样两个开关平时开发建议一直开着#define LV_USE_PERF_MONITOR 1 #define LV_USE_MEM_MONITOR 1打开后仿真窗口的右上角会显示两行数字。第一行是帧率FPS和所有子系统的总CPU占用率第二行是LVGL内存池的使用情况比如“mem35,840/65,536”这样的格式。这行数据非常有用它能直观反映当前界面的复杂度。我举个例子我加了一个带阴影的圆角卡片页面PC上FPS从60掉到了30左右内存占用也涨了不少。虽然PC性能足够强看起来还是流畅但这个跌幅确实说明阴影、透明叠加这些视觉效果代价不低真机上大概率会卡。于是我直接在仿真阶段把阴影关掉改用描边代替界面整体轻了一截后期真机测试果然就稳了。PC仿真虽然不能给出真机的绝对帧率但能给出相对的性能变化趋势这个趋势足以指导你是否需要给界面做“瘦身”。内存监视器也很有参考价值。LVGL的对象占用内存比想象中大一个带样式的容器可能就几百字节页面一复杂几KB内存悄无声息就没了。在PC上先看总内存需求心里有个底再去真机上核对RAM是否够用能避免很多上线前的突发问题。4.4 容器、弹窗和动画的调试建议实际项目里最常见的界面不是简单的按钮加标签而是容器布局、弹窗交互和动画切换。这些效果在PC仿真里调试比真机容易太多。容器和Flex布局是LVGL 8之后的重点特性PC仿真可以非常直观地验证每一行代码的布局效果。我的习惯是每次修改容器的大小、内边距、Flex方向之后马上编译看窗口效果基本一两秒就能看到变化比看代码脑补布局快得多。如果你发现控件在窗口里位置和预期不符优先检查容器的默认padding和控件之间的marginLVGL的默认值可能导致你怎么align都不对的感觉。弹窗调试时重点要验证的是打开/关闭的时序和焦点行为。PC上用鼠标点击遮罩外区域触发关闭这个交互在真机上同样要用触摸实现提前在仿真环境里把事件回调理顺能省去真机上一遍遍复测弹窗流程的麻烦。动画调试时我会刻意去观察动画曲线和时长是否协调比如一个页面切换动画时长设200ms还是300ms在PC上一试便知。顺便说一句如果同一个动画在PC上跑起来都很生硬那多半是动画缓动函数选得不好跟硬件性能无关这时候调整缓动函数比优化底层渲染更有效。5. 常见问题与排查技巧实录5.1 编译期问题速查表问题现象可能原因解决办法fatal error: lvgl/lvgl.h: No such file子模块未初始化执行git submodule update --init --recursiveSDL2/SDL.h: No such fileSDL2开发库未安装或路径未配置Linux装libsdl2-devWindows用MSYS2 pacman装mingw-w64-x86_64-SDL2undefined reference toSDL_mainSDL2main链接顺序问题或main签名不对检查main函数参数是否为int argc, char *argv[]检查链接库顺序编译报错一堆undeclared identifierLVGL版本与示例代码API不一致查lvgl/version.h确认主版本按对应版本API修改链接时报重复定义多个demo文件同时被编译检查LV_USE_DEMO_*开关只保留需要的一个CMake无法生成构建文件CMake版本太低或Ninja未安装升级CMake到3.10以上安装ninja-build编译问题通常信息比较明确报什么错就按什么方向搜。我看很多新手卡在第一步就急着百度其实把报错信息完整读一遍是最快的排查方式“No such file”就是缺文件“undefined reference”就是链接库不对对症下药比漫无目的地刷帖子效率高得多。5.2 运行期问题速查表问题现象可能原因解决办法窗口黑屏或只有背景色SDL窗口刷新未触发确认main循环里调用了lv_timer_handler()检查SDL flush回调是否触发SDL_RenderPresent中文显示为方块CJK字体未启用或自定义字体缺字符打开LV_FONT_SIMSUN_16_CJK转换字体时确认包含所需字符窗口大小与设置的屏幕分辨率对不上lv_conf.h与lv_drv_conf.h分辨率不一致同时修改两处分辨率定义重新编译点击位置偏移SDL窗口缩放后坐标映射问题检查SDL_ZOOM设置不要同时用系统缩放和SDL缩放显示区域只有左上角一部分色深或缓冲区大小配置不匹配检查LV_COLOR_DEPTH与SDL_TRUE_COLOR是否联动正确运行几秒后程序崩溃LVGL内存池耗尽对象创建失败增大LV_MEM_SIZE检查是否有对象泄漏运行期黑屏这个问题我特别说明一下。lv_sim_vscode_sdl正常情况下窗口是能直接显示内容的如果只有背景色什么都没有最常见的原因是lv_conf.h里某个功能配置冲突了或者在main.c里加了自己的逻辑堵住了事件循环。我遇到过一例为了加帧率统计在while循环里加了一个SDL_Delay(50)结果LVGL的timer_handler被拖慢到1帧都不到看起来就像是黑屏。排查时可以先把所有自定义代码撤掉确认默认demo能跑再逐行加回自己的逻辑。5.3 从PC仿真到真机移植的衔接经验这部分算是我这次项目里最有价值的体会。PC仿真调试完成后UI代码搬回真机其实没有想象中那么难但有几个地方必须提前留意。UI代码与驱动代码分离。这是最重要的一条。从一开始写界面时就不要在UI代码里混入任何和SDL、STM32、SPI相关的驱动逻辑。UI文件只调LVGL的API底层走LVGL提供的回调接口比如display_flush、touchpad_read。这样仿真环境里这些回调由SDL实现真机里换成真机驱动实现UI主体部分一个字节都不用改。色深务必提前对齐。如果真机屏幕是RGB565而仿真时用了LV_COLOR_DEPTH 32那颜色在PC上看起来跟真机会有不少偏差尤其是一些渐变和半透明效果失真很大。建议仿真一开始就把色深设成和真机一致别等后期再改。真机上跑LVGL基础demo通过之后再接你的业务代码。很多工程师喜欢直接把自己的代码拷进新移植的LVGL工程一次编译通过就算完事。但我的建议是先在真机上跑通lv_demo_widgets这种官方demo确认底层驱动和LVGL本身没有硬件层面的问题再把你PC上验证过的UI代码整体搬过去。一次只隔离一个变量出问题时排查范围小很多。性能预期的校准。PC仿真帧率再高也不能直接推导出真机帧率但PC上各页面之间的相对性能差异是有参考价值的。如果某个页面在PC上就明显比别的页面掉帧严重这个页面到了真机上大概率也是重灾区提前优化它准没错。这次搭建最深的体会是PC仿真环境的价值不在“模拟”本身而在把整个UI开发节奏从“烧录-观察-等待”变成“编译-运行-所见即所得”。我现在凡是接到带屏的项目第一步永远是先拉一套LVGL仿真工程把界面原型、交互流程、字体、动画全部在电脑上调到满意再进真机。哪怕后面换屏、换主控UI部分几乎不用重写省下的时间相当可观。如果大家也打算搭建议把lv_sim_vscode_sdl这个工程先跑通再沿着文中提到的配置项一点点按自己的屏幕去改第一版不求多跑起来就是胜利。