1. LVGL与TouchGFX概述：两大框架的诞生背景、核心设计理念、开源协议对比

做嵌入式GUI开发这些年，我接触过不少图形框架。从早期的uCGUI，到后来的emWin，再到现在的LVGL和TouchGFX，说实话，选择越来越多，但选起来也越来越纠结。

这一章，咱们先聊聊这两个框架的“身世”。搞清楚它们从哪来、为什么而生、设计上有什么讲究，你才能判断哪个更适合你的项目。我个人习惯是，选框架之前先看它的基因——创始团队的背景往往决定了框架的走向。

1.1 LVGL的诞生：从个人项目到社区明星

LVGL的全称是Light and Versatile Graphics Library，轻量且通用。它的作者是匈牙利工程师Gábor Kiss-Vámosi，最初只是他个人的一个业余项目。

我记得2016年左右，嵌入式GUI领域还比较封闭。商业框架贵，开源的选择又少。Gábor当时在做一些MCU项目，发现市面上缺少一个既免费、又能在低资源单片机上跑得动的现代GUI库。于是他自己动手写了LittlevGL——也就是LVGL的前身。

为什么会叫“LittlevGL”？说白了，就是“小型的图形库”。后来社区壮大了，才改名叫LVGL。嗯，这里要注意，LVGL从诞生起就瞄准了资源受限的MCU，它的核心设计理念就是：用最少的资源，跑出最丰富的界面。

我在项目中遇到过最极端的情况——一个仅有32KB Flash的Cortex-M0芯片，硬是跑起了LVGL的仪表盘界面。当时同事都觉得不可能，但LVGL的帧缓冲模式和局部刷新机制确实做到了。这一点，TouchGFX就很难办到。

1.2 TouchGFX的诞生：从商业软件到ST生态王牌

TouchGFX的故事完全不同。它最初是一家瑞典公司开发的商业产品，目标很明确：为高端MCU提供媲美智能手机的UI体验。

2018年，ST意法半导体收购了TouchGFX，然后做了一件很聪明的事——把它免费开放给所有使用STM32的开发者。这一下，TouchGFX的用户量暴涨。

你想想看，TouchGFX的设计理念从一开始就不是“省资源”，而是“极致体验”。它支持硬件加速、双缓冲、动态帧率调节，甚至能跑出60fps的流畅动画。代价呢？对硬件的要求也高得多。

1.3 开源协议对比：选错了可能吃官司

协议这块，很多人不重视，但我在项目交付时吃过亏。曾经有一个商业项目，用了某个GPL协议的库，结果客户法务要求全部替换——那叫一个折腾。

咱们直接看对比表：

对比项	LVGL	TouchGFX
当前协议	MIT	ST商用许可（免费）
商用是否免费	是	是（仅限STM32平台）
是否要求开源	否	否
能否修改源码	可以	可以
平台限制	无	仅限STM32
法律风险	极低	低（但需遵守ST条款）

这里有个关键点：TouchGFX的免费许可只适用于STM32平台。如果你把TouchGFX移植到其他MCU上，哪怕代码是你自己写的，也可能面临侵权风险。我曾经见过一个团队，把TouchGFX跑在GD32上，结果被ST的法务函警告了。

1.4 知识体系总览：一张图看懂两大框架

下面这张SVG图，把LVGL和TouchGFX的核心差异梳理清楚了。我建议你保存下来，后面每学一章都可以回来对照看看。

1.5 我的选择建议

说了这么多，到底怎么选？我个人的经验是分三步走：

1. 先看硬件：Flash小于64KB、RAM小于8KB？别想了，直接LVGL。
2. 再看平台：非STM32平台？LVGL是唯一选择。STM32平台？两个都可以评估。
3. 最后看团队：团队熟悉C++、追求快速出效果？TouchGFX的拖拽式开发确实爽。团队更习惯C语言、需要深度定制？LVGL的灵活性更高。