简介一款基于Java的Android植物病虫害智能识别应用源码包定位为完整的项目工程示例面向Android应用开发者、农业信息化方向学习者以及希望快速搭建识别功能原型的项目团队。压缩包共139个文件大小约6.49MB其中包含53个XML布局文件用于定义首页、识别结果、用户设置等界面34个Java源文件承载图像采集、特征提取与病虫害识别等核心逻辑另有27个PNG和10个WEBP图片资源、Gradle构建配置与脚本文件共同构成可读、可构建的工程结构。项目将界面设计与识别流程完整打通读者可借此理解从页面布局到业务逻辑落地的实现路径学习如何组织布局资源、编写Android业务代码并完成构建配置同时也可将其作为课程设计、毕业设计或实际项目原型的参考起点。已有360人学习浏览适合作为移动端智能识别应用开发的参考模板也可基于自身需求扩展更多病害类型或优化识别算法。1. 植物病虫害智能识别App本质是把图像分类模型塞进手机写Java/Android的人看到「植物病虫害智能识别」这标题通常会误判成「AI训练」主导的项目。接手过此类工程就知道模型能到95%的准确率只代表起点真正的工程量在「如何让模型跑在千元机上还能连续出结果」图像预处理要与训练时严格对齐、相机帧要避开UI线程、模型体积要控制在可安装包不破百兆更麻烦的是葱叶上的病斑和泥土阴影在颜色分布上几乎没差别。这里直接按「选型 → 模型转换 → 集成实现 → 性能优化 → 真机验证」的顺序把一套可交付的做法讲透。适合做农林业信息化App、智能硬件配套以及拿这个题目做课程设计与毕业设计的人新手可以照步骤复现有经验的人可以看参数和排错细节。2. 技术选型Java写Android识别推理链路怎么搭2.1 为什么在Kotlin主导的Android生态里还选Java过去两三年新开的Android项目大多用Kotlin但植物病虫害识别这个方向存量代码和参考资料里Java占比仍然很高。原因很具体农业院校和研究所的老项目要维护毕设题目固定给了Java模板团队里做嵌入式与后端的人写Java更顺手。Java的意义不在于“更好”而在于“好接手”——TFLite的Java API在1.x时代就稳定了教程、Stack Overflow案例、Gradle依赖版本都沉淀充分遇到编译问题搜索成本低。用Android Studio新建工程时选Java模板目标是把识别功能做稳定选Java是性价比选择不是技术倒退。Kotlin可以调用Java写的识别器反过来Java里也能用Kotlin模块但既然工程标题讲的是Java设计源码整体就该保持一致全工程用Java写避免双语言混编在构建时引入额外配置。我的做法是Gradle里把sourceCompatibility和targetCompatibility固定在Java 8不追新语法因为要覆盖Android 5到14的设备Java 8的兼容面最广。如果之后真需要协程再单独引入kotlin-stdlib不影响主体代码。2.2 Android上跑植物分类的三条路线对比手上已经有一个训练好的病虫害分类模型时把它跑进Android有三种常见路线TFLite、ONNX Runtime、OpenCV DNN模块。三者的取舍看下表。方案模型来源推理速度千元机集成复杂度适合场景TensorFlow LiteKeras/PyTorch转换约20-40ms/张低官方支持好移动端首选量化成熟ONNX Runtime AndroidPyTorch/ONNX导出约30-60ms/张中需要自己管理so库团队已固用ONNXOpenCV DNNCaffe/TF/ONNX约80-150ms/张低但体积大顺带做图像处理绝大多数病虫害识别任务用TFLite。一是因为后训练量化可以把模型压到四分之一大小对在田间用老手机拍摄的场景很关键二是因为Android上它有GPU delegate和NNAPI delegate两条加速路径不用自己写JNI。ONNX Runtime在服务端部署时更合适纯Android端选它反而要多处理一层so库透传。OpenCV DNN适合模型固定不做量化的原型验证真要交付体积和内存都没有优势。2.3 不让推理卡UI按模块拆工程工程结构上我习惯拆成三个模块而不是一把梭写在MainActivity里app负责页面和相机流程core放图像预处理、Bitmap工具与文件存取ml放模型加载、推理封装和结果后处理。这种拆法核心收益是调试时能单独跑单元测试给ml模块传一张固定图片不打开相机就能验证推理输出是否正确。一个能工作的依赖配置大概这样。android { compileSdk 34 defaultConfig { applicationId com.example.plantdiagnosis minSdk 24 targetSdk 34 versionCode 1 versionName 1.0 } compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 } } dependencies { implementation androidx.camera:camera-core:1.3.1 implementation androidx.camera:camera-camera2:1.3.1 implementation androidx.camera:camera-lifecycle:1.3.1 implementation org.tensorflow:tensorflow-lite:2.14.0 implementation org.tensorflow:tensorflow-lite-gpu:2.14.0 implementation com.squareup.okhttp3:okhttp:4.12.0 }minSdk 24是刻意选的Android 7.0及以上覆盖绝大多数存量设备又避开了早期机型在Camera2和Bitmap内存上的历史坑。tensorflow-lite-gpu单独加是因为GPU delegate在部分设备上会初始化失败代码里要做fallback后面第5章细讲。依赖锁住之后识别器代码和相机代码才有稳定的编译基础。3. 模型落地把病虫害分类模型转成TFLite并封装识别器3.1 从训练权重到Android可加载的.tflite模型训练用Keras还是PyTorch不影响Android端最终都要落到SavedModel或ONNX再转TFLite。常见做法是训练阶段就保留一份导出脚本这样模型迭代时不需要手工操作。以Keras训练出的病虫害分类模型为例转换命令如下。# 训练完模型后在工程根目录执行导出 python export_tflite.py \ --saved_model_dir./saved_models/plant_disease_v3 \ --output_path./android_app/app/src/main/assets/model.tflite \ --quantizetrue对应的export_tflite.py关键代码只有几行。import tensorflow as tf converter tf.lite.TFLiteConverter.from_saved_model( ./saved_models/plant_disease_v3 ) # 开启后训练量化float32权重转为float16 converter.optimizations [tf.lite.Optimize.DEFAULT] converter.target_spec.supported_types [tf.float16] tflite_model converter.convert() with open(./android_app/app/src/main/assets/model.tflite, wb) as f: f.write(tflite_model)转换时最容易踩的坑是忘了把输入shape固定。训练时输入是(None, 224, 224, 3)没问题但转TFLite时最好显式指定[1, 224, 224, 3]否则生成的模型在部分TFLite版本上第一次推理会因resize_input_tensor没被调用而报错。固定shape还能省掉每次动态reshape的开销推理速度稳定。3.2 量化要看到具体收益先比大小再看掉点量化不是必须的判断标准很直接在测试集上量化前后准确率掉点小于1.5%就启用。病虫害二分类有病/无病任务通常掉点很小但多分类细粒度识别比如区分叶斑病和锈病对颜色纹理敏感量化可能掉3%以上遇到这种情况就退回到float16量化模型大小只减半掉点几乎为零。三类量化策略对比如下。量化方式体积缩减典型掉点适用场景无量化float321x0设备性能好、包体不敏感float16量化约50%0.5%内折中方案兼容性最好全整型int8量化约75%1%-3%低端机为主、包体敏感还有一个很实际的检查模型文件放进去之后先在Android里打印一次模型输入输出详情确认shape和dtype跟训练保持一致。在MainActivity或单元测试里写一段加载代码看日志。Interpreter interpreter new Interpreter(loadModelFile(context)); // 打印输入输出张量信息确认和训练一致 Log.d(TFLiteInfo, input: interpreter.getInputTensor(0).shape()); Log.d(TFLiteInfo, input type: interpreter.getInputTensor(0).dataType()); Log.d(TFLiteInfo, output: interpreter.getOutputTensor(0).shape());这一步很多人跳过直到真机上识别结果错乱才回头查其实加载时花两分钟看一眼就能定位。getInputTensor(0).shape()返回的是int[]如果看到[1, 224, 224, 3]而代码里传[1, 224, 224, 4]的输入基本就是预处理通道数对不上。3.3 用Java封装PlantRecognizer把预处理和推理收口Android端不直接散着写Interpreter调用我一般封装成一个PlantRecognizer类暴露一个同步方法recognize(Bitmap bitmap)返回带类别名和置信度的结果对象。这样做的好处是CameraX回调里只关心「输入Bitmap、拿输出结果」模型加载、输入MemoryMap、输出TensorBuffer都在内部管理避免MainActivity膨胀。public class PlantRecognizer implements Closeable { private static final int INPUT_SIZE 224; private final Interpreter interpreter; private final float[][] output; public PlantRecognizer(Context context) throws IOException { MappedByteBuffer model loadModelFile(context, model.tflite); interpreter new Interpreter(model); // 输出缓冲区提前分配避免推理时反复new output new float[1][CLASS_COUNT]; } public Recognition recognize(Bitmap bitmap) { Bitmap resized Bitmap.createScaledBitmap(bitmap, INPUT_SIZE, INPUT_SIZE, true); TensorImage inputImage new TensorImage(DataType.FLOAT32); inputImage.load(resized); // 训练时用的归一化方式除以255.0f若训练用了imagenet均值方差必须替换 TensorImage normalized new TensorImage(DataType.FLOAT32); normalized.load(inputImage.getTensorBuffer(), new NormalizeOp(0f, 255f)); interpreter.run(normalized.getTensorBuffer(), output); return postProcess(output[0]); } }NormalizeOp(0f, 255f)是TFLite官方提供的一个小算子把像素从0-255归一化到0-1。注意训练时如果用的是ImageNet均值如[0.485, 0.456, 0.406]和标准差这里不能只除以255需要自定义NormalizeOp的均值方差参数否则识别结果会是另一个分布置信度普遍偏低。这个细节是「模型准但App不准」的高频原因第5章排查清单里还会提到。4. 安卓端实战相机拍照、图像预处理与结果展示4.1 CameraX取帧后先转Bitmap别在分析器里推理CameraX是现在的标准做法ImageAnalysis的analyze回调运行在独立线程比用Camera2手动管理会话省心得多。但常见错误是在analyze()里直接调PlantRecognizer虽然分析线程不是UI线程但处理时间过长会丢帧取景画面卡顿且识别结果滞后。我一般把analyze回调里的工作限定为「转Bitmap 放到单线程队列」推理由专门的后台线程消费。private class PlantAnalyzer implements ImageAnalysis.Analyzer { private final ExecutorService executor Executors.newSingleThreadExecutor(); private final BlockingQueueBitmap queue new LinkedBlockingQueue(2); Override public void analyze(ImageProxy image) { // 只做格式转换不做推理 Bitmap bitmap imageProxyToBitmap(image); image.close(); queue.offer(bitmap); executor.execute(this::consumeQueue); } private void consumeQueue() { // 取最近一帧丢弃中间帧保证UI响应速度 ListBitmap frames new ArrayList(); queue.drainTo(frames); if (frames.isEmpty()) return; Bitmap latest frames.get(frames.size() - 1); Recognition result recognizer.recognize(latest); runOnUiThread(() - showResult(result)); } }为什么用BlockingQueue而不是Executor直接提交分析回调频率在30fps模型推理只能跑15fps左右队列会积压跟进来的帧全是旧数据。这里队列容量设为2drainTo后只取最新一帧相当于做了一个跳帧策略。image.close()必须调用否则CameraX在部分设备上会卡死预览。这套结构其实是在用Java基础里的生产者-消费者模型BlockingQueue和ExecutorService就是两个主力角色。4.2 预处理对齐尺寸、旋转、通道顺序三个变量从相机拿到的是ImageProxy转成Bitmap后直接缩放不够至少还有两个变量要处理旋转和通道顺序。竖屏拍照时ImageInfo.getRotationDegrees()可能是90或270不旋转会让识别模型看到横着的叶子。而Bitmap的ARGB_8888格式转换成TensorImage时内部会按RGB顺序读如果训练时用OpenCV的BGR读取图片这里就要交换通道。private Bitmap imageProxyToBitmap(ImageProxy image) { Image.Plane[] planes image.getPlanes(); ByteBuffer yBuffer planes[0].getBuffer(); ByteBuffer uBuffer planes[1].getBuffer(); ByteBuffer vBuffer planes[2].getBuffer(); // 标准YUV420_888转RGB注意UV分量按4:2:0交错 // 这里复用帧缓冲避免每次new数组触发GC Bitmap bitmap yuvToRgb(yBuffer, uBuffer, vBuffer, image.getWidth(), image.getHeight()); // 旋转必须发生在缩放之前 Matrix matrix new Matrix(); matrix.postRotate(image.getImageInfo().getRotationDegrees()); return Bitmap.createBitmap(bitmap, 0, 0, bitmap.getWidth(), bitmap.getHeight(), matrix, true); }ImageProxy转Bitmap的实现网上有多个版本核心是把YUV420_888的planes按正确偏移组合成像素。大部分实现的问题是内存拷贝太多每帧几百KB30fps下GC压力很大。建议复用同一个Bitmap和ByteArray避免反复分配。旋转更简单用Matrix.postRotate(degrees)一次性完成。如果模型输入是28x28这样的小尺寸先旋转再缩放避免旋转时缩放出模糊格子。4.3 识别结果展示与识别记录的SQLite落库识别结果页至少要展示三块信息病虫害类别名、置信度百分比、建议处理方式。置信度低于0.6时我倾向于把结果标成「未识别/不确定」而不是硬给一个答案。田间照片经常有泥土、手指遮挡、逆光模型在低置信度区间的输出没有参考价值UI上给出「请靠近叶片、避免反光」的提示比硬猜更实用。public class Recognition { public final String label; // 例如 梨黑星病 public final float confidence; // 0.0 - 1.0 public final String suggestion; // 从配置表里映射的处置建议 }历史记录这层容易被漏掉但对农业场景很重要用户三天后再看一棵树需要知道上次识别是什么结果。SQLite表结构固定为id, image_path, label, confidence, created_at五列每次识别完异步插入。注意图片不要存原图存压缩后的thumbnail_240.jpg否则半年使用下来应用体积膨胀很快。插入操作放到ExecutorService里避免识别瞬间数据库写入卡顿UI。提示识别建议不要硬编码在Java代码里放进assets/pest_guide.json农艺师改建议时不用重新发版。App启动时解析一次映射到内存中的MapString, String。5. 性能与排错模型正确却识别不对问题多半在预处理5.1 推理延迟优化的三个层次先给结论如果目标是「打开相机→拍照→2秒内出结果」当前TFLite在千元机上不需要做极致优化也能达到。但要做成连续识别或批量识别分三步考虑。第一层换模型。MobileNetV3-Small或EfficientNet-Lite0在病虫害任务上精度比ResNet50低不了太多延迟却是数量级下降。模型从224x224换成128x128输入延迟降到大约三分之一代价是细粒度病斑比如细菌性斑点的召回率可能下降5%以上需要实测权衡。第二层开GPU delegate。TFLite的GPU delegate在Adreno GPU上通常能快1.5到3倍但部分旧CPU型号初始化可能失败。标准做法是初始化失败时捕获异常回退到CPU。Interpreter.Options options new Interpreter.Options(); try { // 优先尝试GPU加速失败自动回退CPU options.addDelegate(new GpuDelegate()); interpreter new Interpreter(model, options); } catch (Exception e) { Log.w(TFLite, GPU delegate failed, fallback to CPU, e); interpreter new Interpreter(model); }第三层控制输入尺寸和线程数。setNumThreads(4)对量化模型有效对float16模型效果有限。线程数不是越大越好在4核设备上开4线程系统UI线程会被挤占掉帧反而明显。实践中我一般setNumThreads(2)稳定优先。内存抖动也是这层的常见隐患每帧都new Bitmap和new float[1][N]GC会频繁触发。我的做法是识别器内部缓存一个float[1][CLASS_COUNT]输出区识别完拷贝给调用方输入Bitmap复用一个BitmapPool避免每帧都走createBitmap。5.2 识别错误排查清单先查预处理再查模型最诡异的现象是「模型在PC上识别很准到了Android上输出全错」。这个问题95%出在预处理不一致按下面清单排查比重新训练快得多。归一化方式训练用/255.0f代码里NormalizeOp(0,255)一致吗训练用ImageNet均值标准差代码里也要一致。输入尺寸模型导出是224x224预处理resize时用了中心裁剪而不是整体缩放目标对象边缘可能被切掉。旋转竖屏拍照的旋转角度是否应用在ImageProxy转Bitmap之后、送入模型之前。通道顺序训练用OpenCV读取是BGRAndroid读出来是RGB漏了交换通道会识别成颜色错乱置信度通常低于0.7。类别顺序labels.txt的顺序必须与训练时class_indices一致。切换过数据集后老模型配新标签是最高发的错位结果会整体偏移一个类别。我把这份清单直接写在PlantRecognizer的注释里作为维护契约。排查时可以借助一个技巧在电脑上跑一张叶子的jpg把Android端同一张图dump出来两边对比预处理后的数值逐通道对比像素均值。这个对比能快速确认是哪一层出的偏差。5.3 常见异常与参数修正实际运行中会遇到三类典型异常。第一类是IllegalArgumentException: Not a valid TensorBuffer往往发生在模型输入shape是[1, 224, 224, 3]而传入的buffer是[1, 224, 224, 4]检查TensorImage的DataType是否是FLOAT32以及Bitmap是否被系统改成了ARGB_8888之外的类型。第二类是UnsatisfiedLinkError通常是GPU delegate的so库没打包进APK。abiFilters要显式声明arm64-v8a和armeabi-v7a只留arm64-v8a在份额高的新机上没问题老机器会闪退。第三类是识别结果总是同一个类别这是模型没被正确加载的迹象常见原因是assets里模型文件损坏APK包里文件大小为0。打包后用aapt list或在App里打印file.length()对比。提示正式发布前用同一张图片分别在PC和真机上跑一次把Top3的置信度对比做成表格记录在项目文档里这是排查「环境差异导致结果不同」最快的资料。6. 源码工程里值得落地的三个验证技巧识别的正确性验证比功能开发更容易被忽略。代码写完了、能出结果不等于「识别是对的」。我在源码工程里固定保留三个验证入口固定图片回归测试、adb命令本地验证、弱网/离线场景模拟。首先在core模块里放一个assets/test_leaf.jpg每次改动预处理或模型后跑一个单元测试加载这张图、执行recognize、断言Top1类别和置信度与基线值一致。这样任何改动引发回归时./gradlew test立刻暴露问题。断言阈值不要用精确值用confidence 0.7这类容差判断因为不同设备的浮点差异会导致小数点后几位不同。# 在真机上用adb向应用推送测试图片模拟拍照识别 adb push test_leaf.jpg /sdcard/Download/ adb shell am start -n com.example.plantdiagnosis/.MainActivity \ --es test_image /sdcard/Download/test_leaf.jpgMainActivity里接收--es test_image参数若传入则跳过相机流程直接读取图片走识别结果同时打到Logcat。这一步能让测试人员不开相机用固定图片回归也能在自动化测试框架里复用。其次是弱网离线场景识别本身在本地完成但历史记录上传或识别建议在线更新需要网络。源码里做一个ConnectivityLiveData封装当检测到无网络时自动把结果页的在线参考链接换成本地pest_guide.json的内容避免用户看得到结果却看不到处置建议。这里有个细节pest_guide.json要按作物分目录比如guide/梨/黑星病.json否则多作物场景下文件会越滚越大。最后是耗电与发热自检用dumpsys batterystats跑一轮识别后观察CPU和传感器占用若CPU持续超过30%优先检查是不是没有复用Bitmap、或者相机在识别期间没有关闭分析线程。把这三个验证入口留在源码工程里交付后出问题时的定位时间能缩短一大半。本文还有配套的精品资源点击获取