3、内存占用分析：如何查看编译后的程序大小（Sketch大小）与全局变量占用（SRAM）

在Arduino开发中，很多开发者只关注程序能否正常编译和上传，却忽略了编译输出窗口中那两行关键数据：“Sketch uses X bytes”和“Global variables use Y bytes”。这两行数据分别对应程序存储器（Flash）和静态随机存取存储器（SRAM）的占用情况。理解并准确分析这两项指标，是进行内存优化的第一步。本章将系统讲解如何解读编译输出、如何通过工具链获取更详细的映射信息，以及如何定位全局变量占用的具体来源。

3.1 核心原理：Flash 与 SRAM 的分工与限制

Arduino 基于 AVR（如 ATmega328P）或 ARM Cortex-M（如 SAMD21）微控制器，其内部存储器分为两大区域：Flash（程序存储器）和 SRAM（静态随机存取存储器）。Flash 用于存放编译后的机器码、常量字符串和只读数据，断电后数据不丢失；SRAM 用于存放全局变量、静态变量、堆（Heap）和栈（Stack），断电后数据全部清零。两者是独立的物理空间，容量也各不相同。以经典的 Arduino Uno（ATmega328P）为例，Flash 为 32KB（实际可用约 31.5KB，因为引导程序占用 0.5KB），SRAM 仅为 2KB。而 Arduino Mega 2560（ATmega2560）则拥有 256KB Flash 和 8KB SRAM。ESP32 等现代芯片虽然 SRAM 更大（约 520KB），但依然存在资源上限。

理解两者的区别至关重要：Flash 超限会导致编译失败或无法烧录，因为程序放不下；SRAM 超限则不会在编译时直接报错，但程序运行时会出现变量被覆盖、函数调用栈溢出、系统随机复位等诡异问题。因此，SRAM 的占用分析往往比 Flash 更棘手，也更需要开发者主动关注。

3.2 判断方法：从 IDE 输出到命令行工具

获取内存占用信息有多种途径，从最简单的 IDE 输出到专业的命令行工具，各有适用场景。

方法一：Arduino IDE 编译输出窗口

在 Arduino IDE 中点击“验证”按钮（对勾图标），编译完成后，底部黑色输出窗口会显示类似以下信息：

Sketch uses 9248 bytes (28%) of program storage space. Maximum is 32256 bytes.
Global variables use 1159 bytes (56%) of dynamic memory, leaving 889 bytes for local variables. Maximum is 2048 bytes.

第一行是 Flash 占用，第二行是 SRAM 占用。注意“leaving X bytes for local variables”表示剩余可供栈和堆使用的空间。如果这个剩余值小于 200 字节，就需要高度警惕——因为函数调用、中断处理、局部数组都会消耗栈空间。

方法二：编译时生成详细报告（IDE 2.x）

Arduino IDE 2.x 版本支持“编译时输出详细信息”。在 文件 → 首选项 → 显示详细输出 中勾选“编译”，重新编译后，输出窗口会显示完整的命令行调用，包括 avr-size 和 avr-nm 的执行结果。这能提供每个目标文件（.o）的大小，但信息较为分散。

方法三：使用 avr-size 和 avr-nm 命令行工具

对于深度分析，推荐使用命令行工具。编译时在首选项中开启“编译时输出详细信息”，从输出中找到 .elf 文件的完整路径（通常位于临时文件夹）。然后打开终端，进入该目录执行：

avr-size -C -x sketch.ino.elf
avr-nm -S --size-sort sketch.ino.elf

avr-size 会显示各段（.text、.data、.bss）的大小；avr-nm 则列出所有符号及其地址和大小，按大小排序后，可以快速定位哪些全局变量占用了最多 SRAM。对于 ARM 架构的板卡（如 Due、Zero），使用 arm-none-eabi-size 和 arm-none-eabi-nm。

3.3 案例拆解：一个典型的 SRAM 占用排查过程

