📚 课程目录第2章 Flash占用构成分析

2、Flash占用构成分析：区分代码段、只读数据段、常量池、模型权重等不同Flash占用来源

TFLite Micro 在嵌入式系统上运行时，Flash 资源是决定模型能否部署、功能能否扩展的核心约束。很多开发者只关注“模型文件有多大”，却忽略了最终固件中 Flash 占用是由多个来源共同构成的。只有精确区分代码段（.text）、只读数据段（.rodata）、常量池、模型权重、初始化数据段（.data）以及链接器填充等不同部分，才能制定有效的裁剪与压缩策略。本章将系统拆解 Flash 占用的构成维度，帮助你在项目初期就建立清晰的 Flash 预算意识。

上图展示了 TFLite Micro 固件中 Flash 占用的四大核心来源及其细分内容。在实际工程中，这四部分的比例会因模型结构、框架配置和编译器选项而显著变化。下面逐一深入分析每一部分的构成机制、判断方法和优化切入点。

2.1 代码段（.text）：框架与算子的“体积大头”

核心原理：代码段存储的是编译后的机器指令，包括 TFLite Micro 解释器核心逻辑、算子内核实现、内存管理器和调度框架。对于典型的 MCU 项目，代码段通常占用 Flash 总量的 30%~60%。一个常见的误解是“模型越大，代码段越大”，实际上代码段大小主要取决于你链接了哪些算子、启用了哪些框架特性，而非模型权重本身。

判断方法：使用编译器工具链的 size 命令可以快速查看各段大小：

arm-none-eabi-size build/firmware.elf
   text    data     bss     dec     hex filename
  48216    1232   10456   59904    ea00 build/firmware.elf

其中 text 列即为代码段大小。更精细的分析需要查看 map 文件，定位具体函数或模块的占用：

arm-none-eabi-nm --size-sort --radix=d build/firmware.elf | tail -20

这会列出占用最大的符号，帮助你识别哪些算子或函数占据了主要空间。

实战案例：某智能家居项目使用 TFLite Micro 部署关键词唤醒模型，初始固件 Flash 占用 312KB（总容量 512KB）。通过 nm 命令发现，tflite::ops::micro::kConv2D 相关算子占用 18.2KB，而 tflite::ops::micro::kFullyConnected 占用 9.6KB。进一步分析发现，框架默认链接了全部 40+ 个算子，但实际模型只用到 5 个。通过修改 micro_mutable_op_resolver.h，仅注册所需算子，代码段从 48KB 降至 21KB，节省了 27KB Flash。

2.2 只读数据段（.rodata）：查表与量化参数的隐藏消耗

核心原理：只读数据段存放编译期确定的常量数据，包括量化参数（零点、缩放因子）、激活函数查表、滤波器系数和算子注册信息。对于量化模型，每层张量都需要存储 scale 和 zero_point（各 4 字节），当模型层数较多时，这部分开销不可忽视。此外，TFLite Micro 的某些算子（如 sigmoid、tanh）在 int8 量化下使用查表实现，一张 257 字节的查表在多个算子间可能重复实例化。

判断方法：使用 readelf 查看只读数据段的详细内容：

arm-none-eabi-readelf -S build/firmware.elf | grep rodata
  [ 4] .rodata           PROGBITS        0000c000 00c000 004a10 00  A  0   0  8

结合 objdump 可以导出具体内容，但更实用的方式是检查 map 文件中 .rodata 段的符号列表，识别哪些常量占用了较大空间。

经验提示：在 TFLite Micro 中，tflite::MicroMutableOpResolver 的注册表会为每个算子存储名称字符串和函数指针。如果启用了调试日志（TF_LITE_REPORT_ERROR），大量格式字符串也会进入 .rodata。建议在正式发布版本中关闭详细日志，仅保留错误级别输出。

2.3 常量池：编译器生成的“隐形”数据

核心原理：常量池是编译器自动生成的只读数据，用于存储字符串字面量、浮点常量、跳转表和 switch-case 查找表。在 TFLite Micro 中，算子调度器通常使用大型 switch-case 或函数指针表，这些都会产生常量池条目。此外，C++ 的 RTTI（运行时类型识别）和异常处理（如果启用）也会显著增加常量池大小。

判断方法：在编译时添加 -fno-rtti -fno-exceptions 可以消除 RTTI 和异常相关代码。使用 -fno-jump-tables 可以强制编译器不使用跳转表（但可能增加代码段大小）。通过对比编译选项前后的 size 输出，可以量化常量池的影响。

# 优化前
arm-none-eabi-size build/firmware.elf
   text    data     bss     dec     hex filename
  48216    1232   10456   59904    ea00 build/firmware.elf

# 添加 -fno-rtti -fno-exceptions 后
arm-none-eabi-size build/firmware.elf
   text    data     bss     dec     hex filename
  45120    1232   10456   56808    dde8 build/firmware.elf

上述示例中，仅通过禁用 RTTI 和异常就节省了约 3KB Flash。

2.4 模型权重：FlatBuffer 的结构化存储

