简介：本资源是一个面向Android开发者与移动端AI初学者的TensorFlow Lite图像分类实战Demo，帮助用户快速掌握在移动设备上部署轻量级深度学习模型的核心流程。压缩包共110个文件，包含64个XML布局与配置文件、10个PNG图标资源、9个二进制模型及缓存文件（如.bin）、4个Java核心逻辑代码、3个Gradle构建脚本、1个.tflite模型文件以及配套的gradlew构建工具和环境配置文件，整体体积仅3.76MB，轻量易集成。已有6465人学习下载，反映出其在移动端AI落地实践中的高参考价值。读者可直接导入Android Studio运行，完整复现从模型加载、预处理、推理到结果渲染的全流程；项目结构清晰，含明确的ModelInterpreter封装、CameraX实时采集适配及分类结果UI反馈模块，同时提供编译依赖配置与常见JNI兼容性提示，显著降低TF Lite Android端入门门槛。
1. 这不是“跑通就行”的 Hello World：TensorFlow Lite 图像分类在 Android 真机上稳定推理的完整链路
你手头有一份训练好的 TensorFlow 模型，想让它在 Android 手机上实时识别摄像头画面里的猫狗——但刚把 .tflite 文件丢进 assets 目录，Interpreter初始化就报IllegalArgumentException: ByteBuffer is not a valid flatbuffer model；或者模型加载成功了，输入ByteBuffer.allocateDirect()分配的缓冲区后，run()返回全零输出；更常见的是，模拟器里一切正常，一上真机（尤其中低端机型）就卡顿、OOM、甚至直接闪退。这不是环境配置问题，而是 TF Lite 在 Android 平台落地时，模型转换、内存对齐、线程调度、输入预处理、输出解析这五个环节存在强耦合的隐性约束。本 demo 不是教你怎么导出 .tflite，而是把从 Keras 模型到手机端可部署、可调试、可量产的完整链路拆解成可验证的步骤：它包含一个已验证兼容 Android 8.0+ 的轻量级 MobileNetV2 分类模型（.tflite + label.txt），配套 Java/Kotlin 双语言推理封装类，以及针对CameraX的实时帧捕获与预处理 pipeline。适合正在做移动端 AI 集成、需要快速验证算法效果、或被TfLiteDelegate崩溃日志折磨超过 3 小时的工程师。
2. 模型准备：为什么必须用 TFLiteConverter.from_saved_model 而不是 from_keras_model？
TF Lite 的模型转换不是“格式转换”，而是图结构重写 + 算子融合 + 量化感知插入的过程。直接from_keras_model会跳过关键的图优化阶段，导致生成的 .tflite 在 Android 上出现Op not supported错误（如FusedBatchNormV3未被正确折叠）。我们采用from_saved_model流程，确保所有算子被标准化为 TF Lite 支持的原语。
2.1 保存为 SavedModel 格式：冻结计算图并显式指定输入签名
Keras 模型需先转为 SavedModel，才能触发完整的图优化。注意：必须显式定义input_signature，否则TFLiteConverter无法推断动态 batch size 和 shape，导致后续 Android 端resizeInput()失效。
import tensorflow as tf from tensorflow.keras.applications import MobileNetV2 # 加载预训练模型（不带顶层） model = MobileNetV2(weights='imagenet', include_top=True, input_shape=(224, 224, 3)) # 构建一个 dummy 输入用于 trace（关键！） dummy_input = tf.random.normal([1, 224, 224, 3]) _ = model(dummy_input) # 必须执行一次前向传播，确保图完整 # 保存为 SavedModel，显式指定 input_signature tf.saved_model.save( model, 'mobilenetv2_savedmodel', signatures={ 'serving_default': model.call.get_concrete_function( tf.TensorSpec(shape=[1, 224, 224, 3], dtype=tf.float32, name='input') ) } )逻辑说明：
get_concrete_function()强制将模型的call方法编译为静态图，并绑定输入张量的 shape/dtype。tf.saved_model.save()保存的不是 Python 对象，而是序列化的计算图和权重，这是 TFLiteConverter 的唯一可靠输入源。
2.2 使用 TFLiteConverter.from_saved_model 转换：启用默认优化并禁用实验性算子
转换时启用DEFAULT优化等级，它会自动执行算子融合（如 Conv+BN+ReLU 合并）、常量折叠（Constant Folding）和冗余节点剪枝。禁用EXPERIMENTAL_PRESERVE_ALL_TENSORS是关键——该标志会保留所有中间张量名，导致模型体积膨胀 30% 且在部分 Android 设备上触发Invalid tensor index错误。
converter = tf.lite.TFLiteConverter.from_saved_model('mobilenetv2_savedmodel') # 启用默认优化（必须！） converter.optimizations = [tf.lite.Optimize.DEFAULT] # 禁用实验性张量保留（必须！） converter.experimental_preserve_all_tensors = False # 设置目标 API 兼容性（Android 8.0+ 对应 TF Lite 2.3+） converter.target_spec.supported_ops = [ tf.lite.OpsSet.TFLITE_BUILTINS, # 标准算子 tf.lite.OpsSet.SELECT_TF_OPS # 如需调用 TF 原生算子（本例不需要） ] # 转换并保存 tflite_model = converter.convert() with open('mobilenetv2_quant.tflite', 'wb') as f: f.write(tflite_model)参数说明：
Optimize.DEFAULT：启用图优化、权重量化（int8）、算子融合，但不改变模型精度（区别于OPTIMIZE_FOR_SIZE或OPTIMIZE_FOR_LATENCY）；supported_ops中仅保留TFLITE_BUILTINS，避免引入SELECT_TF_OPS导致的libtensorflowlite.so动态链接失败；- 输出的
.tflite文件大小应为 3.8~4.2 MB（MobileNetV2 FP16 权重），若 >5 MB 则说明experimental_preserve_all_tensors=True未关闭。
2.3 验证模型有效性：用 Python 解释器做端到端输出比对
在 Android 部署前，必须用 Python 端tf.lite.Interpreter验证模型输出是否与原始 Keras 模型一致。这是唯一能提前发现量化误差、输入归一化偏差、输出 softmax 丢失等问题的手段。
# 加载原始 Keras 模型和 TFLite 模型 keras_model = tf.keras.models.load_model('mobilenetv2_savedmodel') interpreter = tf.lite.Interpreter(model_path='mobilenetv2_quant.tflite') interpreter.allocate_tensors() # 准备相同输入（注意：Keras 模型输入需归一化到 [0,1]，TFLite 默认 [-1,1]） input_image = tf.io.decode_image(tf.io.read_file('cat.jpg'), channels=3) input_image = tf.image.resize(input_image, [224, 224]) input_image = tf.cast(input_image, tf.float32) / 255.0 # Keras 归一化 input_image_tflite = (input_image * 2.0) - 1.0 # TFLite 归一化：[0,1] → [-1,1] # Keras 推理 keras_output = keras_model(input_image[None, ...]).numpy() # TFLite 推理 input_details = interpreter.get_input_details()[0] output_details = interpreter.get_output_details()[0] interpreter.set_tensor(input_details['index'], input_image_tflite[None, ...]) interpreter.invoke() tflite_output = interpreter.get_tensor(output_details['index']) # 比较 top-1 索引是否一致（容忍 1e-3 误差） print("Keras top-1:", np.argmax(keras_output)) print("TFLite top-1:", np.argmax(tflite_output)) print("Max diff:", np.max(np.abs(keras_output - tflite_output)))关键结论：若
np.argmax()结果不一致，或Max diff > 1e-2，说明模型转换或预处理存在严重偏差，绝不能进入 Android 阶段。常见原因是：Keras 模型使用Rescaling(1./255)层而 TFLite 未同步归一化逻辑。
3. Android 工程集成：从 assets 加载到线程安全推理的 Java 封装
Android 端的核心挑战不是“怎么调用 Interpreter”，而是如何在主线程/后台线程间安全传递ByteBuffer，如何避免allocateDirect()内存泄漏，以及如何让CameraX的ImageProxy数据无缝喂入模型。我们提供一个生产级封装类TFLiteClassifier，它隐藏了所有底层细节。
3.1 创建 TFLiteClassifier：管理 Interpreter 生命周期与线程锁
TFLiteClassifier必须是单例或 Activity/Fragment 级别生命周期绑定的对象，禁止在onCreate()中创建并在onDestroy()中释放Interpreter——因为CameraX的ImageAnalysis可能在 Activity 销毁后仍回调。我们采用Application级别初始化 +WeakReference持有策略。
public class TFLiteClassifier { private static final String MODEL_PATH = "mobilenetv2_quant.tflite"; private static final String LABEL_PATH = "labels.txt"; private final Context context; private final Object lock = new Object(); // 线程锁，保护 Interpreter private final List<String> labels; private final int inputSize = 224; private final float[] mean = {127.5f, 127.5f, 127.5f}; // TFLite 默认归一化均值 private final float[] std = {127.5f, 127.5f, 127.5f}; // TFLite 默认归一化标准差 private MappedByteBuffer tfliteModel; private TfLite tflite; public TFLiteClassifier(Context context) throws IOException { this.context = context.getApplicationContext(); this.labels = loadLabels(); this.tfliteModel = loadModelFile(); this.tflite = new TfLite(this.tfliteModel); } private MappedByteBuffer loadModelFile() throws IOException { AssetFileDescriptor fileDescriptor = context.getAssets().openFd(MODEL_PATH); FileInputStream inputStream = new FileInputStream(fileDescriptor.getFileDescriptor()); FileChannel fileChannel = inputStream.getChannel(); long startOffset = fileDescriptor.getStartOffset(); long declaredLength = fileDescriptor.getDeclaredLength(); return fileChannel.map(FileChannel.MapMode.READ_ONLY, startOffset, declaredLength); } private List<String> loadLabels() throws IOException { List<String> labels = new ArrayList<>(); BufferedReader reader = new BufferedReader( new InputStreamReader(context.getAssets().open(LABEL_PATH))); String line; while ((line = reader.readLine()) != null) { labels.add(line); } reader.close(); return labels; } }逻辑说明：
MappedByteBuffer将模型文件内存映射到进程地址空间，避免一次性读入堆内存（防止 OOM）；TfLite构造函数内部调用new Interpreter(tfliteModel)，此时模型被解析但未分配输入/输出缓冲区。
3.2 输入预处理：YUV_420_888 → RGB → Resize → Normalize 的零拷贝路径
CameraX的ImageAnalysis输出ImageProxy格式为YUV_420_888，而模型输入要求RGB格式的ByteBuffer。直接YUV_420_888→Bitmap→ARGB_8888→ByteBuffer会产生 3 次内存拷贝，导致 15ms+ 延迟。我们采用YUV_420_888直接转RGB的 JNI 实现（已封装在yuv2rgb_jni.c中），并通过ByteBuffer.allocateDirect()分配 native 内存，实现零 GC 压力。
// 在 TFLiteClassifier 中添加 private final ByteBuffer inputBuffer; // Direct buffer for model input public TFLiteClassifier(Context context) throws IOException { // ... previous init ... this.inputBuffer = ByteBuffer.allocateDirect( inputSize * inputSize * 3 // 224x224x3 bytes ); } // 关键方法：将 ImageProxy 转为 RGB 并写入 inputBuffer public void convertYUV420ToRGB(ImageProxy image) { ImageProxy.PlaneProxy yPlane = image.getPlanes()[0]; ImageProxy.PlaneProxy uPlane = image.getPlanes()[1]; ImageProxy.PlaneProxy vPlane = image.getPlanes()[2]; // 调用 JNI 函数，将 YUV 数据直接写入 inputBuffer yuv2rgb( yPlane.getBuffer(), yPlane.getPixelStride(), yPlane.getRowStride(), uPlane.getBuffer(), uPlane.getPixelStride(), uPlane.getRowStride(), vPlane.getBuffer(), vPlane.getPixelStride(), vPlane.getRowStride(), inputBuffer, inputSize, inputSize ); } // JNI 声明（对应 yuv2rgb_jni.c） private static native void yuv2rgb( ByteBuffer yBuffer, int yPixelStride, int yRowStride, ByteBuffer uBuffer, int uPixelStride, int uRowStride, ByteBuffer vBuffer, int vPixelStride, int vRowStride, ByteBuffer outBuffer, int width, int height );参数说明：
yuv2rgb函数内部使用libyuv的I420ToRGB24，将 YUV_420_888（Planar）数据按 stride 步长解析，直接写入outBuffer，全程无中间Bitmap对象。inputBuffer的 capacity 必须严格等于width * height * 3，否则 JNI 写入越界。
3.3 线程安全推理：使用 synchronized 块 + resizeInput() 动态适配
Interpreter.run()不是线程安全的，且CameraX的ImageAnalysis回调可能在任意线程执行。必须用synchronized(lock)包裹setTensor()和run()，并每次调用前检查输入尺寸是否匹配。
public Recognition recognizeImage(ImageProxy image) { if (tflite == null) return null; // 1. 将 YUV 转为 RGB 并写入 inputBuffer convertYUV420ToRGB(image); // 2. 归一化：RGB [0,255] → Float [-1,1] float[] normalized = new float[inputSize * inputSize * 3]; for (int i = 0; i < normalized.length; i++) { normalized[i] = (inputBuffer.get(i) & 0xFF) / 127.5f - 1.0f; } // 3. 同步执行推理 synchronized (lock) { // 确保输入尺寸正确（防止 CameraX 动态调整分辨率导致崩溃） if (tflite.getInputTensor(0).numBytes() != normalized.length * 4) { tflite.resizeInput(0, new int[]{1, inputSize, inputSize, 3}); } tflite.setInput(0, normalized); tflite.run(); float[][] output = new float[1][1001]; // MobileNetV2 输出 1001 类 tflite.getOutput(0, output); return getTopKRecogntions(output[0], 3); } } private Recognition getTopKRecogntions(float[] output, int k) { PriorityQueue<Recognition> pq = new PriorityQueue<>( k, (a, b) -> Float.compare(a.getConfidence(), b.getConfidence()) ); for (int i = 0; i < output.length; i++) { if (pq.size() < k || output[i] > pq.peek().getConfidence()) { pq.offer(new Recognition("" + i, labels.get(i), output[i])); if (pq.size() > k) pq.poll(); } } return pq.poll(); }逻辑说明：
resizeInput()是安全的，它会重新分配内部缓冲区；synchronized(lock)确保同一时刻只有一个线程访问Interpreter；getTopKRecogntions使用最小堆提取 top-k，避免对 1001 维数组全排序。
4. 避坑：Android 端 TF Lite 推理的五个血泪现场
这些坑不是文档里写的“注意事项”，而是真机实测中反复翻车的硬伤。每一条都对应一个adb logcat | grep "tflite"能抓到的具体错误码。
4.1 现象：java.lang.IllegalArgumentException: Internal error: Failed to run on the given Interpreter: tensorflow/lite/kernels/conv.cc:343 input->dims->data[3] != filter->dims->data[2] (224 != 3)
原因：模型输入张量声明为[1,224,224,3]，但Interpreter.setInput()传入的float[]长度是224*224*3=150528，而Interpreter内部期望的是ByteBuffer（每个 float 占 4 字节），实际传入字节数为150528*4=602112，导致维度解析错乱。
解决：永远用ByteBuffer作为setInput()的输入类型，不要用float[]。修改recognizeImage()中的归一化逻辑：
// 错误：传入 float[] // tflite.setInput(0, normalized); // 正确：传入 ByteBuffer ByteBuffer byteBuffer = ByteBuffer.allocateDirect(normalized.length * 4); for (float f : normalized) { byteBuffer.putFloat(f); } tflite.setInput(0, byteBuffer);4.2 现象：E/tflite: Node number 0 (CONV_2D) failed to prepare
原因：libtensorflowlite.so未正确加载。常见于build.gradle中abiFilters未包含目标设备 ABI（如arm64-v8a），或minSdkVersion< 21（TF Lite 要求 Android 5.0+）。
解决：在app/build.gradle中强制指定 ABI 并检查 SDK 版本：
android { defaultConfig { minSdkVersion 21 // 必须 >=21 ndk { abiFilters 'arm64-v8a', 'armeabi-v7a' // 至少包含这两个 } } }4.3 现象：W/tflite: Allocation of X bytes failed（X > 10MB）
原因：allocateDirect()分配的ByteBuffer未被及时回收，或Interpreter未释放导致 native 内存泄漏。CameraX的ImageProxy回调频率高（30fps），若convertYUV420ToRGB()中ByteBuffer复用不当，会累积内存。
解决：复用inputBuffer，禁止在每次回调中新建ByteBuffer。TFLiteClassifier的inputBuffer是final的，convertYUV420ToRGB()直接写入其内部，无需 new。
4.4 现象：E/tflite: Node number Y (SOFTMAX) failed to invoke
原因：输出张量未正确获取。getOutput(0, output)中output数组长度与模型输出维度不匹配（如 MobileNetV2 应为 1001，但声明为new float[1000]）。
解决：永远用getOutputTensor(0).numElements()获取输出维度：
int outputSize = tflite.getOutputTensor(0).numElements(); float[] output = new float[outputSize]; tflite.getOutput(0, output);4.5 现象：E/AndroidRuntime: FATAL EXCEPTION: CameraX-core_io_executor
原因：ImageProxy.close()在ImageAnalysis回调中被多次调用。CameraX的ImageProxy是引用计数对象，close()必须且只能调用一次。若recognizeImage()中因异常提前 return，image.close()未执行，下次回调时image已失效。
解决：用 try-finally 强制 close：
public void analyze(@NonNull ImageProxy image) { try { Recognition result = classifier.recognizeImage(image); // 更新 UI } finally { image.close(); // 确保执行 } }5. CameraX 实时流水线：从预览帧到分类结果的毫秒级延迟控制
CameraX的ImageAnalysis是 Android 端最稳定的图像分析入口，但它默认以最大帧率推送ImageProxy，而 TF Lite 推理耗时约 8~15ms（中端机），若不做节流，会导致ImageProxy队列堆积、内存暴涨、最终 ANR。我们必须实现帧采样 + 异步推理 + 结果缓存三位一体的流水线。
5.1 帧采样策略：用 AtomicBoolean 控制推理节流
ImageAnalysis的setBackpressureStrategy()仅控制队列行为，不解决 CPU 过载。我们采用“令牌桶”思想：用AtomicBoolean作为推理许可开关，只有当上一帧推理完成且 UI 更新完毕后，才允许处理下一帧。
public class CameraAnalyzer implements ImageAnalysis.Analyzer { private final TFLiteClassifier classifier; private final AtomicBoolean canAnalyze = new AtomicBoolean(true); private final Handler mainHandler = new Handler(Looper.getMainLooper()); public CameraAnalyzer(TFLiteClassifier classifier) { this.classifier = classifier; } @Override public void analyze(@NonNull ImageProxy image) { if (!canAnalyze.compareAndSet(true, false)) { image.close(); // 拒绝此帧 return; } // 异步执行推理（避免阻塞 CameraX 线程） Executors.newSingleThreadExecutor().execute(() -> { try { Recognition result = classifier.recognizeImage(image); // 切回主线程更新 UI mainHandler.post(() -> { updateUI(result); canAnalyze.set(true); // 释放令牌 }); } catch (Exception e) { Log.e("CameraAnalyzer", "Inference failed", e); mainHandler.post(() -> canAnalyze.set(true)); } }); } private void updateUI(Recognition result) { // 更新 TextView 或 OverlayView resultTextView.setText(String.format("%s: %.2f%%", result.getTitle(), result.getConfidence() * 100)); } }逻辑说明：
canAnalyze.compareAndSet(true, false)是原子操作，确保同一时刻最多一个推理任务在执行；Executors.newSingleThreadExecutor()保证推理串行化，避免多线程竞争Interpreter；mainHandler.post()将 UI 更新切回主线程，符合 Android 开发规范。
5.2 输出结果缓存：避免高频 UI 刷新导致的掉帧
ImageAnalysis可能以 30fps 推送帧，但 UI 刷新 60fps 已足够。若每帧都setText()，会导致TextView频繁重绘，拖慢主线程。我们采用“结果缓存 + 定时刷新”策略：只在结果置信度变化 >5% 或类别变更时更新 UI，并用Handler.postDelayed()限频。
private static final long MIN_UPDATE_INTERVAL_MS = 100; // 最小刷新间隔 100ms private Recognition cachedResult; private final Handler updateHandler = new Handler(Looper.getMainLooper()); private final Runnable updateRunnable = new Runnable() { @Override public void run() { if (cachedResult != null) { updateUI(cachedResult); } } }; private void updateUI(Recognition result) { // 只有置信度变化 >5% 或类别不同才更新缓存 if (cachedResult == null || !result.getTitle().equals(cachedResult.getTitle()) || Math.abs(result.getConfidence() - cachedResult.getConfidence()) > 0.05f) { cachedResult = result; // 移除旧任务，提交新任务 updateHandler.removeCallbacks(updateRunnable); updateHandler.postDelayed(updateRunnable, MIN_UPDATE_INTERVAL_MS); } }参数说明：
MIN_UPDATE_INTERVAL_MS=100意味着 UI 最多每秒刷新 10 次，既保证用户感知流畅，又避免主线程过载。removeCallbacks()确保不会因快速连续结果导致任务堆积。
5.3 性能验证：用 Systrace 抓取端到端延迟链路
要确认流水线是否真正低延迟，必须用 Android Studio 的Systrace抓取CameraX、ImageAnalysis、TFLite、UI四个域的执行时间。关键指标是analyze()回调到updateUI()的总耗时，理想值应 < 50ms（20fps）。
# 在终端执行（连接真机） python $ANDROID_HOME/platform-tools/systrace/systrace.py \ -t 10 \ -a com.yourpackage.name \ sched gfx view wm am sm input audio video binder_driver hal dalvik camera res memory排查技巧：在 Systrace 中搜索
TFLiteClassifier.recognizeImage，观察其执行块是否被Binder或Camera事件阻塞；若updateUI()块持续 >16ms（1帧），说明TextView绘制过重，应改用Canvas自定义 View。
6. 进阶技巧：用 GPU Delegate 加速推理并验证加速效果
TF Lite 的GpuDelegate可将卷积、激活等密集计算卸载到 GPU，中端机（如骁龙 710）上推理速度提升 2~3 倍。但GPU Delegate 不是开箱即用的“加速开关”，它要求模型算子全部支持 GPU，且需手动验证输出一致性。
6.1 启用 GPU Delegate：在 TFLiteClassifier 构造函数中注入
GpuDelegate必须在Interpreter创建前初始化，并通过addDelegate()注入。注意：GpuDelegate实例必须持有强引用，否则会被 GC 回收导致Interpreter崩溃。
public class TFLiteClassifier { private GpuDelegate gpuDelegate; // 强引用，防止 GC public TFLiteClassifier(Context context) throws IOException { this.context = context.getApplicationContext(); this.labels = loadLabels(); this.tfliteModel = loadModelFile(); // 初始化 GPU Delegate（仅 Android 8.1+） if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O_MR1) { gpuDelegate = new GpuDelegate(); } // 创建 Interpreter 并添加 Delegate tflite = new TfLite(this.tfliteModel); if (gpuDelegate != null) { tflite.addDelegate(gpuDelegate); } } }逻辑说明：
GpuDelegate依赖libtensorflowlite_gpu_delegate.so，该 so 文件由org.tensorflow:tensorflow-lite-gpu提供，需在build.gradle中添加依赖：
implementation 'org.tensorflow:tensorflow-lite-gpu:2.13.0'6.2 验证 GPU 加速有效性：对比 CPU/GPU 的输出差异与耗时
启用 GPU 后，必须验证两点：1）输出结果是否与 CPU 一致；2）耗时是否显著下降。我们扩展recognizeImage()为benchmarkInference()，返回BenchmarkResult。
public static class BenchmarkResult { public final long cpuTimeNs; public final long gpuTimeNs; public final float[] cpuOutput; public final float[] gpuOutput; } public BenchmarkResult benchmarkInference(ImageProxy image) throws Exception { // CPU 推理 long cpuStart = System.nanoTime(); float[] cpuOutput = runInferenceOnCPU(image); long cpuEnd = System.nanoTime(); // GPU 推理（需先移除 GPU Delegate，再重建 Interpreter） TfLite gpuInterpreter = new TfLite(tfliteModel); gpuInterpreter.addDelegate(gpuDelegate); long gpuStart = System.nanoTime(); float[] gpuOutput = runInferenceOnGPU(gpuInterpreter, image); long gpuEnd = System.nanoTime(); return new BenchmarkResult( cpuEnd - cpuStart, gpuEnd - gpuStart, cpuOutput, gpuOutput ); } private float[] runInferenceOnCPU(ImageProxy image) { // 复用原有 recognizeImage 逻辑，但返回 output 数组 } private float[] runInferenceOnGPU(TfLite interpreter, ImageProxy image) { // 类似 recognizeImage，但使用传入的 interpreter }验证标准：
cpuOutput与gpuOutput的max(abs(diff))应 < 1e-3；gpuTimeNs应 ≤ 0.5 *cpuTimeNs。若差异过大，说明模型中存在 GPU 不支持的算子（如ResizeBilinear），需在转换时添加converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS, tf.lite.OpsSet.EXPERIMENTAL_TFLITE_BUILTINS_ACTIVATIONS_INT16_WEIGHTS_INT8]。
6.3 GPU Delegate 的边界与降级策略：当 GPU 不可用时自动回退
GpuDelegate可能因驱动版本过低、GPU 内存不足、或模型含不支持算子而初始化失败。不能让 App 因GpuDelegate失败而崩溃，必须实现优雅降级。
public TFLiteClassifier(Context context) throws IOException { // ... load model ... // 尝试初始化 GPU Delegate try { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O_MR1) { gpuDelegate = new GpuDelegate(); // 强制触发初始化，捕获异常 TfLite testInterpreter = new TfLite(tfliteModel); testInterpreter.addDelegate(gpuDelegate); testInterpreter.close(); } } catch (Exception e) { Log.w("TFLiteClassifier", "GPU Delegate init failed, fallback to CPU", e); gpuDelegate = null; } tflite = new TfLite(tfliteModel); if (gpuDelegate != null) { tflite.addDelegate(gpuDelegate); } }关键教训：从那以后我每次集成
GpuDelegate，都强制走一遍try-catch初始化 +testInterpreter验证流程，绝不假设“只要加了依赖就一定能用”。GPU 加速是锦上添花，CPU 正确性才是雪中送炭。希望帮到你。
本文还有配套的精品资源，点击获取
