3. 多页面架构概述
在嵌入式 GUI 开发中，界面往往不是孤立的一张画面，而是由开机画面、主菜单、参数设置、运行监控、报警提示、数据记录等多个界面共同组成。TouchGFX 作为面向 STM32 等 MCU 的图形框架，提供了两种典型的界面组织方式：单页面架构与多页面架构。理解二者的差异，是设计可维护、可扩展人机界面的第一步。
一、什么是多页面架构
多页面架构是指将整个应用拆分为若干个相对独立的界面单元，每个界面单元称为一个“页面”（Screen 或 View），由统一的页面管理器负责页面的创建、切换、销毁与生命周期调度。每个页面只关注自身的显示内容、交互逻辑和局部状态，页面之间的跳转通过导航接口完成，而不是把所有控件堆叠在同一个画布上。
在 TouchGFX Designer 中，多页面架构通常表现为多个 Screen 并存，配合 Model、Presenter、View 三层结构（MVP 模式）进行解耦。页面切换时，框架会调用当前页面的退出逻辑和新页面的进入逻辑，从而实现资源的按需加载与释放。
二、单页面与多页面的区别
单页面架构把所有控件放在同一个 Screen 中，通过显示/隐藏、位置移动或透明度变化来模拟界面切换。它实现简单，适合界面数量少、逻辑轻量的场景；但当界面增多时，控件数量膨胀、状态耦合严重、代码难以维护。多页面架构则通过页面隔离，把复杂度分散到各个页面内部，整体结构更清晰。
从图中可以看出，单页面架构把多个功能区域塞进同一个 Screen，靠显隐控制切换；多页面架构则把每个功能区域独立成页，由页面管理器统一调度。前者像“一间大房间用屏风隔断”，后者像“多个独立房间由走廊连接”。
三、适用场景与设计原则
选择哪种架构，取决于界面数量、交互复杂度、内存预算和团队协作方式。下表给出典型判断依据：
| 对比维度 | 单页面架构 | 多页面架构 |
|---|---|---|
| 界面数量 | 1～2 个，功能集中 | 3 个以上，功能分区明显 |
| 状态管理 | 全局状态混杂，易互相影响 | 页面内局部状态，边界清晰 |
| 内存占用 | 所有控件常驻，占用较高 | 按需创建/销毁，峰值可控 |
| 可维护性 | 改动牵一发动全身 | 页面独立，便于分工与复用 |
| 切换开销 | 显隐切换快，无重建成本 | 有页面创建/销毁开销，可缓存优化 |
| 适用场景 | 简单仪表、单一功能面板 | 工业 HMI、智能家居、医疗设备 |
多页面架构的设计原则可以归纳为四条：
- 单一职责：一个页面只负责一类功能，避免“万能页面”承载过多逻辑。
- 导航集中：页面跳转统一由页面管理器或导航接口处理，页面内部不直接操作其他页面。
- 数据解耦：页面通过 Model 读写共享数据，不直接访问其他页面的控件或成员。
- 资源可控：明确哪些页面常驻、哪些页面按需创建，避免频繁重建导致卡顿或内存碎片。
四、案例与常见误区
以一台工业温控器为例，界面包含主菜单、温度设定、运行曲线、报警记录四个页面。若采用单页面架构，所有控件常驻，RAM 占用高，且报警弹窗与曲线刷新容易互相干扰。改为多页面架构后，主菜单常驻，其余页面按需创建，报警页在触发时压栈显示，退出后释放，整体响应更稳定。
// 页面切换示意（伪代码）
void gotoSettingScreen() {
presenter->navigateTo<SettingView>();
}
void onAlarmTriggered() {
presenter->pushScreen<AlarmView>(); // 压栈显示
}
void onAlarmClosed() {
presenter->popScreen(); // 出栈返回
}
总体而言，多页面架构并不是“更高级”的代名词，而是面向复杂界面的组织手段。界面简单时，单页面足够高效；界面复杂、团队协作、长期维护时，多页面架构能显著降低耦合、提升可扩展性。掌握页面划分、导航调度与资源管理这三件事，就抓住了 TouchGFX 多页面设计的核心。