1. TouchGFX内存模型深度解析：Flash、SRAM、Framebuffer的分配机制与硬件限制
做TouchGFX优化，第一件事就是搞清楚你的代码到底住在哪、怎么住、能住多大。说白了，嵌入式系统的内存就那么大点地方，不像PC端可以随便挥霍。我刚开始接触TouchGFX时，也踩过不少坑——明明代码逻辑没问题，编译也通过了，一跑起来就黑屏或者闪退。后来才发现，是内存分配出了问题。
这一章，我们就来把TouchGFX的内存模型彻底拆开看看。Flash、SRAM、Framebuffer，这三者怎么分工、怎么协作、有什么硬件限制，我都会结合自己的项目经验给你讲透。
1.1 三大存储区域的角色分工
TouchGFX应用跑在MCU上，主要依赖三种存储介质。它们各有各的脾气，你得顺着它们来。
| 存储区域 | 存储内容 | 访问速度 | 容量特点 | 掉电保持 |
|---|---|---|---|---|
| Flash | 代码、只读数据、字体、图片、字符串常量 | 较慢（读） | 通常较大（512KB~2MB） | 是 |
| SRAM | 全局变量、堆栈、动态分配、运行时数据 | 极快 | 通常较小（128KB~512KB） | 否 |
| Framebuffer | 屏幕像素数据（RGB565/ARGB8888） | 极快（DMA传输） | 由分辨率×色彩深度决定 | 否 |
你看，Flash大但慢，SRAM快但小，Framebuffer则是SRAM里的“大户”。我见过不少新手，把大图片直接扔到SRAM里，结果Framebuffer都没地方放了。嗯，这里要注意——Framebuffer必须放在SRAM中，因为LCD控制器需要高速访问它来刷新屏幕。
核心原则：能放Flash的，绝不放SRAM。字体、图片、动画帧，只要不是运行时必须修改的，统统塞进Flash。
1.2 Framebuffer的分配机制与硬件限制
Framebuffer是内存优化的重灾区。为什么？因为它占的空间是“硬性”的，你没法压缩。
举个例子：一个480×272的屏幕，用RGB565格式（每个像素2字节），单缓冲需要：
480 × 272 × 2 = 261,120 字节 ≈ 255 KB如果是双缓冲，直接翻倍到510 KB。很多MCU的SRAM总共才256KB或512KB，你想想看，一个Framebuffer就把SRAM吃光了，其他变量往哪放？
我在一个项目里就遇到过这种情况。客户要求用800×480的屏幕，ARGB8888格式（每像素4字节），单缓冲就要：
800 × 480 × 4 = 1,536,000 字节 ≈ 1.5 MBMCU的SRAM只有512KB，根本放不下。最后只能降级到RGB565格式，并且只用单缓冲+局部刷新策略才勉强跑起来。
硬件限制提醒：Framebuffer必须放在MCU内部SRAM或外部SDRAM中。如果使用外部SDRAM，要注意访问延迟和DMA带宽，否则会出现屏幕撕裂或闪烁。
1.3 Flash中的资源布局
TouchGFX会把字体、图片、文本等资源编译成二进制数据，链接到Flash的特定区域。我个人习惯把Flash分区规划好：
- 代码区：应用程序代码、TouchGFX框架代码
- 只读数据区：常量、字符串表
- 资源区：字体缓存、图片缓存、动画数据
- 配置文件区：UI布局、主题定义
你可能会问：这些资源为什么不直接放在SRAM里？因为SRAM太贵了。Flash虽然读起来慢一点，但TouchGFX有局部加载和缓存机制，不会每次都从Flash读全部数据。我建议你把常用的图片和字体放在Flash的连续地址段，这样DMA读取效率更高。
1.4 SRAM的分配策略
SRAM是TouchGFX的“工作台”。所有运行时变量、堆栈、动态对象都在这。SRAM的分配策略直接影响UI的流畅度。
我一般把SRAM分成三块：
- 系统区：RTOS任务栈、中断向量表、全局变量
- TouchGFX堆区：用于动态创建控件、容器、动画对象
- Framebuffer区：屏幕像素数据
这里有个坑——堆区大小要谨慎设置。我曾经在一个项目里把堆设得太小，结果UI启动时动态创建控件失败，直接卡死在初始化阶段。后来我把堆从4KB调到16KB，问题就解决了。但也不能设太大，否则Framebuffer就没空间了。
我的经验：在TouchGFX Designer中生成项目后，先检查 TouchGFXConfiguration.cpp 里的 touchgfx_init() 函数，看看Framebuffer地址和大小是否合理。我习惯在启动时打印出各区域的内存使用情况，方便调试。
1.5 内存模型全景图
下面这张图是我自己总结的TouchGFX内存模型。你看一眼就能明白数据是怎么流动的。
1.6 避坑指南：我踩过的三个内存坑
做TouchGFX这几年，我踩过不少内存相关的坑。挑三个典型的跟你说说：
坑一：Framebuffer地址未对齐
我曾经在一个项目里，Framebuffer地址没有32字节对齐，结果DMA传输时出现数据错位，屏幕显示花屏。后来在链接脚本里加了 __attribute__((aligned(32))) 才解决。记住：Framebuffer地址必须按MCU的DMA要求对齐，通常是32字节或64字节。
坑二：堆栈溢出导致随机崩溃
有一次UI跑着跑着就死机了，没有任何规律。我查了两天才发现，是一个回调函数里递归调用了自己，把任务栈撑爆了。从那以后，我习惯在每个任务栈里留20%的余量，并且在调试阶段开启栈溢出检测。
坑三：图片解压到SRAM导致内存不足
TouchGFX支持PNG图片，但PNG解压后需要额外的SRAM空间。我试过在界面上放了一张全屏PNG背景，解压时直接OOM（内存不足）。后来我把所有背景图都转成了BMP格式，或者用JPEG压缩+硬件解码，才把内存省出来。
1.7 小结
好了，这一章我们把TouchGFX的内存模型拆了个底朝天。Flash存资源、SRAM跑运行时、Framebuffer管显示，三者各司其职。你只要记住：能放Flash的别放SRAM，Framebuffer要精打细算，堆栈大小要留余量，基本就不会出大问题。