4、Flash占用分析：测量与拆解TFLite Micro固件内存布局

TFLite Micro在MCU上部署时，Flash占用往往成为首要瓶颈。许多开发者发现，仅仅调用一个简单的图像分类模型，固件体积就可能超过200KB，而其中真正属于模型权重和算子的部分却不足一半。要实施有效的算子裁剪，第一步不是盲目删代码，而是精确回答三个问题：代码段（.text）占多少？数据段（.data/.bss）占多少？常量段（.rodata）占多少？本章将系统讲解如何测量这些指标，如何从编译产物中定位算子相关符号，以及如何通过链接脚本和map文件建立Flash占用的完整视图。

上图展示了Flash占用分析的整体链路：从编译产物出发，通过工具链提取各段信息，最终形成可指导裁剪决策的量化报告。下面我们将深入每个环节的具体操作。

4.1 核心原理：ELF文件中的三段式Flash布局

MCU上的Flash存储主要承载三类数据，对应ELF文件中的三个关键段：

• .text（代码段）：存放编译后的机器指令，包括TFLite Micro框架的调度逻辑、算子内核函数（如Conv2D、DepthwiseConv2D的C/C++实现）、内存分配器代码等。该段大小直接决定CPU执行路径的复杂度。
• .rodata（只读数据段）：存放常量数据，包括模型权重（若以C数组形式嵌入）、量化参数（零点、缩放因子）、激活函数查找表、算子注册表结构体等。该段通常占据Flash的较大比例，尤其是包含完整模型时。
• .data（已初始化数据段）：存放有非零初始值的全局变量，在启动时从Flash拷贝到RAM。TFLite Micro中该段通常较小，主要包含一些全局配置标志。
• .bss（零初始化数据段）：存放零初始化的全局变量，不占用Flash空间（仅记录大小），但占用RAM。TFLite Micro的tensor arena通常位于此段或由链接脚本单独分配。

理解这三段的核心意义在于：算子裁剪主要影响.text段（移除未使用的内核函数），模型优化主要影响.rodata段（量化、剪枝、权重共享），而arena配置影响.bss段（但不影响Flash）。因此，测量Flash占用时必须分别统计，才能准确判断裁剪策略的收益。

4.2 测量方法：从size命令到map文件深度解析

测量Flash占用需要组合使用多种工具，形成从宏观到微观的完整视图。

4.2.1 宏观测量：size命令快速获取段大小

编译完成后，使用GNU工具链的size命令可以快速获取各段大小：

# 针对ARM Cortex-M系列
arm-none-eabi-size build/firmware.elf
# 输出示例
#   text    data     bss     dec     hex filename
#  128456   1024   20480  149960   249c8 build/firmware.elf

其中text即代码段Flash占用，data是已初始化数据（Flash中占用与RAM中占用相同），bss仅占RAM。对于Flash总量，需要计算text + data。若使用--format=berkeley或--format=sysv可获取更详细的分段信息。

4.2.2 微观定位：nm和objdump提取符号级信息

当需要定位具体算子占用的Flash空间时，使用nm列出符号表并按地址排序：

# 列出所有符号，按地址排序，显示大小
arm-none-eabi-nm -S --size-sort build/firmware.elf | tail -50

输出中每行包含：符号地址、符号大小、符号类型（T=代码段，R=只读数据，B=bss，D=data）、符号名称。通过过滤T类型且名称包含tflite或ops的符号，可以快速定位算子内核函数：

# 查看所有TFLite相关代码段符号
arm-none-eabi-nm -S build/firmware.elf | grep " T " | grep -i "tflite\|ops" | sort -k2 -rn | head -30

对于更详细的段归属分析，objdump -h可以显示每个段的起始地址、大小和属性：

arm-none-eabi-objdump -h build/firmware.elf

4.2.3 终极武器：map文件全量分析

链接器生成的.map文件是Flash占用分析的黄金标准。它记录了每个目标文件（.o）中各段的大小，以及每个符号的最终链接地址。关键信息包括：

• 段汇总表：列出所有输入段（如.text、.rodata）的总大小及来源文件。
• 符号交叉引用表：每个符号的地址、大小、所在目标文件。
• 废弃段信息：通过--gc-sections丢弃的未使用段，可帮助确认哪些算子已被自动裁剪。

