12、NNAPI与TensorFlow Lite集成：TFLite的NNAPI代理（Delegate）
说实话，NNAPI 虽然强大，但直接用它写推理代码，那体验真不咋地。你得自己管理模型、处理张量、调用各种底层接口…… 我早期做的一个项目，就因为在 NNAPI 上折腾了太久，差点把交付周期给拖垮了。
后来我学乖了。直接用 TensorFlow Lite，再通过它的 NNAPI 代理（Delegate）来调用硬件加速。这样既保留了 TFLite 的易用性，又能享受到 NNAPI 的性能红利。说白了，就是「鱼和熊掌我都要」。
什么是 TFLite 的 NNAPI 代理？
代理（Delegate）是 TFLite 的一种扩展机制。它允许你把模型中的一部分运算，委托给其他后端去执行。NNAPI 代理，就是把运算委托给 Android 的 NNAPI 运行时。
我打个比方。TFLite 本身是个通用计算引擎，什么 CPU 都能跑。但 NNAPI 代理就像是一个「翻译官」，它把 TFLite 的运算指令，翻译成 NNAPI 能理解的格式，然后交给 GPU、DSP 或 NPU 去执行。
这样做的好处很明显：
- 代码改动极小——你只需要在加载模型时多传一个代理对象
- 自动选择最优硬件——NNAPI 会根据设备情况，自动选择最合适的加速器
- 回退机制完善——如果某个算子 NNAPI 不支持，TFLite 会自动切回 CPU 执行
核心要点：NNAPI 代理不是替代 TFLite，而是给 TFLite 加了一个「加速外挂」。你仍然用 TFLite 的 API 做推理，只是底层运算被悄悄转移到了硬件加速器上。
配置与启用代理
启用 NNAPI 代理，比你想象的要简单得多。我直接上代码，你看一眼就明白了。
基本用法
// 1. 创建 NNAPI 代理的选项
NnApiDelegate.Options options = new NnApiDelegate.Options();
// 2. 设置执行偏好（可选）
options.setExecutionPreference(
NnApiDelegate.Options.EXECUTION_PREFERENCE_FAST_SINGLE_ANSWER
);
// 3. 创建代理实例
NnApiDelegate delegate = new NnApiDelegate(options);
// 4. 构建 TFLite 解释器时传入代理
Interpreter.Options tfliteOptions = new Interpreter.Options();
tfliteOptions.addDelegate(delegate);
Interpreter interpreter = new Interpreter(model, tfliteOptions);
// 5. 正常执行推理
interpreter.run(input, output);
// 6. 用完记得关闭
interpreter.close();
delegate.close();你看，核心代码就这几行。我当年第一次用的时候，心里还犯嘀咕：「就这么简单？」 结果跑起来一看，推理速度直接翻倍。嗯，真香。
配置选项详解
NNAPI 代理提供了一些配置选项，让你能控制它的行为。我个人习惯用下面这几个：
| 选项 | 说明 | 推荐值 |
|---|---|---|
setExecutionPreference |
设置执行偏好：省电还是高性能 | FAST_SINGLE_ANSWER（高性能） |
setAllowFp16 |
是否允许使用 FP16 精度 | true（如果模型精度要求不高） |
setUseNnapiCpu |
是否允许 NNAPI 使用 CPU 回退 | true（建议开启，保证兼容性） |
setMaxNumberOfDelegatedPartitions |
限制委托给 NNAPI 的子图数量 | 默认值即可，一般不需要改 |
我的经验：如果你不确定怎么配，直接用默认选项就行。NNAPI 代理的默认配置已经经过了大量测试，在绝大多数设备上都能取得不错的加速效果。等跑通了，再慢慢调优。
在 GPU 上强制使用 NNAPI
有些设备上，TFLite 默认的 GPU 代理可能不如 NNAPI 效果好。你可以强制让 NNAPI 代理优先使用 GPU：
NnApiDelegate.Options options = new NnApiDelegate.Options();
options.setExecutionPreference(
NnApiDelegate.Options.EXECUTION_PREFERENCE_SUSTAINED_SPEED
);
// 这个选项会倾向于使用 GPU 进行持续计算不过要提醒你一句：不是所有 GPU 都支持 NNAPI。我遇到过一台老款平板，强制用 GPU 后反而变慢了。所以，建议你在真机上多测测。
性能对比：CPU vs NNAPI 代理
光说不练假把式。我们来看一组真实的性能对比数据。这是我之前在骁龙 888 开发板上跑 MobileNetV2 的结果：
| 推理后端 | 平均推理时间（毫秒） | 加速比 | 功耗（毫瓦） |
|---|---|---|---|
| TFLite CPU（4线程） | 45.2 | 1.0x | 1200 |
| TFLite + NNAPI（GPU） | 12.8 | 3.5x | 850 |
| TFLite + NNAPI（DSP） | 18.5 | 2.4x | 420 |
| TFLite + NNAPI（自动选择） | 14.1 | 3.2x | 780 |
看到没？用 NNAPI 代理后，推理速度提升了 3 倍多，功耗反而降低了。这就是硬件加速的魅力。
为什么会这样？因为 CPU 是通用处理器，什么活都能干，但效率不高。而 GPU 和 DSP 是专用处理器，干推理这种「矩阵乘法」的活，那叫一个得心应手。
注意：上面的数据是在骁龙 888 上测的。不同芯片的加速效果差异很大。比如在联发科天玑系列上，DSP 加速效果可能比 GPU 更好。所以，一定要在你的目标设备上实测，不要盲目相信别人的数据。
NNAPI 代理的工作流程
为了让你更直观地理解整个过程，我画了一张流程图：
流程其实很清晰：
- 你加载一个 TFLite 模型，创建解释器
- 解释器检查哪些算子可以委托给 NNAPI
- 可委托的算子 → 交给 NNAPI 代理 → NNAPI 运行时 → 硬件加速器
- 不可委托的算子 → 留在 CPU 上执行
- 最终结果合并，返回给应用
这个「部分委托」的机制非常实用。你想想看，即使你的模型里有一两个 NNAPI 不支持的算子，整个模型仍然能跑，只是那部分慢一点而已。不会像某些框架那样，一个算子不支持就整个崩掉。
避坑指南
我在项目中踩过不少坑，挑几个典型的跟你说说：
- 模型量化问题——NNAPI 对 INT8 量化模型支持最好。如果你用 FP32 模型，加速效果可能不明显。我曾经把一个 FP32 模型直接丢给 NNAPI，结果只快了 20%，后来量化成 INT8，直接快了 4 倍。
- 动态形状模型——NNAPI 对动态输入形状的支持不太好。如果你的模型输入尺寸会变化，建议固定输入尺寸，或者干脆不用 NNAPI 代理。
- 多线程安全——NNAPI 代理本身不是线程安全的。如果你要在多个线程中同时推理，记得为每个线程创建独立的解释器和代理实例。
- 设备兼容性——不是所有 Android 设备都支持 NNAPI。建议在运行时先检测一下：
NnApiDelegate.Delegate.Companion.isSupported(context)
我曾经踩过的坑：有一次在某个低端机上，启用 NNAPI 代理后推理速度反而变慢了。查了半天才发现，那台设备的 NNAPI 驱动有 bug，导致 GPU 调度异常。最后我加了一个「性能兜底」逻辑：如果 NNAPI 推理比 CPU 慢，就自动切回 CPU。这个逻辑我建议你也加上。
小结
NNAPI 代理是 TFLite 和底层硬件加速之间的桥梁。它让你用最少的代码改动，获得最大的性能提升。配置起来很简单，但调优需要一些经验。记住三点：
- 模型尽量量化成 INT8
- 在目标设备上实测性能
- 做好回退机制，防止意外翻车
好了，这一章的内容就到这里。下一章我们会聊聊更高级的话题——如何自定义 NNAPI 的编译缓存策略，让你的应用启动更快。