★ FEATURED ARTICLE 做了这么久的HarmonyOS智慧农业应用系列前面十几篇基本都在跟传感器数据、告警逻辑、生长环境模型较劲。到了第18篇我想换个切入点聊聊一个让很多人又爱又恨的功能——图像识别具体说就是病虫害诊断。这篇开始我没打算直接贴代码而是先把一个很多人没想明白的问题理清楚病虫害诊断为什么值得作为智慧农业应用里第一个图像识别模块来做以及HarmonyOS端究竟怎么落地才算靠谱。你可能会说病虫害识别不就是拍照传云端、返回个标签嘛。真没那么简单。农业场景的特殊性在于拍摄环境不可控、病害形态复杂、样本分布不均很多时候模型给你一个“稻瘟病置信度0.72”你反而不知道怎么处理。这篇教程会带你把“拍照-预处理-推理-结果校验-人机交互”整条链路走完同时把模型选择、数据来源、阈值设计和纠错机制一次性讲透。无论你是做毕设、打比赛还是给某个农业基地做真实预研这部分内容都能拿来直接用。1. 田间地头的诊断痛点这个功能为什么值得第一个做1.1 植物医生不够用农户的“看错病”成本太高我在跟几个种植基地交流时发现一个共性现状真正懂植保的人不可能天天蹲在每一块地里。一个农技员往往要负责几百上千亩的作物巡检等农户发现异常再拍照送检中间最快也要一两天。而像稻瘟病、霜霉病这类传染性病害两三天足以从零星病斑扩散成一片。更麻烦的是农户自己诊断容易误判。叶子上出现黄斑可能是缺氮可能是锈病早期也可能是药害。几种情况对应的处置方式完全不同一旦用错药轻则没效果重则烧苗。传统做法是靠经验但经验需要积累新农人恰恰最缺这个。1.2 图像识别能替农户和农技员分别省下什么如果把病虫害诊断拆成“发现异常、判断类型、给出处置建议”三个环节图像识别在第二个环节能发挥的作用最明显。发现异常可以靠传感器和人工巡检但“判断类型”恰恰是基层最缺的能力。HarmonyOS端侧推理的好处是手机一拍模型本地就能给出分类结果不依赖田间信号隐私性也好。从农技员的角度看这个功能相当于一个“预筛器”。农户自己拍完先识别一轮带着结果和原始照片去找农技员复核沟通效率会高很多。农技员不用再远程问“什么颜色、多大面积、在哪个部位”直接把图像识别结果作为参考省掉大量描述成本。所以我的结论是病虫害诊断不是智慧农业的锦上添花而是真正能落到田间、被用户高频打开的功能入口。这也是我建议所有做农业App的团队一旦有余力优先把图像识别模块提上日程的原因。2. 三条识别路线之争端侧模型、云推理还是混合方案2.1 先摸清三条路线的真实边界做技术选型前我画了一张对比表把HarmonyOS端做图像识别的三条主流路线放在一起看方案推理位置离线可用精度天花板实施难度单次成本典型场景ML Kit自带分类模型端侧支持较低通用类别低无绿叶/枯叶等粗粒度区分自定义模型端侧推理端侧支持高取决于训练数据中高无特定作物的病虫害细分类图像上传云推理云端不支持高可反复迭代中GPU/带宽需要海量类别和持续更新第一眼看大家可能觉得自定义端侧模型精度又高又离线肯定最优。但实际开发中不是这么回事。端侧模型要考虑内存占用、推理耗时、模型体积这些约束直接决定你能跑多大的网络。2.2 云端推理的隐藏成本上传一张图要等多久有段时间我倾向云端推理觉得精度高、好迭代。真跑到大棚实测才发现农业网络的稳定性远不如城市。大棚的钢结构会遮挡信号偏远地块经常只有4G一格信号一张2MB的叶片照片上传顺利的话要十几秒碰上弱网直接转圈圈。更关键的是农户的耐心极其有限。他在地里顶着大太阳举起手机拍完等30秒还没结果大概率直接放弃。所以纯云端方案在农业生产环境里体验很难做好。2.3 我的选型结论端侧为主、云侧兜底最终的方案定为端侧自定义模型做主诊断云侧留一个可选的复核接口。常态情况下本地模型在几百毫秒内输出结果满足田间使用的实时性要求遇到置信度极低或者用户主动选择的“疑难杂症”再提示上传云端做二次判断。这个混合方案的实现成本确实比单端或单云高但从产品路径看是值得的先用端侧模型保证基础体验等积累了足够的真实图片反馈再逐步优化云端模型反哺端侧。HarmonyOS的ML Kit恰好同时支持端侧推理接口和网络请求能力一套代码可以串起双链路。3. “一拍即诊”全链路实现相机、预处理、推理与展示3.1 底层开发框架与页面结构准备进入代码之前先交代开发环境。我这里用的是一个典型的HarmonyOS应用工程界面部分基于ArkTS声明式开发框架页面组件用ArkUI来写。你如果是从零开始先创建一个Empty Ability工程然后在module.json5里申请相机权限和读写权限{ module: { requestPermissions: [ { name: ohos.permission.CAMERA, reason: 用于拍摄作物叶片进行病虫害识别 }, { name: ohos.permission.READ_MEDIA, reason: 用于从相册选择已有作物照片 } ] } }这里有个权限设计的细节要提醒你农业App的用户群体年龄偏大对隐私授权很敏感。申请权限时的说明文案一定要直白不要写“用于提升服务质量”这种空话写清楚“用于拍摄叶片判断病虫害”通过率会明显提升。页面结构上我建议把识别功能拆成三个Region顶部是预览区中间是识别结果卡片底部是操作按钮区。不要一上来就堆功能农户使用场景往往是单手操作按钮要做大、结果要醒目。3.2 相机拍摄与相册选择双入口设计图像识别第一步是拿图。我在页面里放了两个入口一个调用系统相机直接拍一个从相册选择。干活的时候农户更习惯直接拍但有些特殊情况——比如想对比昨天的病斑变化——相册入口就很有用。调用系统相机在HarmonyOS端并不复杂用的是系统提供的CameraPicker能力。示例代码如下import { cameraPicker } from kit.CameraKit; async function takePhoto() { const pickerProfile: cameraPicker.PickerProfile { cameraPosition: cameraPicker.CameraPosition.CAMERA_POSITION_BACK }; const result await cameraPicker.pick(this.getContext(), [pickerProfile]); if (result.resultCode 0) { // 拿到图片的URI交给预处理模块 this.processImage(result.uri); } }相册选择则用PhotoViewPicker代码结构类似。这里有一个关键点拿到的URI不能直接当文件路径用要先通过文件管理接口打开或者拷贝到应用沙箱目录。很多新手在这个环节被卡住报错“No such file”其实就是因为没做权限上下文切换。3.3 图片预处理不做好这一步模型精度直接打七折很多人以为模型训练好了就万事大吉真正跑起来才发现田间照片跟训练集图片差距太大。我总结出预处理环节四个必须处理的点第一压缩。原相机照片动辄几MB直接送进模型推理内存和耗时都爆炸。我会统一压缩到短边不超过1024像素质量参数压到85。对病害识别来说叶片的纹理细节基本保留得住。第二旋转校正。手机拍摄时经常竖着拍但模型训练样本多为横图EXIF信息里的旋转角度如果不处理模型看到的就是一张“躺倒”的叶子识别效果自然差。用HarmonyOS的图像接口读取Orientation属性并校正即可。第三光照归一化。大棚里光线复杂有自然光、补光灯、甚至反光膜反射的紫光。最简单的做法是转成RGB后做一次均值归一化把像素值缩放到[0,1]区间这能显著降低不同光照条件下的误判率。第四ROI裁切。病斑往往只占叶片的一小部分整张叶片图送进模型背景干扰太大。我会在页面上给用户提供一个可拖动的选框让用户把病斑区域框出来只裁切这个区域去推理。别小看这个交互设计它比任何算法都管用。3.4 ML Kit模型加载与推理调用HarmonyOS的ML Kit对自定义模型推理支持得比较完善加载模型后调用预测接口即可。我的核心代码如下import { mlKit } from kit.AIKit; // 从模型管理目录加载转换后的模型 const model await mlKit.loadModel( this.getContext(), entry/resources/base/media/pest_model.mindir ); // 构造推理输入 const inputTensor mlKit.createTensor( [1, 224, 224, 3], mlKit.DataType.FLOAT32 ); inputTensor.setData(preprocessedImageData); // 执行推理 const output await model.predict(inputTensor); const scores output.getData(); // scores是一组概率值对应训练时的类别顺序这里的模型文件后缀取决于你用的转换工具链。我后面第4节会细讲怎么把训练好的模型转成HarmonyOS端能加载的格式。推理输出的scores数组你需要在训练时记住类别索引顺序比如0代表健康、1代表稻瘟病、2代表稻曲病不能搞乱。3.5 结果展示置信度、处置建议与历史记录推理结果不能只弹一个“稻瘟病”标签。农户真正需要的是“这是什么病、严不严重、怎么办”。我做了三级展示第一级诊断结果卡片。展示病害名称和置信度置信度用进度条可视化。同时用颜色区分风险等级绿色代表健康或低风险黄色代表疑似红色代表高风险。第二级处置建议。这是静态知识库匹配的结果根据病害种类给出用药时机、用药量、物理防治建议。内容要接地气我会写“翻田晒土”而不是“改善土壤理化性质”。第三级历史记录。每次识别自动保存原图、结果、时间、地块编号。这对后续追踪病情扩散趋势很有价值。HarmonyOS端可以用轻量级数据库来存不需要上云。4. 模型是怎么来的从数据、标注到训练部署全链路4.1 病害数据从哪找公开数据集与田间自采的组合拳端侧模型训练的成败七成取决于数据。病虫害识别领域有几个公开数据集涵盖水稻、玉米、小麦等主要作物的常见病害图片数量从几千到几万不等。这些数据集的好处是类别标准直接可用坏处是拍摄环境太干净跟真实田间差距大。所以我的经验是“公开数据集打底田间自采补短板”。团队去合作的基地用手机拍了几千张真实病斑照片。你会发现这些照片里有泥点、有虫影、有套袋反光甚至还有农户的手指头。这些“脏”数据看起来不美观但对模型泛化能力至关重要。4.2 数据清洗与标注的坑类别不平衡是最大的敌人真实数据拿回来第一件事不是训练而是清洗。我踩过的坑是肉眼看着像“稻瘟病”的照片放大后发现是稻飞虱排泄物引起的煤污病。这种错误标签如果不去掉模型学到的是“黑色斑点稻瘟病”整个识别逻辑就歪了。清洗完就要标注。推荐的标注工具新手也能快速上手支持画框和分类标签。这里有个原则必须坚持每个类别的样本量尽量均衡至少要保证最少的类别有500张以上。如果你的多数类有5000张、少数类只有200张训练时少数类几乎学不出有效特征。实在凑不够就用数据增强——随机旋转、翻转、亮度变化、加噪声这些操作能有效扩充样本量。4.3 训练与转换从PyTorch到HarmonyOS端侧可运行格式模型训练部分我用的主流的CNN轻量网络参数量小适合手机端。训练框架不限制PyTorch或者MindSpore都行关键在最后一步转成HarmonyOS端可加载的格式。转换流程是这样的先把训练好的模型导出再做量化压缩转成端侧推理框架支持的格式。量化这一步特别重要把32位浮点压成8位整数模型体积能缩小到原来的四分之一推理速度提升明显。代价是精度略降一般降1-2个百分点农业场景完全能接受。转换完成后务必在HarmonyOS模拟器上先验证一遍输出是否和训练时一致。我遇到过转换后个别层的计算精度异常输出结果变成乱码的情况。建议准备10张典型图片分别跑训练框架和端侧推理对比输出张量的差异值差异超过阈值就要回头检查转换参数。5. 别让App“拍脑袋说话”识别结果的置信度、阈值与纠错机制5.1 置信度不是越高越好阈值动态调节策略模型输出的置信度很多人直接拿来用超过0.9才显示结果。但实际使用中我发现固定阈值有问题。不同作物、不同病害的训练难度不一样有些病特征明显模型输出0.95很轻松有些病早期症状模糊模型可能只给0.6。如果统一按0.8卡模糊但仍有价值的识别全被拦掉用户体验就是“拍十次八次没结果”。我最后用了动态阈值按病害类别分别设定阈值特征明确的类别阈值卡高一点特征模糊的类别卡低一点。实现上就是维护一张阈值配置表随训练迭代持续调整。5.2 多标签与“其他”类的处理思路真实的田间场景一片叶子可能是两种病害混合发生。单纯的多分类模型只能输出一个结果这时候就需要引入多标签策略把模型输出层改成多个sigmoid而非softmax每个病害类别独立判断是或否。同时我强烈建议在训练类别里加一个“其他”类。这个类收集那些不属于任何已知病害、但也不健康的图片比如机械损伤、药害、晒伤。没有这个类模型会硬把所有输入归到已知类别里出现“水渍也说成霜霉病”的离谱结果。有了“其他”类模型至少知道说“我没见过这种”把判断权交还给用户。5.3 图片“体检”识别之前先检查图能不能用很多时候识别不准不是模型的锅是图片本身不行。我总结了一份图片质量体检清单清晰度检测用Laplacian算子算一下图像方差值过低说明图片模糊直接提示用户重拍过曝欠曝检测计算图像平均亮度超出范围提示调整光线面积占比检测绿色叶片像素占整张图的比例过低说明背景太多提示用户拉近拍摄叶片完整性检测如果发现照片里叶片边缘大面积缺损说明拍的是碎片识别意义有限这四道体检全部在端侧完成每个检查耗时不超过20毫秒对用户体验几乎没有影响。但带来的收益非常明显——从源头过滤掉一批低质量图片模型推理的准确率能提升好几个百分点。5.4 用户纠错闭环让人工反馈反哺模型迭代识别结果出来以后我会在结果卡片下方放两个按钮一个“结果正确”一个“结果不对”。用户点“结果不对”的时候弹一个小表单让他选择“实际是什么情况”至少也要填个“不知道”。这些反馈数据打上标签后可以定期回流到训练集里。这是整个闭环里最有价值的一环。很多团队训练完模型就扔了殊不知真实使用数据才是模型持续变强的燃料。HarmonyOS端可以先把反馈图片存到本地等网络空闲时再打包上传不影响正常使用。6. 从Demo到下田实测中的意外情况与调整细节6.1 阳光直射下的屏幕能见度问题第一次田间实测我遇到了一个意想不到的状况正午强光下手机屏幕反光严重用户根本看不清拍摄预览也看不清识别结果卡片上的字。解决方案分两层。第一层App内做一个“强光模式”开关用户打开后界面整体变成黑底白字对比度拉高第二层识别结果除了文字显示增加语音播报功能朗读病害名称和处置建议。这两个改动很小但对田间可用性的提升是质的飞跃。6.2 网络离线时的降级策略我们规划的端侧模型能覆盖大部分情况但屏幕上还是出现了“网络连接失败”的报错。排查了很久发现问题出在云端复核接口的调用逻辑上不管置信度高不高App都会先请求云端客户端拿到网络异常就整体报错。修复方案是调整链路顺序端侧推理先行如果置信度超过阈值直接展示结果根本不去请求云端只有置信度低于阈值才发起云端复核。同时给云端请求加超时控制超时后直接提示“当前为离线识别结果仅供参考”。这样一来网络问题不再阻塞核心功能。6.3 模型热更新不重新发版也能升级识别能力农业病害种类随着季节和地域变化很大。5月份你训练的模型识别得了小麦锈病到了8月份可能新出现一种你根本没纳入类别的病害。我建议早做规划模型文件走动态下发HarmonyOS端启动时检查服务端模型版本号有新版本就下载替换。这个机制用几行代码就能实现但能避免“每加一个病害类别就要发一次版”的窘境。模型文件不大几兆到十几兆夜间WiFi环境下自动更新完全不打扰用户。6.4 识别边界要写进产品说明最后说一个容易被忽视的点任何AI识别工具都必须明确自己的边界。我在App的“关于诊断”页面明确写了三条限制诊断结果仅供参考不能替代专业植保人员的判断对相似病害容易混淆如遇争议请联系当地农技站用药建议需要结合当地用药规范避免超量使用。这不是免责条款而是对用户负责。农业领域用错药的后果比互联网领域点错一个按钮严重得多。把边界讲清楚反而能建立用户信任大家更愿意把App作为辅助工具持续使用。多说一句我的体会病虫害识别这个功能真正跑起来以后你会发现最大的门槛既不是HarmonyOS端的编码也不是模型精度而是有没有一颗敬畏农业现场的心。端侧推理、模型压缩、阈值设计这些技术手段最终的目标只有一个——让手机成为农户口袋里那个随叫随到的“植保小助手”。后面我会继续更新这个系列下一篇打算聊聊智慧农业里另一个高频场景成熟度判断与采收建议敬请关注。
阅读完成 · 觉得有帮助？