分析map文件时，重点关注Discarded input sections部分，这里列出了被垃圾回收的段，如果某个算子内核函数出现在这里，说明它未被任何注册表引用，可以安全移除。

4.3 案例拆解：一个图像分类模型的Flash占用分析实战

假设我们有一个基于MobileNetV2的图像分类模型，部署在STM32F746（1MB Flash）上。初始编译后，size命令输出如下：

text    data     bss     dec     hex filename
412356   2048   65536  479940   753c4 build/firmware.elf

Flash总占用为412356 + 2048 = 414404字节（约405KB），距离1MB还有较大余量，但若后续添加更多功能则可能紧张。我们通过map文件进一步拆解：

段/模块	大小（字节）	占比	主要符号
.text 总大小	412,356	100%	—
├─ 算子内核函数	286,432	69.5%	Conv2D (82KB), DepthwiseConv2D (45KB), Add (12KB), Reshape (8KB), Softmax (15KB), 其他
├─ 框架调度	78,924	19.1%	MicroInterpreter, TensorAllocator, OpResolver
├─ 内存管理	28,456	6.9%	arena分配器, 内存对齐工具
└─ 其他（日志、调试）	18,544	4.5%	printf, assert, 调试接口
.rodata 总大小	128,432	100%	—
├─ 模型权重	112,896	87.9%	model_data[] 数组
├─ 算子查找表	12,288	9.6%	tanh_lut, sigmoid_lut
└─ 其他常量	3,248	2.5%	版本信息, 配置结构体

通过上述拆解，我们发现：算子内核函数占代码段的69.5%，其中Conv2D和DepthwiseConv2D合计占127KB，是裁剪的首要目标。进一步使用nm查看具体符号：

arm-none-eabi-nm -S build/firmware.elf | grep " T " | grep -E "Conv2D|Depthwise" | sort -k2 -rn
# 输出示例
# 0800a1b4 0001a3c4 T tflite::ops::micro::Conv2D::Eval
# 0800a5f8 0000f2a0 T tflite::ops::micro::DepthwiseConv2D::Eval
# 0800b8a0 0000a1b8 T tflite::ops::micro::Conv2D::Prepare

分析发现，Conv2D的Eval函数占用了约107KB，这是因为该函数包含了针对不同输入通道数、核大小、步长的多个分支优化代码。若模型仅使用3x3卷积，可以通过宏定义裁剪掉5x5、7x7等分支，预计可节省30-40KB。

实际操作中，我们修改micro/kernels/conv.cc中的条件编译宏，仅保留3x3卷积路径，重新编译后：

text    data     bss     dec     hex filename
368124   2048   65536  435708   6a5fc build/firmware.elf

代码段从412KB降至368KB，节省约44KB（10.7%）。同时，由于移除了未使用的卷积分支，链接器的--gc-sections自动丢弃了相关代码，进一步减少了Flash占用。

4.4 常见误区与总结复盘

在Flash占用分析过程中，开发者常陷入以下误区：

• 误区一：只关注.text段，忽略.rodata。当模型权重以浮点格式存储时，.rodata可能占据Flash的70%以上。此时算子裁剪的收益微乎其微，应优先进行模型量化（如int8量化可将权重压缩4倍）。
• 误区二：盲目相信size命令的总数。size命令显示的是链接后的最终大小，但未考虑链接器的垃圾回收效果。若未启用-ffunction-sections -fdata-sections和--gc-sections，未使用的算子代码也会被链接进固件，导致Flash虚高。
• 误区三：忽略对齐填充。ARM Cortex-M要求4字节对齐，某些段（如.rodata）可能因对齐产生填充字节。在计算实际可用空间时，需考虑这些额外开销。
• 误区四：混淆Flash与RAM占用。.data段同时占用Flash和RAM，但.bss仅占RAM。在评估Flash余量时，只需关注text + data，而评估RAM余量时需关注data + bss。

总结复盘：Flash占用分析是算子裁剪的基石。建议建立标准化的分析流程：

1. 编译时启用-ffunction-sections -fdata-sections，链接时启用--gc-sections，确保未使用代码被自动丢弃。
2. 使用size命令获取宏观段大小，建立基线数据。
3. 通过nm -S和map文件定位Top 10的Flash消耗符号，重点关注算子内核函数。
4. 结合模型结构（算子类型、参数范围）判断哪些代码分支可以安全裁剪。
5. 每次裁剪后重新测量，记录Flash变化，形成裁剪日志。