手上有块带屏幕的板子却不知道怎么在上面跑出一个像样的界面或者已经在用 STM32CubeMX 配外设但一提到图形界面就头皮发麻觉得那是前端工程师才干的活如果你正好卡在这个位置那这篇文章就是给你写的。我最早接触 STM32CubeMX 的时候它还只是个帮人初始化时钟和引脚的“配置小工具”。后来项目越做越多发现 HMI、仪器仪表、家电面板这类需求几乎天天见光靠点灯和串口打印根本交不了差。直到把 TouchGFX 这套 GUI 框架和 CubeMX 配套使用之后我才算真正找到了一条从“能跑”到“好看”的实用路径——不需要从零写绘图引擎也不用纠结底层像素怎么刷。这篇文章会围绕“STM32CubeMX 作为工程底座 TouchGFX 作为界面引擎”这套组合把我实际做项目时踩过的坑、总结出的步骤、以及那些文档里不会明说的经验一起理清楚。你学完之后能拿它做什么快速验证 MCU 上的界面方案给现有产品套一个交互闭环甚至研究如何让界面帧率稳定不卡顿都可以往这个框架里装。适合正在做嵌入式产品原型、想给作品加交互界面的开发者也适合刚接触 TouchGFX 想少走弯路的新手。1. 工欲善其事STM32CubeMX 与 TouchGFX 的定位与协作逻辑很多人第一次听“CubeMX with TouchGFX”以为是一个工具其实它们是两个东西在配合干活。要理解这套玩法顺手得先把各自的职责边界划清楚。1.1 两套工具各承担什么角色STM32CubeMX 的核心价值是把 STM32 芯片那些复杂的寄存器初始化、引脚复用、时钟树配置、外设中断优先级这些工作从手写代码变成了图形化勾选。它生成的是 HAL 驱动层代码也就是你程序的“地基”。只要底层初始化对了上层再怎么折腾都有底气。TouchGFX 则是做界面渲染和交互逻辑的框架跑在芯片的 LCD 控制器和内存之上。真正让我觉得它好用的点在于它自带了一套 PC 端的界面设计器叫 TouchGFX Designer让你像拖拽控件一样把画面排出来处理字体、图片、动画和交互事件然后生成 C 代码。它不是在帮你画画而是在帮你生成能直接嵌进嵌入式工程里的 UI 代码。简单类比一下CubeMX 是水电工帮你把水管和电线铺好TouchGFX 是装修队负责把房间布置得能看、能住。两者的接口是一套约定好的代码结构只要在 CubeMX 里勾选启用 TouchGFX 的选项生成工程的时候它就会自动预留好 TouchGFX 的接入目录和调用点。1.2 版本兼容性与选型思路这套组合里最容易被新手低估的坑就是版本匹配。CubeMX 从某个版本开始内置了对 TouchGFX 的支持如果你从 CubeMX 里直接生成 TouchGFX 工程它会自动检查你的软件包版本和芯片支持情况。但我建议你不要盲目去官网下最新版每一个都装先确认你的开发板属于哪个系列。比如 STM32F746、STM32H743 这类带 LTDC 控制器和高性能核心的型号跑 TouchGFX 非常顺而像 STM32F103 这种老经典的板子虽然也能跑很简单的界面但是性能瓶颈很明显分辨率稍高一点就开始卡。选型的逻辑很简单先看 MCU 主频、Flash、RAM、是否带 TFT 控制器再决定你要跑多大的界面。我的建议是如果你要做彩色图形界面至少选带硬件 TFT-LCD 控制器的型号比如 STM32F429、STM32F746、STM32H750 这些。没有硬件控制器也不代表完全不能做你可以用 SPI 接口的屏但帧率和画面复杂度都要控制得很低适合显示几个数字或简单图标。另外CubeMX 里生成工程时会让你选择是否启用 TouchGFX Generator。只有在软件包安装正确的前提下这个选项才会出现在中间件栏里。装的时候注意版本对应别用 CubeMX 6.x 配一个特别老的 TouchGFX 包容易出现生成代码后各种各样编译错误。1.3 为什么需要“以 CubeMX 为底座”这种方式如果你只用 TouchGFX 的独立工程模板也不是不行但那样你等于放弃了 STM32CubeMX 帮你管理外设配置的巨大便利。尤其当你的产品除了界面还要处理按键、ADC 采样、通信协议、传感器数据甚至联网时“外设初始化 中间件管理 UI 渲染”统一由 CubeMX 牵头整体复杂度会下降很多。实际开发时我通常先在 CubeMX 里把所有外设都配置好再生成 TouchGFX 工程这样 TouchGFX 的代码会和 HAL 初始化代码共存在同一个编译环境下。之后无论是调整 GPIO、修改时钟频率还是换一个引脚都能回到 CubeMX 里可视化修改再重新生成代码。底层改动对 UI 的影响只在接口层面不会蔓延到界面内部逻辑。这种“底座先行”的模式长期项目维护时尤其受益。原因很简单嵌入式产品迭代过程中硬件改版几乎无法避免今天换个传感器明天加个通信接口后天给屏幕调下背光脉宽。如果每次改外设都要去翻 UI 代码那绝对会疯。以 CubeMX 为中心的工程结构让整个系统边界清晰UI 专心管界面外设专用驱动去处理硬件。2. 项目初始化用 CubeMX 快速搭建带图形能力的工程底座这一步是我们正式动手的开始。别急着打开 TouchGFX Designer先把地基打好后面才不会返工。2.1 创建工程前的关键选择打开 CubeMX在 MCU 选择器里挑一个支持片上 Flash 和 RAM 都足够大的型号。在这里我以 STM32F746G-DISCO 为例它板载了 4.3 寸 480x272 的 TFT 屏RGB 接口直接连到 LTDC是体验 TouchGFX 最省心的开发板之一。选定芯片后第一件事是配置时钟树。用内外部晶振配合 PLL把主频调整到实际支持的最高值。以 STM32F746 为例目标是把 SYSCLK 拉到 216MHz因为图形渲染不仅吃 CPU 计算还要考虑 LTDC 要持续刷数据到屏幕主频不够画面就会发虚、闪烁。接着要确认 GPIO 和 LTDC 引脚的映射。如果你的板子不是官方开发板而是自己画的板子这里就需要逐个核对屏的 RGB 线序、行场同步信号、像素时钟和数据使能信号是否和你 PCB 上实际布线一致。这个环节一旦接错画面不是花屏就是根本没有输出而且很难通过软件去排查。我当时自己画板子的时候就是在 LTDC 引脚映射上吃了大亏。明明是照着参考设计画的排线结果屏幕一直白屏最后拿着示波器一根一根量信号才发现 DE 信号数据使能接到了 PB1而 CubeMX 里默认映射的是 PE4白白折腾了两天。现在我的习惯是在画原理图之前先把 CubeMX 对应芯片的 pinout 打开逐个信号确认完再确定 PCB 走线方向。2.2 外设配置与时钟树设定图形界面不是孤立存在的肯定要跟用户、外设交互。我一般在初始化阶段就把常用的外设全部规划好哪怕一开始不用也先把框架搭好。以本项目为例需要配置的外设通常包括调试串口用于打印日志调试 UI 状态和内存占用。背光控制的 PWM 通道用于调节屏幕亮度。若干 GPIO用于状态指示灯、按键扫描。触摸屏使用的 I2C 接口比如常见的电容触摸方案用 I2C 连接。如果产品有联网需求预留以太网或 Wi-Fi 模块的接口。每个外设的初始化参数、中断优先级、DMA 通道在 CubeMX 里都有对应配置页面。我的经验是中断优先级这一栏一定要提前规划尤其当后续要跑 FreeRTOS 时触摸屏中断、定时器更新中断、串口接收中断的优先级不能乱设否则低优先级任务会被持续打断界面卡顿或触摸失灵是小事严重的会导致系统死锁。这里我把 CubeMX 中一些关键配置项列出来方便你在填写时有参考配置项推荐值说明SYSCLK216MHzF746越高越好图形渲染需要APB154MHz不宜超过芯片手册最大值APB2108MHz影响 LTDC 时钟LTDC 像素时钟约 6.5MHz10MHz根据屏规格计算过大会闪屏堆大小至少 0x2000TouchGFX 动态内存需求较高栈大小至少 0x1000FreeRTOS 任务默认栈可稍后调帧缓冲外部 SDRAM 区尽量别放内部 RAM当你在 CubeMX 里把这些配置完成后建议先不勾选 TouchGFX生成一次最基础的工程用串口打印或点灯确认系统能跑起来。确认无误后再逐步添加中间件和图形库。这样一旦后面出现问题你能快速判断问题出在系统底层还是 UI 配置上。2.3 堆栈与内存管理的提前储备内存规划是我在图形界面项目中最看重的一环。TouchGFX 的动画、图像缓冲和控件对象全是运行时动态分配的对内存要求比普通裸机程序高得多。STM32F746 内部有 320KB SRAM其中 64KB 是紧耦合内存 TCM另有 256KB 的 AXI SRAM。TouchGFX 的帧缓冲最好放在 AXI SRAM 中因为它同时被 CPU 和 DMA2D 访问访存效率更高。如果屏幕分辨率是 480x272使用 RGB565 格式一帧的大小约为 480 × 272 × 2 261120 字节约 255KB光帧缓冲就占据 AXI SRAM 一大半。所以单缓冲方案在内部 RAM 下勉强可行但如果是双缓冲做动画防撕裂就必须借助外部 SDRAM。因此我的建议是如果是评估阶段的板子内部 SRAM 够用如果是正式产品设计尽量给 MCU 挂一片外部 SDRAM。至于具体怎么在 CubeMX 里配置外部存储控制器 FMC后面在优化章节里再详细展开。2.4 开启 TouchGFX 集成选项到这一步CubeMX 的配置工作已基本完成。现在在中间件一栏中找到 “TouchGFX”勾选启用。CubeMX 会生成一个 TouchGFX 相关的外设配置并自动把 TouchGFX Generator 的模块加进工程树里。这里有一个细节TouchGFX 的时钟通常由 LTDC 提供但也支持通过定时器触发刷新。用 LTDC 的话图像数据直接从显存读取刷新率稳定用定时器的话控制更灵活适合特殊刷新场景。目前我见到的绝大多数案例都用 LTDC 方式稳定性最高。生成代码后你会在工程中看到一个名为TouchGFX的目录里面已经放好了touchgfx框架代码和generated目录。这意味着底座已经就绪就差一个 UI 设计师了。3. TouchGFX Designer 实操从设计稿到可运行界面打开 TouchGFX Designer你会看到它的操作界面其实很像一个轻量级的上位机设计软件。左边是控件面板右边是画布和属性栏。不用写一行代码就能把控件拖到屏幕上配置位置、颜色、纹理和交互动作。3.1 创建并关联你的第一个应用在 TouchGFX Designer 中新建项目时要选择芯片型号和开发板。它的板级选择列表里包含了 ST 官方的各类评估板选对应型号后会自动帮你配置好屏幕参数和引脚映射。如果你用的是自己画的板子就选择 “Custom” 模板手动填写屏幕分辨率、像素格式、刷新方式等参数。然后切回工程生成时用的 CubeMX确认 TouchGFX 集成版本与实际安装的 Designer 版本一致。我曾经因为电脑上装了新版的 TouchGFX Designer而 CubeMX 里缓存的软件包是最老的版本导致生成出来的代码无法编译。解决办法很简单去 CubeMX 的软件包管理器里更新 TouchGFX 到和 Designer 一致。在 Designer 中添加一个 Box 控件并填充背景色再用 Text 控件拉出一行字随便打点内容最后按 “Run Simulator” 跑一下你会看到它自带一个模拟器可以预览界面的实际渲染效果。这一步主要是验证工具链通不通。3.2 界面设计与资源管理界面的美观程度核心在资源准备。图片和字体都不是直接从 PC 端拷贝到板子里的而是 TouchGFX 在生成代码时把图片压缩、编码成适合 MCU 解码的格式再编译进 Flash 或者外部存储中。所以你在使用资源时要注意格式选择和大小控制。图片格式常用 RGB565 或 ARGB8888。RGB565 占用内存少一半适合无需透明效果的背景ARGB8888 可做透明混合但内存消耗巨大。我的建议是能在 ps 里提前抠好图的尽量少用实时透明效果。字体TouchGFX 支持用 TTF 字体文件生成字模表但它生成的是固定大小、固定的抗锯齿级别。中文界面特别要注意每个汉字都是一张像素图字体文件太大直接撑爆 Flash。我的做法是把界面里用到的文字全部整理到一个文本串里在 TouchGFX 中生成字模时只包含用到的字符能省下一大块空间。简单说触控屏上显示中文永远不要贪多。如果你只需要显示特定数字或状态优先用“数字字体”只包含 0~9、小数点、冒号等字符体积会小很多。控件TouchGFX 自带的控件足够用的按钮、滑块、进度条、图形基本覆盖常见需求。但每个控件都会消耗运行时内存尤其是控件还有一些状态图占用 Flash 偏多。所以一个界面里别堆几十个控件能复用的一定复用。关于资源管理我再分享一个实际经验使用 Designer 时它会自动帮你在assets/images目录下管理原始图片工程文件但最终的图片转换结果在生成源码时才确定。你在 pc 端改了图片直接替换原文件重新生成代码即可不需要手动去改生成后的二进制内容。这样在后期改版时非常方便。3.3 代码生成与整合回填界面设计完成后Designer 会生成一套 C 源码直接更新到 CubeMX 创建的工程目录下的TouchGFX/target和TouchGFX/generated中。你不需要手动拷贝文件CubeMX 的 TouchGFX 集成会自动完成这一步。不过CubeMX 生成工程后不要每次都直接从 Designer 里覆盖输出目录而是让 Designer 输出到 CubeMX 规定的目录内否则文件路径一乱编译就抓瞎。这个过程衔接得顺不顺取决于目录结构是否固定。我习惯这样管理Core/用户主程序、中断回调、外设驱动。TouchGFX/targetTouchGFX 与板级相关的初始化代码如屏幕驱动、触摸驱动。TouchGFX/generatedDesigner 根据设计自动生成的框架代码不要手动改。TouchGFX/gui每个界面的模型、视图、展示器等 C 文件。你在 Designer 里写的交互逻辑会映射到这里。如果把 UI 相关的业务逻辑全塞到 main 函数里那就完全失去了框架的优势。所有跟界面相关的逻辑应该尽量写在 TouchGFX 的 View 和 Presenter 类中这样你后续维护或者换界面时不用动底层驱动。4. 业务逻辑打通模型、控制器与 UI 的数据交互TouchGFX 的界面代码采用了一种类似 MVPModel-View-Presenter的架构理解这套结构是掌握它的核心。它解决了一个具体问题UI 代码和业务逻辑如何不纠缠在一起。4.1 TouchGFX 的 MVP 架构速览你打开TouchGFX/gui目录后会看到每个界面都有一个同名文件夹里面有几个关键类Model全局数据模型保存跨界面共享的数据例如传感器读数、系统状态。ModelListener用于 Model 向 View 通知数据变化的接口。View当前界面的视图组件直接管理屏幕上控件的显示和交互。Presenter视图和模型之间的桥梁处理界面事件并更新数据。Screen整个界面的组装器把 View、Presenter 和关联的 UI 控件连接起来。这套逻辑和 web 前端的 MVC 有点像只是具体形态不同。View 只负责展示和接收用户操作Presenter 负责决策和分发Model 负责数据管理。合理依赖这套分层代码会非常清爽。4.2 从外设到 UI数据怎么流动举个实际的例子。假设你有一个温度传感器通过 ADC 采集数据要把读数实时显示到界面上的 Text 控件里。流程是ADC 采样完成后数据先被写到某个全局变量中Model 类定期读取该变量然后调用modelListener-temperatureUpdated(value)通知当前界面。当前界面的 View 在接收到这个回调之后调用temperatureText.setValue(value)更新控件显示。在这个过程中外设的中断回调不需要认识 View 是谁View 也不需要知道 ADC 怎么配置。只要你把数据变化的通知路径打通整个系统的耦合度就降下来了。刚上手一定不要越过这套机制直接在外设回调里改控件属性短期能用后面界面一多绝对乱套。4.3 实战一个简单温湿度数据显示的例子为了更直观我拿一个实际项目的简化版来描述这个流程。假设我做了个小型环境监测设备主控通过 I2C 读取温湿度传感器 SI7021每隔 1 秒更新一次界面。第一步在 CubeMX 里把 I2C 配好并生成一个sensor_read()函数读取原始数据。第二步在 Model 类的tick()方法中每 1000ms 调用一次sensor_read()将转换后的温湿度值保存到 Model 的成员变量中然后调用modelListener-onSensorDataReady(temp, humidity)。第三步在 View 中实现onSensorDataReady虚函数将值格式化后赋给两个 Text 控件。void MainView::onSensorDataReady(float temperature, float humidity) { Unicode::snprintf(temperatureTextBuffer, 16, %d.%d, (int)temperature, (int)(temperature * 10) % 10); Unicode::snprintf(humidityTextBuffer, 16, %d.%d, (int)humidity, (int)(humidity * 10) % 10); temperatureText.setWildcard(temperatureTextBuffer); temperatureText.invalidate(); humidityText.setWildcard(humidityTextBuffer); humidityText.invalidate(); }关键点有两处一是要用Unicode::snprintf这类 TouchGFX 的格式化函数而不是标准 C 的sprintf因为后者不一定适合嵌入式环境二是调用invalidate()通知图形库该区域需要重新绘制否则即使数据变了界面也不刷新。很多新手卡在“数据变了但界面不更新”上其实就是漏了invalidate()这一步。如果不调用它TouchGFX 不会自动重绘界面像是画面定格了一样。而动画控件、滑条这类自带动效的控件内部会自动 invalidateText 和 Box 这类静态控件必须手动触发。5. 性能与感官优化把界面做得又稳又流畅一个界面能跑起来和能跑得流畅完全是两个世界。我见过不少项目功能都实现了就是拖影、闪烁、触摸不跟手观感极差。这节讲讲我在实际调优中收获比较大的几个方向。5.1 影响流畅度的核心指标最直接的是帧率也就是每秒画面刷新多少次。TouchGFX 里有一个帧率统计功能在调试模式下会以宏开关的形式编译进代码你可以用串口工具把它打出来。正常情况下480x272 分辨率的 RGB565 屏帧率至少要跑到 25fps 以上才觉得“不卡”。如果低于 20fps拖影和撕裂感会非常明显。帧率不是越高越好因为每帧渲染都要消耗 CPU 和带宽帧率过高负载变大可能导致其他外设处理不及时。我一般会把帧率控制在 30fps 左右留出余量给后面的通信、存储等操作。另一个指标是单帧渲染耗时。在客户端没有太多动画的情况下TouchGFX 会自动触发局部刷新只重绘变化区域以降低 CPU 负载。而如果动画连续播放它会切换到全屏刷新。你会发现界面滚动时明显卡顿大概率是单帧渲染耗时太高需要优化绘图逻辑。TouchGFX 提供了渲染计时器和分析工具可以在模拟器里直接看到每一帧的耗时分布。5.2 缓存与内存优化当你的界面设计复杂或有大量图片要加载时Flash 和内存往往同时吃紧。TouchGFX 支持的缓存机制主要有三种帧缓冲缓存、局部缓存和字体缓存。帧缓冲缓存就是双缓冲或三缓冲。双缓冲虽然多占一帧内存但能避免撕裂。如果你有外部 SDRAM强烈建议使用双缓冲体验提升非常明显。局部缓存适合地图、图表这类需要滚动查看的场景。TouchGFX 允许你在一个控件内部开辟一块局部缓存让它的内容在滚动时不会触发全屏重绘。字体缓存中文界面尤其有用。将常用的中文文字一次性生成到缓存中后续控件复用同一个字模时不必再从 Flash 读取显示速度能提升不少。内存方面我见过最有效的一招是“资源按需加载”。TouchGFX 允许你把图片资源放在外部存储比如 SD 卡、外部 Flash 芯片中运行时按需读取到内存而不是全部打包到内部 Flash。这个方案的代价是会增加底层读取驱动的复杂度但在大界面、多图片产品上几乎是必选项。我实际做过一个需要显示多张 480x272 全屏图片的方案每张图以 ARGB8888 格式存储约 500KB十张图就是 5MB内部 Flash 根本装不下。后来把所有图片放到外部 SPI Flash 中用 TouchGFX 的BitmapDataReader接口实现按需读取才终于让产品跑起来。5.3 一些画质与手感上的小技巧像素格式如果你的屏色彩表现一般没必要上 ARGB8888RGB565 视觉差别不大内存却能省一半。双缓冲切换TouchGFX 的动态位图切换默认在 vsync 信号期间进行。如果你发现画面撕裂出现在某一半区域试着调整 LTDC 的中断优先级让绘图切换与 LCD 扫描同步。触摸响应触摸的响应延迟通常不只是 TouchGFX 的事。先从底层确认触摸芯片的中断是边沿触发还是电平触发再检查 I2C 读取是否被其他高优先级任务阻塞。界面帧率过低时尽快排查是否有多个大尺寸全屏控件同时执行透明混合。透明混合是渲染性能杀手能少用就少用。细节优化无止境但我建议先抓主要矛盾先保证帧率稳再抠画面细节。在主频和内存条件有限的情况下宁可画面简单一点也要保证交互的流畅度。用户能接受朴素但很难接受“卡得要死”的产品。6. 常见问题与排查技巧实录整个开发流程中我踩过不少坑也帮同事解过不少。把高频问题整理成一个速查表按图索骥排查能省下大量时间。6.1 编译问题速查现象最可能原因解决方向提示找不到touchgfx头文件生成的工程未正确关联 TouchGFX 目录检查 CubeMX 中间件是否启用 TouchGFX 和软件包版本链接时报内部 Flash 不足图片/字体资源过多压缩图片位数、使用位图缓存外部化、只生成用到的字模编译报undefined reference to _estack等加壳样式错误链接脚本未包含 TouchGFX 生成的目标文件在 CubeMX 重新生成代码不要手动删除 TouchGFX 相关文件控件方法在 View 中找不到Designer 重新生成代码后新控件未同步到工程在 Designer 改动控件后重新按步骤生成并覆盖到 CubeMX 工程目录Unicode相关函数未声明缺少触摸屏 GUI 类头文件引入touchgfx/Unicode.hpp并确保 include 路径完整6.2 运行时异常排查思路现象排查方向白屏检查 LTDC 初始化、时钟配置、帧缓冲地址是否正确花屏检查分辨率、像素格式是否与屏一致LTDC 与帧缓冲的格式是否匹配触摸失灵检查 I2C 线路、触摸芯片中断配置、CubeMX 中引脚映射界面卡顿掉帧查看是否单缓冲模式 大动画同时触发尝试双缓冲或降低动画复杂度随机死机排查内存溢出、任务优先级低、外部中断和 UI 线程并发冲突如果你的问题是“触摸没反应”我通常会先做一个测试在 TouchGFX 的模拟器里运行同一个界面看触摸控件是否有反应。如果模拟器正常板子不正常那就说明问题在驱动层或引脚配置如果模拟器也不正常说明你在 Designer 里的事件绑定根本没成功。6.3 我用过最省事的一套调试器调试 UI 一定要善用 TouchGFX 的模拟器。它的运行环境是 PC所以很多和硬件无关的问题在桌面上两三分钟就能定位比如控件布局重叠、文字大小不当、事件绑定出错。等模拟器上确认没问题再烧到板子里调试时基本只剩硬件相关的问题。在板子上我会串口输出HAL::getInstance()-getFrameBuffer()相关的调试信息或者直接在主循环里周期打印剩余堆大小。面板程序跑久了堆吃紧是常态能监控才能及时发现内存泄漏。如果你用的芯片支持 SWO 引脚跟踪系统输出比 UART 好用得多。虽然配起来多花一点时间但在查帧率、渲染耗时这类精确指标时SWO 的输出实时性不是普通串口能比的。调试期间我还会故意给 TouchGFX 帧缓冲地址加一个偏移量往地址里写一个特定的模式值。如果屏幕某个区域显示了这个模式值说明 DMA2D 和 LTDC 的读写协同没有问题反之就是总线或时序配置的问题。这一招在很多疑难杂症排查中救过我。7. 从开发板到产品的几个现实提醒很多人把 Demos 跑通就以为万事大吉但真正量产时还会遇到一批问题。这里聊几个我在实际项目中的感想。第一个提醒是屏幕尺寸和分辨率决定了内存和 Flash 的天花板。虽然你现在可能只是做一个原型但产品最终形态一旦定了分辨率千万别在开发中期随意升级分辨率。因为底层缓存、图片资源、LTDC 时序都要跟着变改动成本可能比重新做一版还高。第二个是所有 UI 体验的优化都建立在稳定可靠的外设驱动上。如果触摸驱动连“点按”都不稳定或者 I2C 上拉电阻值不匹配TouchGFX 再怎么调动画调字体也白搭。先保证底层驱动扎实了再谈界面。第三个是组件化思维要在早期建立。TouchGFX 支持自定义控件而且一个自定义控件可以复用到不同界面中去。界面不是画一张图贴上去而是由可维护的组件拼装出来的。你在开发过程中一定会反复修改组件化能让你改得动、撤得回。最后再分享一个小技巧TouchGFX 的截图功能。调试阶段要记录界面异常或者给团队同步 UI 进展时别拿手机拍屏幕直接在 TouchGFX 的模拟器或板级代码里调用截图接口把当前渲染图像直接保存下来。一张准确无误的截图比十张拍摄图都管用而且还能作为回归测试的基线方便不同阶段的版本对比。玩 STM32CubeMX 配 TouchGFX 这件事学会容易做精难。我个人的体会是整个链条的价值并不在某个单点上而在于它把嵌入式系统里最难搞的界面部分从“手工拼像素”变成了“设计驱动、代码生成”的高效流程。多拿几个实际项目练手你会越来越喜欢这种把界面玩出花的感觉。