1. LVGL与TouchGFX概述：两大框架的诞生背景、核心定位、市场占有率对比、开源协议差异
做嵌入式GUI选型，我见过太多团队在LVGL和TouchGFX之间反复横跳。说实话，这两个框架我都深度用过，踩过坑也填过坑。今天咱们就从头捋一捋，看看它们到底是怎么来的，各自想解决什么问题，以及——你该在什么场景下选谁。
1.1 诞生背景：一个从社区长出来，一个从商业打磨出来
LVGL（Light and Versatile Graphics Library） 的故事挺有意思。它最早叫LittlevGL，2016年由一位匈牙利工程师Gábor Kiss-Vámosi发起。我当时关注它的时候，它还只是个在GitHub上几百星的小项目。为什么它能火？说白了，当时嵌入式GUI领域缺一个「轻量、开源、能跑在MCU上」的通用方案。STemWin收费，emWin授权复杂，uCGUI老态龙钟。LVGL正好填补了这个空白。
TouchGFX 的出身完全不同。它2014年由瑞典公司Draupner Graphics开发，一开始就是商业软件，主打「高性能、高帧率、硬件加速」。我记得2018年ST收购TouchGFX时，圈内不少人觉得意外——一个收费的GUI库被芯片厂商买下来免费提供，这操作确实少见。但ST的算盘很明白：用TouchGFX绑定STM32生态，让开发者离不开他们的硬件。
核心差异一句话总结： LVGL是社区驱动的「万金油」，什么芯片都能跑；TouchGFX是ST生态的「性能尖兵」，专为STM32优化。
1.2 核心定位：你要的是「能跑」还是「跑得漂亮」？
这两个框架的定位差异，我习惯用一个比喻：LVGL像瑞士军刀，TouchGFX像专业厨刀。
LVGL 的核心定位是：轻量、可移植、功能全面。它能在几十KB RAM的MCU上跑起来，支持20多种输入设备，控件库超过40个。我曾在Cortex-M0+上跑过LVGL，虽然帧率只有20fps左右，但该有的按钮、滑块、图表全都能用。它的设计哲学是「给你所有工具，你自己组装」。
TouchGFX 的核心定位是：高性能、低功耗、硬件加速。它依赖ST的Chrom-ART图形加速器和LTDC控制器，能轻松跑到60fps。它的设计哲学是「帮你把每一帧都优化到极致」。我在一个STM32F769项目上用TouchGFX做仪表盘，动画流畅得像手机App——代价是换芯片？不存在的，因为TouchGFX只支持STM32。
| 对比维度 | LVGL | TouchGFX |
|---|---|---|
| 最小RAM需求 | ~8KB（无缓冲区） | ~64KB（建议） |
| 最小Flash需求 | ~32KB | ~128KB |
| 硬件加速 | 可选（通过DMA2D） | 强制（依赖ST硬件） |
| 目标MCU | ARM、RISC-V、ESP32等 | 仅STM32 |
| 控件数量 | 40+ | 30+ |
| 动画引擎 | 内置 | 内置+硬件加速 |
我的建议： 如果你的产品还在选型阶段，不确定用哪家MCU，先选LVGL。等硬件定下来再考虑要不要切TouchGFX。我见过太多项目因为「先选了TouchGFX，后来发现ST芯片缺货」而被迫重写UI——那叫一个酸爽。
1.3 市场占有率：谁在用，用在哪？
说实话，精确的市场占有率数据很难拿到，因为嵌入式GUI不像手机OS那样有权威统计机构。但我根据GitHub星数、社区活跃度、招聘需求、以及我接触过的项目，可以给你一个大致判断。
LVGL 在GitHub上有超过15k星，贡献者超过300人。它的用户群体非常分散：智能家居、工业HMI、医疗设备、消费电子……几乎覆盖所有嵌入式GUI场景。我去年参加Embedded World展会，看到至少10家展商在用LVGL做产品原型。
TouchGFX 的GitHub星数约5k，但它的用户集中在ST生态内。ST官方数据显示，TouchGFX的激活用户超过2万。它的典型场景是：需要高帧率动画的消费电子，比如智能手表、家电触摸屏、车载仪表盘。我有个朋友在做扫地机器人的触控面板，他们选TouchGFX就是因为「滑动菜单必须60fps，不然用户会觉得卡」。
1.4 开源协议差异：别让许可证卡住你的产品
协议这块，我吃过亏。曾经有个项目，团队用了某个开源库没仔细看协议，产品卖到欧洲后被要求公开全部源码——那叫一个狼狈。所以协议一定要在选型阶段搞清楚。
LVGL 使用 MIT 许可证。这意味着你可以自由使用、修改、分发，甚至闭源商用。只需要保留版权声明即可。说白了，MIT是最宽松的开源协议之一，对商业产品非常友好。我自己的几个产品都用LVGL，从来没担心过协议问题。
TouchGFX 的情况复杂一些。ST收购后，它采用 ST 自己的软件许可协议（SLA）。对于大多数开发者来说，只要你的产品使用STM32芯片，就可以免费使用TouchGFX——包括商用。但要注意几个坑：
- 不能脱离ST硬件：协议明确禁止在非ST芯片上使用TouchGFX
- 衍生代码归属：你基于TouchGFX开发的UI代码归你，但TouchGFX库本身的修改需要遵循ST的贡献协议
- 技术支持限制：免费版本只提供社区支持，企业级支持需要额外付费
| 协议维度 | LVGL (MIT) | TouchGFX (SLA) |
|---|---|---|
| 商用闭源 | 允许 | 允许（限ST芯片） |
| 修改后闭源 | 允许 | 允许（需保留版权） |
| 硬件绑定 | 无 | 仅STM32 |
| 版权声明要求 | 必须保留 | 必须保留 |
| 企业支持 | 社区+商业公司 | ST官方付费支持 |
我曾经踩过的坑： 有个客户选了TouchGFX做智能家居面板，产品开发到一半，ST芯片缺货涨价300%。想换国产芯片？TouchGFX协议不允许。最后只能重写UI到LVGL，多花了两个月。所以我的建议是：如果你不确定供应链稳定性，优先选MIT协议的LVGL。
1.5 小结：选型前的灵魂三问
在进入后续章节的详细对比之前，我建议你先问自己三个问题：
- 我的硬件确定了吗？ 如果还没定，或者可能换芯片，选LVGL。
- 我需要60fps动画吗？ 如果只是按钮、列表、图表，LVGL够用；如果是滑动菜单、3D效果、游戏UI，考虑TouchGFX。
- 我的团队熟悉什么？ LVGL用C语言，TouchGFX用C++。如果团队C++经验不足，LVGL的学习曲线更平缓。