3. TouchGFX核心概念
在正式进入 LVGL 迁移之前，必须先把 TouchGFX 的“骨架”吃透。TouchGFX 并不是一个简单的绘图库，而是一套围绕 Designer 可视化设计 与 MVP 架构 组织起来的完整 UI 框架。理解它的工作流与分层方式，才能在迁移时判断哪些代码可以平移、哪些需要重写、哪些应当彻底重构。
一、Designer 工作流：从画布到代码
TouchGFX Designer 是整套框架的入口。开发者在画布上拖拽控件、设置属性、定义交互，Designer 会把这些操作保存为 .touchgfx 工程文件，并自动生成 C++ 代码。其典型工作流如下：
- 在 Designer 中新建 Screen，拖入 Box、TextArea、Image、Button 等控件；
- 为控件设置位置、颜色、文本、图片资源等属性；
- 通过 Interactions 面板配置“点击按钮 → 切换屏幕 / 调用虚函数”等行为；
- 点击 Generate Code，Designer 生成
View、Presenter基类与资源文件； - 开发者在生成的
View与Presenter中补充业务逻辑； - 编译下载，在目标板上运行并迭代。
关键点在于：Designer 生成的是“骨架”，不是“全部”。它负责界面结构与交互绑定，业务逻辑必须由开发者手写。迁移到 LVGL 时，Designer 的可视化能力会被 SquareLine Studio 或手写代码替代，但“结构由工具生成、逻辑由人补充”的分工思路仍然成立。
二、MVP 架构：Model、View、Presenter 的职责边界
TouchGFX 采用 MVP（Model-View-Presenter）模式，把界面、数据和逻辑彻底分离。三者职责如下：
| 角色 | 职责 | 典型内容 |
|---|---|---|
| Model | 数据与业务状态 | 传感器数据、配置参数、通信结果 |
| View | 界面显示与用户输入 | 控件布局、动画、触摸事件 |
| Presenter | 协调 View 与 Model | 响应事件、更新数据、驱动界面刷新 |
View 不直接访问 Model，Model 也不感知 View。所有交互都经过 Presenter 中转。这种“单向依赖”让界面可以独立替换，也让业务逻辑可以脱离硬件测试。迁移到 LVGL 时，LVGL 本身没有强制 MVP，但你可以保留 Presenter 层，把 LVGL 的 lv_obj_t 操作封装在 View 中，从而延续原有架构。
三、Screen 与 View：一个屏幕，一个视图
在 TouchGFX 中，每个 Screen 对应一个 View 类。Designer 中新建的 Screen 会自动生成 Screen1View 和 Screen1Presenter。View 继承自 touchgfx::View，内部持有所有控件对象，并实现 setupScreen()、tearDownScreen() 等生命周期函数。
class Screen1View : public Screen1ViewBase
{
public:
virtual void setupScreen();
virtual void tearDownScreen();
virtual void handleTickEvent();
protected:
// 控件成员由 Designer 生成
};迁移到 LVGL 时，Screen 的概念对应“一个 lv_obj 容器”或“一个独立的 UI 模块”。LVGL 没有自动生成 View 基类的机制，因此需要手动建立“屏幕对象 + 初始化函数 + 事件回调”的结构。建议为每个屏幕建立独立的 .c/.h 文件，保持与 TouchGFX 类似的边界。
四、Transition 与 Interaction：屏幕切换与事件绑定
Transition 描述屏幕之间的切换动画，例如滑动、淡入淡出、覆盖。Interaction 描述“谁触发、触发什么、作用于谁”。在 Designer 中，Interaction 通常配置为：
- 触发源：Button 的 Clicked 事件；
- 动作：调用
gotoScreen2()或执行自定义虚函数； - 目标：切换屏幕或更新控件状态。
迁移到 LVGL 时，Transition 对应 lv_scr_load_anim() 等动画加载函数；Interaction 对应 lv_obj_add_event_cb() 注册的事件回调。TouchGFX 的 Interaction 是“配置式”的，LVGL 是“代码式”的，后者更灵活，但也更容易失控。建议在迁移时先列出所有 Interaction，再逐一映射为 LVGL 事件回调。
五、迁移视角：哪些概念可以平移，哪些必须重写
把 TouchGFX 的这套概念映射到 LVGL，可以得到一张清晰的迁移对照表：
| TouchGFX 概念 | LVGL 对应 | 迁移策略 |
|---|---|---|
| Designer 画布 | SquareLine Studio / 手写代码 | 重新设计，不逐像素照搬 |
| Screen / View | lv_obj 容器 + 模块文件 | 按屏幕拆分，保留边界 |
| Presenter | 无原生对应 | 手动保留中间层 |
| Model | 无原生对应 | 独立为数据模块 |
| Interaction | lv_obj_add_event_cb | 逐条映射为回调 |
| Transition | lv_scr_load_anim | 替换为 LVGL 动画 API |
六、常见误区与复盘
- 误区一：把 Designer 当成代码生成器。Designer 生成的是可编译骨架，业务逻辑必须手写；迁移时不要试图自动转换
.touchgfx文件。 - 误区二：View 里直接操作 Model。这会让界面与数据强耦合，迁移到 LVGL 后更难拆分。应坚持 Presenter 中转。
- 误区三：Interaction 全部堆在 Designer 里。复杂交互应下沉到 Presenter 的虚函数中，Designer 只保留简单绑定。
- 误区四：忽略 Transition 的生命周期。屏幕切换时的资源释放、定时器停止、事件解绑，在 LVGL 中同样需要显式处理。
复盘一句话：TouchGFX 的核心价值不在控件本身，而在于 Designer 工作流 + MVP 分层 + Screen/View 边界 + Interaction/Transition 机制 这四件事共同构成的工程结构。迁移到 LVGL 时，控件 API 会变，但这套结构思想应当被保留下来，成为 LVGL 工程的骨架。