📚 课程目录第2章 TFLite Micro核心架构解析

2. TFLite Micro 核心架构解析

这一章，我们来拆解 TFLite Micro 的“五脏六腑”。

很多初学者把模型往板子上一丢，跑通了就完事。但一旦遇到内存不够、算子报错、或者模型压根不跑，就抓瞎了。我刚开始做 STM32 移植时也这样，后来被坑了几次，才老老实实把源码啃了一遍。

说白了，TFLite Micro 的核心就四个东西：解释器（Interpreter）、算子（Operator）、张量（Tensor）、模型加载。搞懂它们，你就能掌控全局。

解释器是整个框架的大脑。它不负责具体计算，而是负责“安排谁先干、谁后干、干完数据放哪”。

我习惯把它的工作流程分成三步：

你想想看，这就像一个项目经理。他先看图纸（模型），然后给每个工种（算子）分配工具和材料（张量），最后喊一声“开工！”。

核心要点：解释器本身不存储数据，它只维护一个“执行计划”。真正的数据都在张量里。

这里有个坑。我在项目里遇到过，AllocateTensors() 返回了 kTfLiteError，但模型文件明明是对的。后来发现，是某个中间张量的尺寸太大，超出了 STM32 的 SRAM 上限。所以，内存分配失败是移植中最常见的“死因”。

TFLite Micro 和 TFLite 最大的区别是什么？

答案是：算子不是全量内置的。TFLite 桌面版有几百个算子，但 Micro 版只保留了你真正用到的那几个。

算子注册，说白了就是告诉解释器：“我这个模型里只用 Conv2D、DepthwiseConv2D 和 Softmax，别的你别管。”

注册方式有两种：

方式	说明	适用场景
全量注册	使用 `tflite::ops::micro::AllOpsResolver()`	快速验证，但 ROM 占用大
手动注册	逐个添加 `AddConv2D()`、`AddSoftmax()` 等	生产环境，精确控制 ROM 大小

我个人习惯用手动注册。为什么？因为 STM32 的 Flash 很金贵。全量注册可能多出几十 KB 的代码，而这些代码你根本用不上。

小技巧：在编译前，先用 xxd 或 Netron 查看模型文件里的算子列表。只注册这些算子，一个都不要多。

我曾经接手过一个项目，同事用了全量注册，结果 Flash 爆了。我帮他改成手动注册，只保留了 5 个算子，Flash 占用直接降了 40%。

这是 TFLite Micro 最精妙的设计，也是面试常考题。

桌面版 TFLite 可以动态分配内存，但 Micro 版不行——因为嵌入式系统没有 malloc 或者 malloc 很慢。所以，Micro 版采用了一种叫 “静态内存规划” 的策略。

具体来说：

你想想看，这就像酒店的房间分配。客人 A 退房了，客人 B 才能入住。TFLite Micro 的“前台”会精确计算每个张量的生命周期，然后让它们“拼房”。

注意：输入张量和输出张量的内存是独立的，不会被复用。只有中间张量（intermediate tensors）才会参与复用。

我画了一张图，帮你理解这个内存复用模型：

模型加载，就是把一个二进制文件变成解释器能理解的“图结构”。

流程大致如下：

这里有个细节。模型文件里的张量信息只包含“形状”和“类型”，不包含实际数据指针。实际数据指针是在 AllocateTensors() 阶段才确定的。

关键点：模型加载阶段不分配内存，只做“规划”。真正的内存分配在 AllocateTensors() 阶段。

我刚开始做移植时，总以为模型加载完就能用了。结果一调用 Invoke() 就崩。后来才发现，我忘了调用 AllocateTensors()。嗯，这个坑我踩过，你别踩。

最后，给你一个检查清单：