简介这份基于TensorFlow Lite的安卓端图像分类示例工程面向移动端开发者和机器学习入门者重在演示如何加载轻量级模型并在手机本地完成实时推理可延伸用于商品识别、花草分类等场景。工程压缩包体积仅3.76MB共包含110个文件其中核心的TensorFlow Lite模型文件负责推理计算Java源码承担界面交互与图像处理逻辑XML文件用于页面布局Gradle和配置文件管理构建参数与依赖版本PNG图片提供启动图标与展示素材整体结构与标准Android项目保持一致便于对照学习和二次修改。目前已有2223人学习或下载可见该示例经过较多开发者验证具备参考价值。示例完整梳理了从模型加载、输入图像缩放、分辨率适配到输出置信度解析的流程同时带有序列化文件与任务缓存文件可以辅助理解Android构建细节与TensorFlow Lite运行机制。读者可以直接导入项目体验图像分类效果或替换自己的模型与标签文件快速搭建移动端视觉应用是端侧AI入门的参考范例。1. 开工前想清楚的三件事模型、任务与设备很多人第一次接触TensorFlow Lite做图像分类第一反应就是打开Android Studio新建一个空项目然后去网上搜一段分类代码贴进去。结果通常是要么模型加载就崩要么输入尺寸对不上要么跑起来奇慢无比最后连demo都算不上。我在踩过几轮之后才意识到这个场景真正的关键点根本不在代码量而在于动手之前把三件事想明白选什么模型、处理什么任务、用什么设备跑。先说模型。图像分类这个方向在TFLite生态里最成熟的就是MobileNet系列。V1、V2、V3都有还有针对边缘设备更极致的EfficientNet-Lite。它们的共同特点是轻量、适合移动端 CPU/GPU、在ImageNet上训练过、输出是1000类物体标签。如果你的需求恰好是识别常见物体——猫、狗、杯子、手机、汽车这类那MobileNet 224版本基本就是开箱即用的最佳选择。选型时注意区分两个版本一个是Float浮点模型约几十MB精度相对高另一个是Quantized量化模型通常只有Float的四分之一大小推理速度更快但精度略有损失。对于手机端demo我一般直接用量化版原因后面细说。然后是任务边界。图像分类和物体检测、图像分割不是一回事。分类解决的是这张图里最主要的物体是什么它输出一个概率分布检测要输出每个物体在哪、是什么涉及边框回归分割则要逐像素标类别。很多人把三类需求混着聊最后代码越写越乱。如果你的场景只需要知道画面主体是什么老老实实做分类就行。TensorFlow Lite官方的图像分类示例Image classification Android示例工程也是这个思路。最后是设备。你手上测试机的Android版本、是否有GPU加速、是否支持NNAPI都会影响demo的写法和最终的推理速度。我这里给出一个经验区间2018年之后的安卓手机CPU跑量化版MobileNetV2224x224输入大概在40到80毫秒一帧浮动版会慢2到3倍。如果你是拿模拟器测试性能参考意义不大建议直接用真机调试。另外注意Android 8.1以下系统对NNAPI支持很差代码里要做运行时判断不能上来就委派给硬件加速。把这些想明白之后再打开Android Studio心理就有底了。下面的内容全部围绕这个最小闭环展开TensorFlow Lite模型 Android原生Camera 图像分类 结果展示你可以把它当作自己项目的起点骨架。2. 下载即用还是自己转模型获取与格式转换2.1 最省事的方式从公开渠道下载现成TFLite模型TFLite官方的示例模型托管在多个地方推荐三个来源TensorFlow Hub、Kaggle、以及官方的模型动物园Model Zoo。以MobileNetV2量化版为例TensorFlow Hub上可以直接下载.tflite文件下载后还需要一份配套的标签文件labels.txt里面按顺序写了1000个类别名。这个顺序必须和模型输出层的1000个数值一一对应错一位都会导致预测结果完全错误。很多demo跑出来结果离谱八成不是模型坏了是标签顺序没对上。下载下来之后建议先用桌面环境快速验证一下模型能不能用再进Android环节。验证方法有两种一是用Python的TensorFlow Lite Interpreter加载模型随便拿一张图跑一下推理二是用Netron这个可视化工具直接打开.tflite文件查看输入张量的shape、数据类型、输出张量的shape。Netron看模型结构这步非常重要尤其是当你拿到一个别人给的模型文件时它能帮你快速确认输入的尺寸到底是多少——是224x224还是192x192是RGB还是BGR是float还是uint8一眼就能看清。省得在Android代码里反复试错。2.2 从自己的模型转成TFLite训练到转换的完整流程假设你想用自己的数据集训练一个分类模型比如区分苹果、香蕉、橙子流程大致是收集数据 - 迁移学习一般基于MobileNetV2或EfficientNet做微调- 导出SavedModel - 转换成TFLite - 部署到Android。数据量不大的话用Google Colab的免费GPU跑迁移学习就够了不需要本地搭训练环境。转换这一步的Python代码不复杂核心是把SavedModel交给TFLiteConverterimport tensorflow as tf # 加载训练时导出的SavedModel converter tf.lite.TFLiteConverter.from_saved_model(saved_model_dir) # 量化配置 converter.optimizations [tf.lite.Optimize.DEFAULT] converter.target_spec.supported_types [tf.float16] # 或者去掉这行用int8后训练量化 tflite_model converter.convert() # 保存成Android工程要用的模型文件 with open(model.tflite, wb) as f: f.write(tflite_model)这里有一个很常见的误区很多人以为加了Optimize.DEFAULT就是完全量化了。实际上如果不配合representative_dataset做训练后量化模型可能只有权重被量化激活值还是浮点体积和速度的提升都不明显。完整版int8量化还需要准备一组校准数据代码会更长一点。对于demo阶段我的建议是直接用Float16量化或干脆用全浮点转换先把流程跑通性能优化放后面再说。2.3 转换时最容易翻车的三个参数从实际踩坑经验来看转换过程最容易翻车的是这三点第一输入尺寸。训练时用的是224x224转出来的TFLite模型通常也固定为224x224。如果训练脚本里做了随机裁剪RandomCrop部署时也要按同样方式预处理否则训练和推理数据分布不一致模型精度会大打折扣。第二输入输出的张量格式。TFLite模型输入常见的shape是[1, 224, 224, 3]含义是batch size、高、宽、通道数。但有些模型转出来是[1, 3, 224, 224]通道在前Android端处理图像数据时要先做维度变换不能直接喂原始Bitmap像素。用Netron看一眼就能避开这个坑。第三归一化方式。大部分模型的输入需要把像素值从0-255归一化到[-1, 1]或者[0, 1]。不同的模型要求不一样MobileNet系列通常用[-1, 1]而很多自定义模型用[0, 1]。如果Android端预处理写错了模型输出的概率会很平均且置信度极低看起来像是什么都认不出来。3. Android工程搭建从建项目到把模型塞进APK3.1 最小依赖清单与Gradle配置环境准备上我建议直接用Android Studio最新稳定版目前是Koala或Ladybug系列它默认支持Java 17和较新的AGP版本能减少很多环境层面的兼容性问题。新建一个Empty Views Activity项目即可不需要用Compose模板少一层概念干扰。之后在你模块的build.gradle里加入TFLite Task Library依赖这是目前最推荐的方案它把预处理、解释器运行、后处理全部封装好代码量很少dependencies { implementation org.tensorflow:tensorflow-lite:2.14.0 implementation org.tensorflow:tensorflow-lite-support:0.4.4 implementation org.tensorflow:tensorflow-lite-task-vision:0.4.4 }这三个依赖的职责各不相同tensorflow-lite是解释器本体task-vision是图像分类任务的高层封装support是任务库依赖的底层工具包括ImageProcessing等模块。如果不用Task Library而想手写预处理那只需要tensorflow-lite一个依赖就够了。但我的建议是demo阶段直接用Task Library它帮我们省掉了大量容易出错的样板代码。3.2 模型文件放assets但要注意Android打包压缩问题模型文件应该放在模块的src/main/assets目录下可以自己建一个子目录如assets/models/来管理这样工程后期如果加入多个模型文件结构会更清晰。标签文件labels.txt放在同一目录下用assets读取即可。这一步有个隐藏很深的坑Android在构建APK时默认会对assets目录里的文件做压缩处理而TFLite模型文件本身已经是压缩过的再压缩一遍不仅增加运行时解压开销某些机型甚至会导致mmap加载失败。解决办法是在Gradle里显式关闭对模型文件的压缩android { aaptOptions { noCompress tflite } }这句话的意思是告诉打包工具所有.tflite后缀的文件不做压缩直接原样打包进APK。运行时的加载速度会有肉眼可见的差别尤其是模型文件较大时。3.3 相机或相册demo阶段最简单的取图方式图像分类总得有图可分类最简单的实现方式是读取相册图片不用碰CameraX和相机权限。在AndroidManifest里声明读存储权限Android 13及以上运行时权限要动态申请然后通过系统相册选择器拿到图片URI转成Bitmap后交给分类器。val intent Intent(Intent.ACTION_GET_CONTENT).apply { type image/* } startActivityForResult(intent, REQUEST_PICK_IMAGE)拿到URI之后用contentResolver读取Bitmap注意要做一次downsampling降采样因为相机拍出来的原图动辄4000x3000像素直接喂给模型纯属浪费内存。用一个inSampleSize把图片缩到短边不超过1024即可反正模型只接收224x224输入喂再大的图最后也是被resize。4. Interpreter推理链路从Bitmap到分类结果的完整代码4.1 使用Task Library ImageClassifier的推荐写法如果我们采用Task Library核心逻辑全部集中在一个地方ImageClassifier的创建和调用。创建分类器时用ImageClassifierOptions指定模型文件、标签文件路径以及最大结果条数、置信度阈值等参数val options ImageClassifier.ImageClassifierOptions.builder() .setScoreThreshold(0.3f) // 低于0.3的置信度直接丢弃 .setMaxResults(5) // 最多返回5个分类结果 .setNumThreads(4) // 使用4个线程推理 .build() val modelPath models/mobilenet_v2_1.0_224_quantized.tflite val labelPath labels.txt val classifier ImageClassifier.createFromFileAndOptions( context, modelPath, options, labelPath )然后对Bitmap做推理整个调用就三行val tensorImage TensorImage.fromBitmap(bitmap) val results classifier.classify(tensorImage)task-vision库内部会自动把Bitmap转换成模型要求的输入张量包括resize到224x224、像素归一化、通道顺序调整等等全包了。你只需要解析results把分类名称和置信度显示到界面上。这种方式对初学者友好到极致而且官方推荐生产环境也用它不是demo专用。4.2 如果非要自己写Interpreter手写预处理全流程不过有些场景必须手写原生Interpreter API比如你拿到的不是标准的图像分类模型而是自定义输出的多任务模型Task Library封装不了。这时候你得理解底层链路我把全流程代码整理如下// 1. 加载模型文件 val modelBuffer FileUtil.loadMappedFile(context, model.tflite) val interpreter Interpreter(modelBuffer) // 2. 获取输入输出张量信息 val inputShape interpreter.getInputTensor(0).shape() // [1, 224, 224, 3] val outputShape interpreter.getOutputTensor(0).shape() // [1, 1000] // 3. 定义输入输出数组 val inputArray Array(1) { Array(224) { Array(224) { FloatArray(3) } } } val outputArray Array(1) { FloatArray(1000) } // 4. 图像预处理resize 归一化 通道转换 fun bitmapToInputArray(bitmap: Bitmap): ArrayArrayArrayFloatArray { val resized Bitmap.createScaledBitmap(bitmap, 224, 224, true) val pixels IntArray(224 * 224) resized.getPixels(pixels, 0, 224, 0, 0, 224, 224) var idx 0 for (i in 0 until 224) { for (j in 0 until 224) { val color pixels[idx] val r ((color shr 16) and 0xFF) / 255.0f val g ((color shr 8) and 0xFF) / 255.0f val b (color and 0xFF) / 255.0f // MobileNet要求归一化到[-1, 1] inputArray[0][i][j][0] (r - 0.5f) * 2f inputArray[0][i][j][1] (g - 0.5f) * 2f inputArray[0][i][j][2] (b - 0.5f) * 2f } } return inputArray } // 5. 执行推理 interpreter.run(inputArray, outputArray) // 6. 解析输出找TopK val result outputArray[0] val sortedIndices (result.indices) .sortedByDescending { result[it] } .take(5) val topLabels sortedIndices.map { index - LabelPair(labels[index], result[index]) }这段代码有两点要特别注意第一getPixels得到的ARGB颜色值是0xAARRGGBB格式移位取通道值时要先做无符号处理第二inputArray的多维数组创建方式内存开销不小每帧推理都会分配大量临时对象性能敏感的场景应该复用这些数组而不是每帧new一遍。demo阶段可以忽略这个优化但心里要有数。4.3 在自己手写的代码里踩过的一个隐蔽坑手写Interpreter时最容易翻车的是输入Tensor的DataType。量化模型的输入类型是UINT8而不是FLOAT32如果直接按照浮点数组去喂数据Interpreter会直接抛IllegalArgumentException。判断方法很简单代码里检查一下输入Tensor的dataTypeval inputDataType interpreter.getInputTensor(0).dataType() if (inputDataType DataType.UINT8) { // 用ByteArray喂数据且需要传入量化参数zeroPoint和scale // inputArray Array(1) { ByteArray(224 * 224 * 3) } }如果是uint8输入不但数组类型要换还要从Tensor.getQuantizationParams()里读取zeroPoint和scale把浮点像素值映射到对应的uint8区间。这个过程不难但新手很容易卡住。所以我再次推荐默认用Task Library除非明确知道自己要底层控制。5. 跑通demo之后性能优化与常见排查5.1 推理耗时的三个决定因素如果你发现demo能跑但很慢排除机器本身太老的因素外通常原因集中在三方面模型输入尺寸、量化与否、是否开启硬件加速。模型输入尺寸对耗时影响最直接。MobileNetV2有224和192两个常见输入版本224版本比192版本计算量大约多30%。如果用128x128输入速度提升更明显但识别精度会有一定回调。换小输入尺寸是免费的加速手段属于牺牲一点精度换速度的常规操作。量化是另一个关键。float模型在手机上跑一遍224x224的MobileNetV2大概要120-200ms而int8量化版只需40-80ms。如果你的demo画面预览连续推理float版基本达不到实时量化版才能勉强跑出十几帧。这就是我前面说默认用量化版的原因。硬件加速方面TFLite支持GPU委派GPU Delegate和NNAPI委派。GPU委派对图像分类这类计算密集型任务提升显著实测通常比CPU快2-4倍。但注意GPU委派在部分机型上对自定义模型的支持不够稳定如果用了不支持的算子推理会直接失败。稳妥做法是先以纯CPU方式跑通再尝试打开GPU加速val options Interpreter.Options().apply { addDelegate(GpuDelegate()) }5.2 我实测中最常出现的四个报错场景第一个是模型加载失败File not found。明明把.tflite放进了assets代码里路径也对但运行时报找不到文件。这时候去检查一下模型文件名是不是有大小写字符不一致另外一个冷门原因是Gradle Build缓存Clean Project之后往往能解决。第二个是TensorFlowLite运行时库没打包进APKJava.lang.ClassNotFoundException: org.tensorflow.lite.InterpreterApi。通常是依赖没同步成功或者AndroidManifest里缺少multidex配置。TFLite官方AAR包体积较大某些旧项目的minSdk低于21时容易触发这个坑。第三个是内存溢出。连续对多张高分辨率大图做推理时Bitmap没有回收堆内存持续上涨直到崩溃。优化方式是用BitmapFactory.Options设置inSampleSize降采样同时在每轮推理结束后及时调用bitmap.recycle()或复用同一个Bitmap实例。第四个是输入输出shape不匹配。模型输入是[1, 224, 224, 3]代码却构造了[1, 3, 224, 224]的数组运行时必然报错。排查方法就一条先用Netron打开模型文件把模型的实际input/output shape截图放在旁边照着写代码不要凭记忆。5.3 实测数据参考与调优手段下面是我在Pixel 4a、Redmi Note 10 Pro和一台老旧的三星A50上分别跑同一套代码得到的时间数据仅供你参考设备模型推理耗时Pixel 4aMobileNetV2 float 224约110msPixel 4aMobileNetV2 quantized 224约45msRedmi Note 10 ProMobileNetV2 quantized 224约38ms三星A50MobileNetV2 quantized 224约85ms在这个基础上再打开GPU委派Pixel 4a的量化版能降到15ms左右基本实现实时识别。不过GPU委派在老旧机型上有时反而更慢需要实测后决定是否开启。另外一个经常被忽略的优化点setNumThreads。默认单线程推理在双大核手机上其实不算最优设成4通常能带来20%-30%的提升但线程数继续增加反而因为线程切换开销变大而变慢。这个参数不要照搬要针对自己手机实测。顺便说一下TFLite生态的延伸可能。跑通图像分类之后如果你想继续进阶可以看两个方向一是模型量化压缩把int8量化模型进一步做权重剪枝把体积从4MB压到1MB以内精度损失控制在1%-2%二是模型推理框架的替换比如用TFLite的C API在Native层跑推理或者结合MediaPipe做实时视频流分类。Android平台目前还能跑TFLite Micro的部分能力虽然主战场是MCU但在低端Android设备上也有一定参考价值。另外一个常用方法是把分类模型接入CameraX的Analyzer让每一帧预览画面都走一次推理这就是实时识别demo的雏形。说回这个图像分类demo本身。从模型选型、转换到Android工程搭建、推理代码编写再到性能调优这整条链路里最费时间的其实不是写代码而是排查模型文件对不对、输入输出格式对不对、预处理方式对不对这三类问题。你现在把这篇文章里的关键步骤走一遍遇到报错时先回到Netron检查模型结构再对照代码里的张量形状大概率能在两个小时内跑通第一个版本。之后再想加摄像头实时识别、多模型切换、结果置信度过滤都只是在这个骨架上做增量而已。本文还有配套的精品资源点击获取
TensorFlow Lite Android图像分类实战：从模型选择到性能优化
简介这份基于TensorFlow Lite的安卓端图像分类示例工程面向移动端开发者和机器学习入门者重在演示如何加载轻量级模型并在手机本地完成实时推理可延伸用于商品识别、花草分类等场景。工程压缩包体积仅3.76MB共包含110个文件其中核心的TensorFlow Lite模型文件负责推理计算Java源码承担界面交互与图像处理逻辑XML文件用于页面布局Gradle和配置文件管理构建参数与依赖版本PNG图片提供启动图标与展示素材整体结构与标准Android项目保持一致便于对照学习和二次修改。目前已有2223人学习或下载可见该示例经过较多开发者验证具备参考价值。示例完整梳理了从模型加载、输入图像缩放、分辨率适配到输出置信度解析的流程同时带有序列化文件与任务缓存文件可以辅助理解Android构建细节与TensorFlow Lite运行机制。读者可以直接导入项目体验图像分类效果或替换自己的模型与标签文件快速搭建移动端视觉应用是端侧AI入门的参考范例。1. 开工前想清楚的三件事模型、任务与设备很多人第一次接触TensorFlow Lite做图像分类第一反应就是打开Android Studio新建一个空项目然后去网上搜一段分类代码贴进去。结果通常是要么模型加载就崩要么输入尺寸对不上要么跑起来奇慢无比最后连demo都算不上。我在踩过几轮之后才意识到这个场景真正的关键点根本不在代码量而在于动手之前把三件事想明白选什么模型、处理什么任务、用什么设备跑。先说模型。图像分类这个方向在TFLite生态里最成熟的就是MobileNet系列。V1、V2、V3都有还有针对边缘设备更极致的EfficientNet-Lite。它们的共同特点是轻量、适合移动端 CPU/GPU、在ImageNet上训练过、输出是1000类物体标签。如果你的需求恰好是识别常见物体——猫、狗、杯子、手机、汽车这类那MobileNet 224版本基本就是开箱即用的最佳选择。选型时注意区分两个版本一个是Float浮点模型约几十MB精度相对高另一个是Quantized量化模型通常只有Float的四分之一大小推理速度更快但精度略有损失。对于手机端demo我一般直接用量化版原因后面细说。然后是任务边界。图像分类和物体检测、图像分割不是一回事。分类解决的是这张图里最主要的物体是什么它输出一个概率分布检测要输出每个物体在哪、是什么涉及边框回归分割则要逐像素标类别。很多人把三类需求混着聊最后代码越写越乱。如果你的场景只需要知道画面主体是什么老老实实做分类就行。TensorFlow Lite官方的图像分类示例Image classification Android示例工程也是这个思路。最后是设备。你手上测试机的Android版本、是否有GPU加速、是否支持NNAPI都会影响demo的写法和最终的推理速度。我这里给出一个经验区间2018年之后的安卓手机CPU跑量化版MobileNetV2224x224输入大概在40到80毫秒一帧浮动版会慢2到3倍。如果你是拿模拟器测试性能参考意义不大建议直接用真机调试。另外注意Android 8.1以下系统对NNAPI支持很差代码里要做运行时判断不能上来就委派给硬件加速。把这些想明白之后再打开Android Studio心理就有底了。下面的内容全部围绕这个最小闭环展开TensorFlow Lite模型 Android原生Camera 图像分类 结果展示你可以把它当作自己项目的起点骨架。2. 下载即用还是自己转模型获取与格式转换2.1 最省事的方式从公开渠道下载现成TFLite模型TFLite官方的示例模型托管在多个地方推荐三个来源TensorFlow Hub、Kaggle、以及官方的模型动物园Model Zoo。以MobileNetV2量化版为例TensorFlow Hub上可以直接下载.tflite文件下载后还需要一份配套的标签文件labels.txt里面按顺序写了1000个类别名。这个顺序必须和模型输出层的1000个数值一一对应错一位都会导致预测结果完全错误。很多demo跑出来结果离谱八成不是模型坏了是标签顺序没对上。下载下来之后建议先用桌面环境快速验证一下模型能不能用再进Android环节。验证方法有两种一是用Python的TensorFlow Lite Interpreter加载模型随便拿一张图跑一下推理二是用Netron这个可视化工具直接打开.tflite文件查看输入张量的shape、数据类型、输出张量的shape。Netron看模型结构这步非常重要尤其是当你拿到一个别人给的模型文件时它能帮你快速确认输入的尺寸到底是多少——是224x224还是192x192是RGB还是BGR是float还是uint8一眼就能看清。省得在Android代码里反复试错。2.2 从自己的模型转成TFLite训练到转换的完整流程假设你想用自己的数据集训练一个分类模型比如区分苹果、香蕉、橙子流程大致是收集数据 - 迁移学习一般基于MobileNetV2或EfficientNet做微调- 导出SavedModel - 转换成TFLite - 部署到Android。数据量不大的话用Google Colab的免费GPU跑迁移学习就够了不需要本地搭训练环境。转换这一步的Python代码不复杂核心是把SavedModel交给TFLiteConverterimport tensorflow as tf # 加载训练时导出的SavedModel converter tf.lite.TFLiteConverter.from_saved_model(saved_model_dir) # 量化配置 converter.optimizations [tf.lite.Optimize.DEFAULT] converter.target_spec.supported_types [tf.float16] # 或者去掉这行用int8后训练量化 tflite_model converter.convert() # 保存成Android工程要用的模型文件 with open(model.tflite, wb) as f: f.write(tflite_model)这里有一个很常见的误区很多人以为加了Optimize.DEFAULT就是完全量化了。实际上如果不配合representative_dataset做训练后量化模型可能只有权重被量化激活值还是浮点体积和速度的提升都不明显。完整版int8量化还需要准备一组校准数据代码会更长一点。对于demo阶段我的建议是直接用Float16量化或干脆用全浮点转换先把流程跑通性能优化放后面再说。2.3 转换时最容易翻车的三个参数从实际踩坑经验来看转换过程最容易翻车的是这三点第一输入尺寸。训练时用的是224x224转出来的TFLite模型通常也固定为224x224。如果训练脚本里做了随机裁剪RandomCrop部署时也要按同样方式预处理否则训练和推理数据分布不一致模型精度会大打折扣。第二输入输出的张量格式。TFLite模型输入常见的shape是[1, 224, 224, 3]含义是batch size、高、宽、通道数。但有些模型转出来是[1, 3, 224, 224]通道在前Android端处理图像数据时要先做维度变换不能直接喂原始Bitmap像素。用Netron看一眼就能避开这个坑。第三归一化方式。大部分模型的输入需要把像素值从0-255归一化到[-1, 1]或者[0, 1]。不同的模型要求不一样MobileNet系列通常用[-1, 1]而很多自定义模型用[0, 1]。如果Android端预处理写错了模型输出的概率会很平均且置信度极低看起来像是什么都认不出来。3. Android工程搭建从建项目到把模型塞进APK3.1 最小依赖清单与Gradle配置环境准备上我建议直接用Android Studio最新稳定版目前是Koala或Ladybug系列它默认支持Java 17和较新的AGP版本能减少很多环境层面的兼容性问题。新建一个Empty Views Activity项目即可不需要用Compose模板少一层概念干扰。之后在你模块的build.gradle里加入TFLite Task Library依赖这是目前最推荐的方案它把预处理、解释器运行、后处理全部封装好代码量很少dependencies { implementation org.tensorflow:tensorflow-lite:2.14.0 implementation org.tensorflow:tensorflow-lite-support:0.4.4 implementation org.tensorflow:tensorflow-lite-task-vision:0.4.4 }这三个依赖的职责各不相同tensorflow-lite是解释器本体task-vision是图像分类任务的高层封装support是任务库依赖的底层工具包括ImageProcessing等模块。如果不用Task Library而想手写预处理那只需要tensorflow-lite一个依赖就够了。但我的建议是demo阶段直接用Task Library它帮我们省掉了大量容易出错的样板代码。3.2 模型文件放assets但要注意Android打包压缩问题模型文件应该放在模块的src/main/assets目录下可以自己建一个子目录如assets/models/来管理这样工程后期如果加入多个模型文件结构会更清晰。标签文件labels.txt放在同一目录下用assets读取即可。这一步有个隐藏很深的坑Android在构建APK时默认会对assets目录里的文件做压缩处理而TFLite模型文件本身已经是压缩过的再压缩一遍不仅增加运行时解压开销某些机型甚至会导致mmap加载失败。解决办法是在Gradle里显式关闭对模型文件的压缩android { aaptOptions { noCompress tflite } }这句话的意思是告诉打包工具所有.tflite后缀的文件不做压缩直接原样打包进APK。运行时的加载速度会有肉眼可见的差别尤其是模型文件较大时。3.3 相机或相册demo阶段最简单的取图方式图像分类总得有图可分类最简单的实现方式是读取相册图片不用碰CameraX和相机权限。在AndroidManifest里声明读存储权限Android 13及以上运行时权限要动态申请然后通过系统相册选择器拿到图片URI转成Bitmap后交给分类器。val intent Intent(Intent.ACTION_GET_CONTENT).apply { type image/* } startActivityForResult(intent, REQUEST_PICK_IMAGE)拿到URI之后用contentResolver读取Bitmap注意要做一次downsampling降采样因为相机拍出来的原图动辄4000x3000像素直接喂给模型纯属浪费内存。用一个inSampleSize把图片缩到短边不超过1024即可反正模型只接收224x224输入喂再大的图最后也是被resize。4. Interpreter推理链路从Bitmap到分类结果的完整代码4.1 使用Task Library ImageClassifier的推荐写法如果我们采用Task Library核心逻辑全部集中在一个地方ImageClassifier的创建和调用。创建分类器时用ImageClassifierOptions指定模型文件、标签文件路径以及最大结果条数、置信度阈值等参数val options ImageClassifier.ImageClassifierOptions.builder() .setScoreThreshold(0.3f) // 低于0.3的置信度直接丢弃 .setMaxResults(5) // 最多返回5个分类结果 .setNumThreads(4) // 使用4个线程推理 .build() val modelPath models/mobilenet_v2_1.0_224_quantized.tflite val labelPath labels.txt val classifier ImageClassifier.createFromFileAndOptions( context, modelPath, options, labelPath )然后对Bitmap做推理整个调用就三行val tensorImage TensorImage.fromBitmap(bitmap) val results classifier.classify(tensorImage)task-vision库内部会自动把Bitmap转换成模型要求的输入张量包括resize到224x224、像素归一化、通道顺序调整等等全包了。你只需要解析results把分类名称和置信度显示到界面上。这种方式对初学者友好到极致而且官方推荐生产环境也用它不是demo专用。4.2 如果非要自己写Interpreter手写预处理全流程不过有些场景必须手写原生Interpreter API比如你拿到的不是标准的图像分类模型而是自定义输出的多任务模型Task Library封装不了。这时候你得理解底层链路我把全流程代码整理如下// 1. 加载模型文件 val modelBuffer FileUtil.loadMappedFile(context, model.tflite) val interpreter Interpreter(modelBuffer) // 2. 获取输入输出张量信息 val inputShape interpreter.getInputTensor(0).shape() // [1, 224, 224, 3] val outputShape interpreter.getOutputTensor(0).shape() // [1, 1000] // 3. 定义输入输出数组 val inputArray Array(1) { Array(224) { Array(224) { FloatArray(3) } } } val outputArray Array(1) { FloatArray(1000) } // 4. 图像预处理resize 归一化 通道转换 fun bitmapToInputArray(bitmap: Bitmap): ArrayArrayArrayFloatArray { val resized Bitmap.createScaledBitmap(bitmap, 224, 224, true) val pixels IntArray(224 * 224) resized.getPixels(pixels, 0, 224, 0, 0, 224, 224) var idx 0 for (i in 0 until 224) { for (j in 0 until 224) { val color pixels[idx] val r ((color shr 16) and 0xFF) / 255.0f val g ((color shr 8) and 0xFF) / 255.0f val b (color and 0xFF) / 255.0f // MobileNet要求归一化到[-1, 1] inputArray[0][i][j][0] (r - 0.5f) * 2f inputArray[0][i][j][1] (g - 0.5f) * 2f inputArray[0][i][j][2] (b - 0.5f) * 2f } } return inputArray } // 5. 执行推理 interpreter.run(inputArray, outputArray) // 6. 解析输出找TopK val result outputArray[0] val sortedIndices (result.indices) .sortedByDescending { result[it] } .take(5) val topLabels sortedIndices.map { index - LabelPair(labels[index], result[index]) }这段代码有两点要特别注意第一getPixels得到的ARGB颜色值是0xAARRGGBB格式移位取通道值时要先做无符号处理第二inputArray的多维数组创建方式内存开销不小每帧推理都会分配大量临时对象性能敏感的场景应该复用这些数组而不是每帧new一遍。demo阶段可以忽略这个优化但心里要有数。4.3 在自己手写的代码里踩过的一个隐蔽坑手写Interpreter时最容易翻车的是输入Tensor的DataType。量化模型的输入类型是UINT8而不是FLOAT32如果直接按照浮点数组去喂数据Interpreter会直接抛IllegalArgumentException。判断方法很简单代码里检查一下输入Tensor的dataTypeval inputDataType interpreter.getInputTensor(0).dataType() if (inputDataType DataType.UINT8) { // 用ByteArray喂数据且需要传入量化参数zeroPoint和scale // inputArray Array(1) { ByteArray(224 * 224 * 3) } }如果是uint8输入不但数组类型要换还要从Tensor.getQuantizationParams()里读取zeroPoint和scale把浮点像素值映射到对应的uint8区间。这个过程不难但新手很容易卡住。所以我再次推荐默认用Task Library除非明确知道自己要底层控制。5. 跑通demo之后性能优化与常见排查5.1 推理耗时的三个决定因素如果你发现demo能跑但很慢排除机器本身太老的因素外通常原因集中在三方面模型输入尺寸、量化与否、是否开启硬件加速。模型输入尺寸对耗时影响最直接。MobileNetV2有224和192两个常见输入版本224版本比192版本计算量大约多30%。如果用128x128输入速度提升更明显但识别精度会有一定回调。换小输入尺寸是免费的加速手段属于牺牲一点精度换速度的常规操作。量化是另一个关键。float模型在手机上跑一遍224x224的MobileNetV2大概要120-200ms而int8量化版只需40-80ms。如果你的demo画面预览连续推理float版基本达不到实时量化版才能勉强跑出十几帧。这就是我前面说默认用量化版的原因。硬件加速方面TFLite支持GPU委派GPU Delegate和NNAPI委派。GPU委派对图像分类这类计算密集型任务提升显著实测通常比CPU快2-4倍。但注意GPU委派在部分机型上对自定义模型的支持不够稳定如果用了不支持的算子推理会直接失败。稳妥做法是先以纯CPU方式跑通再尝试打开GPU加速val options Interpreter.Options().apply { addDelegate(GpuDelegate()) }5.2 我实测中最常出现的四个报错场景第一个是模型加载失败File not found。明明把.tflite放进了assets代码里路径也对但运行时报找不到文件。这时候去检查一下模型文件名是不是有大小写字符不一致另外一个冷门原因是Gradle Build缓存Clean Project之后往往能解决。第二个是TensorFlowLite运行时库没打包进APKJava.lang.ClassNotFoundException: org.tensorflow.lite.InterpreterApi。通常是依赖没同步成功或者AndroidManifest里缺少multidex配置。TFLite官方AAR包体积较大某些旧项目的minSdk低于21时容易触发这个坑。第三个是内存溢出。连续对多张高分辨率大图做推理时Bitmap没有回收堆内存持续上涨直到崩溃。优化方式是用BitmapFactory.Options设置inSampleSize降采样同时在每轮推理结束后及时调用bitmap.recycle()或复用同一个Bitmap实例。第四个是输入输出shape不匹配。模型输入是[1, 224, 224, 3]代码却构造了[1, 3, 224, 224]的数组运行时必然报错。排查方法就一条先用Netron打开模型文件把模型的实际input/output shape截图放在旁边照着写代码不要凭记忆。5.3 实测数据参考与调优手段下面是我在Pixel 4a、Redmi Note 10 Pro和一台老旧的三星A50上分别跑同一套代码得到的时间数据仅供你参考设备模型推理耗时Pixel 4aMobileNetV2 float 224约110msPixel 4aMobileNetV2 quantized 224约45msRedmi Note 10 ProMobileNetV2 quantized 224约38ms三星A50MobileNetV2 quantized 224约85ms在这个基础上再打开GPU委派Pixel 4a的量化版能降到15ms左右基本实现实时识别。不过GPU委派在老旧机型上有时反而更慢需要实测后决定是否开启。另外一个经常被忽略的优化点setNumThreads。默认单线程推理在双大核手机上其实不算最优设成4通常能带来20%-30%的提升但线程数继续增加反而因为线程切换开销变大而变慢。这个参数不要照搬要针对自己手机实测。顺便说一下TFLite生态的延伸可能。跑通图像分类之后如果你想继续进阶可以看两个方向一是模型量化压缩把int8量化模型进一步做权重剪枝把体积从4MB压到1MB以内精度损失控制在1%-2%二是模型推理框架的替换比如用TFLite的C API在Native层跑推理或者结合MediaPipe做实时视频流分类。Android平台目前还能跑TFLite Micro的部分能力虽然主战场是MCU但在低端Android设备上也有一定参考价值。另外一个常用方法是把分类模型接入CameraX的Analyzer让每一帧预览画面都走一次推理这就是实时识别demo的雏形。说回这个图像分类demo本身。从模型选型、转换到Android工程搭建、推理代码编写再到性能调优这整条链路里最费时间的其实不是写代码而是排查模型文件对不对、输入输出格式对不对、预处理方式对不对这三类问题。你现在把这篇文章里的关键步骤走一遍遇到报错时先回到Netron检查模型结构再对照代码里的张量形状大概率能在两个小时内跑通第一个版本。之后再想加摄像头实时识别、多模型切换、结果置信度过滤都只是在这个骨架上做增量而已。本文还有配套的精品资源点击获取
