4、静态内存优化：全局变量、常量与只读数据的布局策略
说到静态内存优化，我得先坦白一件事。早年我做第一个嵌入式语音项目时，代码编译通过，功能也正常，结果一跑起来就死机。查了三天，最后发现是全局变量把栈区给挤爆了。嗯，从那以后，我对静态内存的布局就格外上心。
静态内存，说白了就是编译时就确定好的那部分内存。全局变量、静态变量、常量字符串、只读数据，全归它管。这部分内存不会动态分配，也不会被释放，所以布局得好不好，直接决定了你的系统能跑多稳。
4.1 全局变量的“坑”与“道”
全局变量用起来方便，但代价不小。每个全局变量都会在程序整个生命周期里占用内存。我见过有人把几百个全局标志位散落在各个.c文件里，结果RAM被吃掉了好几KB。
我个人习惯的做法是：
- 能局部就别全局——函数内部能解决的，绝不放到文件作用域。
- 能静态就别外部——只在当前文件用的变量，加个
static，既防止命名冲突，也方便后续优化。 - 能合并就合并——比如多个布尔标志位，可以用位域或一个uint8_t的各个bit来表示。
核心原则：全局变量每多一个，你的内存压力就大一分。尤其是在语音算法中，缓冲区、状态机、参数表动辄几百字节，布局稍有不慎就会出问题。
举个例子，语音前端处理中常用的环形缓冲区：
// 不推荐：每个缓冲区单独定义
static int16_t mic_buffer[512];
static int16_t ref_buffer[512];
static int16_t out_buffer[512];
// 推荐：合并为一个结构体，按对齐要求排列
typedef struct {
int16_t mic[512];
int16_t ref[512];
int16_t out[512];
} audio_buffers_t;
static audio_buffers_t audio_buf;
为什么这样好？因为结构体内部编译器会帮你做对齐优化，而且访问时缓存命中率更高。我在项目中遇到过，分开定义时三个缓冲区可能被分配到不同的内存区域，导致cache miss频繁，性能直接掉了15%。
4.2 常量与只读数据的“搬家”策略
常量数据，比如查找表、滤波器系数、语音特征模板，这些是只读的。它们应该放在哪里？
默认情况下，它们会被放到RAM里。但你想啊，RAM多贵啊，而且掉电就丢。对于嵌入式系统，尤其是资源受限的MCU，我们应该把它们挪到Flash或ROM里。
具体怎么做？
- 使用
const关键字——告诉编译器这是只读数据，编译器会尽量把它放到Flash段。 - 利用链接脚本——手动指定某个段放在Flash地址空间。
- 使用
__attribute__((section(".rodata")))——强制放到只读数据段。
小技巧：对于语音算法中的大查找表（比如FFT旋转因子表、汉明窗系数），我建议用const + __attribute__((aligned(4)))，既能放Flash，又能保证对齐访问，一举两得。
我曾经在一个语音唤醒项目里，把一组1280字节的MFCC均值表从RAM挪到Flash，直接省出了1.2KB的RAM。对于只有16KB RAM的芯片来说，这简直是救命。
4.3 布局策略：谁该挨着谁？
静态内存的布局不是随便排排坐。合理的布局能减少碎片、提高访问效率、甚至降低功耗。
我总结了几条经验：
- 高频访问的变量放一起——比如语音处理中的当前帧缓冲区、状态标志位，尽量放在同一Cache Line内。
- 大小相近的变量放一起——避免因对齐导致的填充浪费。比如所有int16_t的变量放一个段，所有int32_t的放另一个段。
- 只读数据和读写数据分开——这样链接器可以分别映射到Flash和RAM，互不干扰。
- 初始化值为0的变量单独放——很多编译器支持
.bss段，这部分在启动时统一清零，比逐个初始化快得多。
| 数据类型 | 推荐存放段 | 说明 |
|---|---|---|
| 全局变量（有初始值） | .data | RAM中，启动时从Flash拷贝 |
| 全局变量（无初始值） | .bss | RAM中，启动时清零 |
| const常量 | .rodata | Flash中，直接寻址 |
| 字符串字面量 | .rodata | Flash中，注意对齐 |
| 静态局部变量 | .data 或 .bss | 取决于是否有初始值 |
注意：有些MCU的Flash读取速度比RAM慢，如果某个常量被高频访问（比如语音算法中的循环缓冲区查找表），放在Flash可能导致性能瓶颈。这时候需要权衡：是省RAM还是保速度？我一般建议用const放在Flash，如果实测性能不够，再考虑用DMA或Cache来缓解。
4.4 实战：语音特征提取中的静态内存布局
拿一个典型的语音特征提取模块来说，它通常包含：
- 预加重系数（常量，float）
- 汉明窗系数（常量，float或int16_t）
- FFT旋转因子（常量，int16_t）
- Mel滤波器组系数（常量，int16_t）
- 当前帧数据（读写，int16_t数组）
- 特征输出缓冲区（读写，float数组）
- 状态标志位（读写，uint8_t）
我一般这样布局：
// 只读数据 - 全部放到Flash
static const int16_t hamming_window[256] __attribute__((section(".rodata"))) = { ... };
static const int16_t fft_twiddle[512] __attribute__((section(".rodata"))) = { ... };
static const int16_t mel_filter_bank[1280] __attribute__((section(".rodata"))) = { ... };
// 读写数据 - 放到RAM，按访问频率排列
static int16_t frame_buffer[256]; // 高频访问
static float feature_buffer[40]; // 中频访问
static uint8_t proc_flags; // 低频访问
这样做的好处很明显：
- 所有常量只占Flash，不占RAM
- 高频的帧缓冲区放在一起，cache友好
- 状态标志位单独一个字节，不浪费
我记得有一次，一个同事把Mel滤波器系数也放在了RAM里，结果RAM超了200字节。我让他改成const并放到Flash，问题立刻解决。你想想看，1280个int16_t就是2.5KB，对于很多MCU来说，这已经是半个RAM了。
4.5 避坑指南
我曾经踩过的坑：
- 误把大数组声明为
static但没有加const，结果它被放到了RAM的.data段，白白浪费空间。 - 字符串字面量默认在.rodata，但如果用
char *p = "hello"，指针本身在RAM里，字符串在Flash。如果频繁修改指针指向，RAM占用会悄悄增加。 - 不同编译器对
const的处理不一样。有些编译器会把const变量依然放到RAM，只是标记为只读。一定要看map文件确认。
嗯，静态内存优化这件事，说难不难，说简单也不简单。关键是要养成习惯：每定义一个全局变量或常量，都问自己一句——它真的需要待在RAM里吗？它能不能和别的变量共用空间？它的布局会不会影响性能？
下一章我们会聊动态内存分配的那些事，到时候你会发现，静态内存布局做得好，动态内存的压力会小很多。