核心原理：模型权重以 TFLite FlatBuffer 格式存储，通常作为 C 数组嵌入固件。FlatBuffer 不仅包含权重数据本身，还包含张量描述、算子参数、子图结构等元数据。对于 int8 量化模型，权重数据通常占模型总大小的 70%~85%，其余为结构开销。一个常见的误区是只关注权重数据大小，忽略了 FlatBuffer 的 schema 对齐和 padding 开销。

判断方法：使用 TFLite 提供的工具分析模型文件结构：

python -c "
import tensorflow as tf
interpreter = tf.lite.Interpreter(model_path='model.tflite')
interpreter.allocate_tensors()
details = interpreter.get_tensor_details()
total_params = sum(d['shape'].num_elements() for d in details)
print(f'总参数数量: {total_params}')
print(f'模型文件大小: {os.path.getsize(\"model.tflite\")} 字节')
print(f'参数存储估算: {total_params} 字节 (int8)')
"

通过对比模型文件大小和参数存储估算值，可以计算出 FlatBuffer 结构开销的比例。

风险提示：不要试图手动修改 FlatBuffer 二进制来“压缩”模型。TFLite Micro 依赖严格的 schema 对齐和字段偏移，任何手动修改都可能导致解析失败或未定义行为。正确的做法是使用 TensorFlow 的量化感知训练和优化工具（如 pruning、clustering）从源头减小模型。

2.5 其他占用：.data、.bss 与链接器填充

核心原理：.data 段存储已初始化的全局变量，这些变量在启动时从 Flash 复制到 RAM，因此 Flash 中需要保存一份初始值。.bss 段是零初始化变量，不占用 Flash 空间（但占用 RAM）。链接器为了满足对齐要求（通常为 4 字节或 8 字节），会在段之间插入填充字节，这些填充在 map 文件中显示为 *fill* 条目。

判断方法：查看链接脚本（.ld 文件）中的对齐设置，以及 map 文件中的填充区域：

arm-none-eabi-ld -Map=firmware.map build/*.o -o firmware.elf
grep -A2 "fill" firmware.map | head -20

如果发现大量填充，可以调整链接脚本中的对齐值，或重新排列段顺序以减少填充。

2.6 Flash 占用分析流程与优化决策表

为了系统性地分析 Flash 占用，建议遵循以下流程：

基线测量：编译默认配置，记录各段大小。
符号级分析：使用 nm/readelf 定位 Top 20 占用符号。
配置裁剪：关闭日志、禁用 RTTI/异常、裁剪算子注册。
模型优化：量化、剪枝、蒸馏，减小权重和元数据。
链接优化：使用 -ffunction-sections -fdata-sections 配合 --gc-sections 删除未使用代码。
验证回归：每次优化后运行完整测试套件，确保功能正确。

Flash 占用来源	典型占比	主要优化手段	优化潜力	风险等级
代码段（.text）	30%~60%	算子裁剪、编译选项、链接器 GC	高（可减少 50%+）	低（需验证算子覆盖）
只读数据段（.rodata）	10%~20%	查表共享、量化参数压缩、日志裁剪	中（可减少 30%~40%）	低
常量池	5%~15%	禁用 RTTI/异常、字符串去重	中（可减少 20%~30%）	低
模型权重	20%~40%	量化、剪枝、权重共享	高（可减少 50%~75%）	中（需重新训练）
.data + 填充	1%~5%	链接脚本优化、变量重排	低（通常 <2KB）	低

2.7 常见误区与复盘总结

误区一：只关注模型文件大小。很多开发者认为“模型 100KB，Flash 512KB，肯定够用”，却忽略了代码段可能已经占用了 200KB。最终导致 Flash 溢出时措手不及。

误区二：盲目裁剪算子导致运行时错误。在裁剪算子注册时，必须确保模型推理路径上的所有算子都被注册。建议在开发阶段保留全部算子，在发布前通过自动化测试验证裁剪后的配置。

误区三：忽略链接器 GC 的作用。默认编译可能链接了未使用的库函数。使用 -ffunction-sections -fdata-sections -Wl,--gc-sections 可以自动删除未引用的函数和数据，通常能减少 10%~20% 的代码段。

案例复盘：某可穿戴设备项目，初始 Flash 占用 480KB（总容量 512KB），仅剩 32KB 余量。通过本章方法分析发现：代码段 210KB（算子冗余 80KB）、只读数据段 65KB（日志字符串 25KB）、模型权重 180KB（未量化）、其他 25KB。优化措施包括：① 算子裁剪至实际使用的 7 个，节省 72KB；② 关闭 TF_LITE_REPORT_ERROR 日志，节省 22KB；③ 将模型从 float32 量化为 int8，权重从 180KB 降至 48KB；④ 启用链接器 GC，额外节省 15KB。最终 Flash 占用降至 285KB，余量 227KB，同时推理速度提升 2.3 倍。整个优化过程耗时 2 天，其中模型量化占 1.5 天（需要重新验证精度）。

总结：Flash 占用分析不是一次性的工作，而应贯穿项目开发周期。建议在架构设计阶段就建立 Flash 预算表，将代码段、只读数据段、模型权重分别设定上限，并在每次版本迭代时跟踪变化。使用本章介绍的工具和方法，你可以精确识别每一字节 Flash 的去向，为后续的代码裁剪和常量压缩打下坚实基础。