下面通过一个实际案例，演示如何从“程序运行不稳定”到定位 SRAM 占用过高的完整过程。

背景与约束：某环境监测项目使用 Arduino Uno，需要采集温湿度、PM2.5 和 GPS 数据，并通过 LCD 显示屏显示。开发完成后，设备在运行约 10 分钟后随机重启，有时 LCD 显示乱码。项目已接近交付，硬件无法更改。

初始现象与目标：编译输出显示 Global variables use 1780 bytes (86%)，剩余 SRAM 仅 268 字节。目标是将全局变量占用降低到 60% 以下（即 1228 字节以内），确保系统稳定运行。

关键数据与日志：通过 avr-nm -S --size-sort 输出，发现以下大块占用：

分析判断过程：首先，char buffer[512] 是全局数组，用于存放 GPS 的 NMEA 原始语句。但 GPS 模块每次输出的最长语句不超过 120 字节，512 字节明显过大。其次，float sensor_data[50] 用于存储 50 组历史数据，但实际只需要最近 10 组。第三，String gps_string 在堆上动态分配内存，且 String 对象本身在 SRAM 中占用约 6 字节，但动态分配的内存碎片化会加剧 SRAM 压力。最后，LCD 库和 SoftwareSerial 库本身也占用约 300 字节全局空间。

实际操作步骤：

1. 将 buffer[512] 缩小为 buffer[128]，节省 384 字节。
2. 将 sensor_data[50] 改为 sensor_data[10]，节省 160 字节。
3. 将 String gps_string 替换为固定长度的 char gps_line[128]，并手动解析，避免动态内存分配。
4. 将 lcd_line[64] 改为 lcd_line[32]，因为实际显示内容不超过 20 个字符。
5. 重新编译后，全局变量占用降至 1050 字节（51%），剩余 998 字节。

结果对比：修改后设备连续运行 72 小时无重启，LCD 显示正常。编译输出变为 Global variables use 1050 bytes (51%)。

风险与代价：缩小 buffer 后，如果 GPS 模块输出异常长语句（如某些厂商扩展语句），可能导致截断。因此，在代码中增加了长度检查，超长时丢弃该条数据。此外，使用 char 数组替代 String 后，字符串拼接需要手动处理，代码量略有增加。

复盘经验：全局数组的大小应基于实际需求而非“预留余量”；避免在全局作用域使用 String 对象；库的全局变量占用往往被忽视，更换轻量级库（如用 LiquidCrystal_I2C 替代并行 LCD 库）也能显著减少 SRAM 占用。

3.4 常见误区与总结复盘

在内存占用分析中，开发者常陷入以下误区：

• 只关注 Flash 忽略 SRAM：Flash 超限会直接编译失败，而 SRAM 超限是“软故障”，更难排查。建议每次编译都记录 SRAM 占用百分比。
• 误以为局部变量不占 SRAM：局部变量在栈上分配，栈空间从 SRAM 中划出。如果全局变量占用过高，栈空间被压缩，局部数组稍大就会溢出。
• 忽视 const 修饰符：在 AVR 上，const char str[] = "hello" 默认存储在 Flash 中，但 const int arr[] 如果未使用 PROGMEM，仍会复制到 SRAM。需要显式使用 PROGMEM 和 pgm_read_* 函数。
• 认为 free() 能完全释放内存：在 Arduino 上，free() 释放的内存可能不会立即归还给堆，且碎片化问题严重。最好的策略是避免动态内存分配。

总结来看，内存占用分析应遵循以下流程：第一步，每次编译后记录 Flash 和 SRAM 的百分比；第二步，当 SRAM 占用超过 70% 时，使用 avr-nm 列出所有全局符号，按大小排序；第三步，针对大块数组和 String 对象进行优化；第四步，优化后重新编译，对比前后数据。通过系统化的分析，可以确保程序在有限的 SRAM 中稳定运行，为后续的 Arena 内存池和全局变量控制打下基础。