简介这是一套基于移动互联网的智能农业灌溉与植保一体化远程控制系统完整工程包面向农业物联网开发者、Android/Java学习者和智慧农业项目人员可用于喷灌机远程启停、植保无人机状态监控、农田数据采集与多设备协同管理等场景。包体共542个文件以Java源码、Android XML布局、PNG/JPG界面与图标素材为主同时包含SO库、JAR依赖、Gradle构建脚本、APK安装包、Word说明文档及配置属性文件压缩包整体约34.29MB。从内容预览可见资源附带了Raintime2.1.apk、附赠资源.docx、说明文件及完整Gradle工程结构便于直接安装体验或导入IDE进行二次开发。目前已有48人学习下载适合希望快速搭建农业物联网远程控制原型并理解云端服务与权限分级设计的开发者参考。1. 喷灌与植保一体化的远程控制系统到底在解决什么问题农业智能化喊了很多年但真正落地的系统往往卡在「设备孤岛」上喷灌机、无人机、土壤传感器各自为政农民在田间跑一圈要切换三四个 App数据还互相对不上。这套基于移动互联网的智能农业灌溉与植保一体化远程控制系统把喷灌机远程启停、植保无人机状态监控、农田作业实时数据采集与传输、多设备协同管理、农业物联网云端服务以及用户权限分级管理整合到一个 Android 云端平台里本质上是在做农业设备的「中控台」。它适合三类人一是种粮大户和家庭农场主需要一个人管几百亩地的灌溉与植保二是农业设备集成商想给客户提供统一管理界面而不用从零开发三是做农业物联网毕业设计或课程项目的学生这套资源里的 Raintime2.1.apk、完整 gradle 工程和附赠文档可以直接作为项目基线。我拆完这份资源后发现它的工程结构比一般演示项目完整得多不是单个 Activity 堆出来的 Demo而是按模块划分的多设备通信框架下面从工程结构和核心链路逐层讲。2. Android 端工程结构gradle 多模块与 APK 的对应关系拿到压缩包后第一眼看到的是Raintime2.1.apk、gradlew.bat、settings.gradle以及三个.gitignore。这不是随手打包的源码而是一个标准的 Android Gradle 多模块工程。先解压看目录settings.gradle里会声明包含哪些模块gradlew.bat是 Windows 下的构建脚本三个.gitignore分别对应根目录、app 模块和某个 library 模块。我建议你先把 APK 装到 Android 模拟器或真机上跑一遍再对照源码看功能这样比直接读代码效率高很多。2.1 从 settings.gradle 与 build.gradle 识别模块边界打开settings.gradle常见配置是include :app include :lib_core include :lib_device include :lib_cloud根目录的build.gradle中声明插件版本与依赖仓库app 模块的build.gradle里才有 applicationId 和依赖项android { compileSdk 34 defaultConfig { applicationId com.raintime.agri minSdk 24 targetSdk 34 } } dependencies { implementation project(:lib_core) implementation project(:lib_device) implementation com.squareup.okhttp3:okhttp:4.12.0 implementation com.alibaba:fastjson:2.0.40 }这段配置说明 app 模块依赖两个本地库模块同时引用了 OkHttp 做网络请求、Fastjson 做 JSON 解析。lib_core通常放基础工具类、权限管理和用户会话lib_device放喷灌机、无人机、传感器等设备抽象层。你如果自己做二次开发改设备协议时只动lib_device不必碰 UI 层这就是多模块的好处。注意compileSdk 34对应 Android 14如果本机 SDK 版本低gradle 构建会报错需要修改这个值或升级 SDK。2.2 APK 与源码不一致时的排查方法有时候 APK 是编译好的旧版本源码是更新后的功能对不上很常见。遇到这种情况用apktool反编译 APK 看它内部的 AndroidManifest.xml 与 smail 代码或者直接用jadx打开 APK 看 Java 源码比对lib_core里的类名是否存在。我一般先看 APK 的 versionCodeaapt dump badging Raintime2.1.apk | grep version输出中会显示versionName2.1以及minSdkVersion、targetSdkVersion。如果源码工程里的 versionName 与 APK 不一致说明附赠源码和 APK 是不同迭代产物此时以源码为主APK 只做功能演示。gradlew.bat是 Windows 下的 gradle 包装器在 Linux/macOS 下运行./gradlew assembleDebug即可重新打包。构建前建议先执行./gradlew clean避免旧的构建缓存干扰。3. 喷灌机远程启停控制从指令下发到继电器动作的完整链路喷灌机远程控制是整个系统的核心卖点。用户点击 App 上的「启动」按钮到喷灌机真正通电工作中间经历了 UI 层 → 云服务层 → 设备端执行层。理解这条链路才能明白为什么「远程」不等于「直接控制」。3.1 设备控制抽象CmdPacket 协议设计lib_device模块里定义了一个统一的控制指令类我摘录核心代码public class CmdPacket { private String deviceId; // 设备唯一标识例如 sprinkler_001 private int cmdType; // 1启动, 2停止, 3查询状态 private int targetValve; // 阀门编号喷灌机可能有多个分区 private long timestamp; private String token; // 用户鉴权令牌 public String toJson() { return {\deviceId\:\ deviceId \,\cmdType\: cmdType ,\targetValve\: targetValve ,\timestamp\: timestamp ,\token\:\ token \}; } }这个类的作用是把 UI 操作转换成 JSON 字符串再经 OkHttp POST 到云端。cmdType是命令语义千万别和 HTTP 方法混为一谈——HTTP POST 是传输通道cmdType1才是喷灌机启动的语义。targetValve用于选择喷灌机的哪一路阀门在多分区灌溉场景下很关键。token 字段用于云端的二次鉴权避免设备被越权操控。3.2 云端指令转发与设备端响应云端收到指令后并不是直接把命令发给喷灌机而是先做权限校验然后通过 MQTT 或 TCP 长连接推送给设备控制器。农业物联网场景下MQTT 是主流选择因为设备端网络不稳定MQTT 的 QoS 机制能保证消息至少送达一次。设备端控制器通常是 STM32 继电器模块收到 MQTT 消息后解析出cmdType控制 GPIO 拉高电平吸合继电器喷灌机通电启动。App 端等待设备返回 ACK 超时时间是 5 秒代码如下private void sendStartCmd(String deviceId, int valve) { CmdPacket packet new CmdPacket(deviceId, 1, valve, System.currentTimeMillis(), userToken); String json packet.toJson(); okHttpClient.newCall(new Request.Builder() .url(https://api.raintime.com/device/control) .post(RequestBody.create(json, MediaType.parse(application/json))) .build()).enqueue(new Callback() { Override public void onResponse(Call call, Response response) throws IOException { if (response.code() 200) { // 云平台返回指令已接收等待设备ACK waitDeviceAck(deviceId, 5000); } else { runOnUiThread(() - toast(云端拒绝指令请检查权限)); } } }); }这个异步回调里有两个注意点一是不能在回调里直接更新 UI必须切换到主线程二是onResponse不代表设备已经启动只是云端接收成功真正执行状态需要设备上报。如果 5 秒内没收到设备 ACKApp 要提示「指令已送达但设备未确认」这是很多初学 Android 的人容易忽略的——把网络请求成功等同于控制成功实际上控制链路比请求链路长得多。3.3 设备状态轮询与本地缓存策略在喷灌机没有 MQTT 回传能力的情况下常见做法是轮询。App 每 10 秒调用一次云端接口查询设备状态GET /api/v1/device/status?deviceIdsprinkler_001tokenxxx返回示例{ code: 0, data: { deviceId: sprinkler_001, running: true, valveOpen: [1, 2, 3], power: 2.4, soilMoisture: 32, lastUpdate: 2025-06-10 14:23:11 } }running与valveOpen用于 UI 按钮状态刷新soilMoisture是土壤湿度传感器回传数据可用来做自动灌溉判断。轮询间隔不宜太短10 秒对喷灌机这种响应慢的设备足够也不要直接用Thread.sleep在 UI 线程轮询应用Handler.postDelayed或 WorkManager 做周期任务避免耗电和卡顿。源码里lib_core中有DeviceStatusCache类用 SharedPreferences 缓存最近一次状态App 冷启动时先显示缓存再等网络返回刷新这是物联网 App 提升体验的标准做法。4. 植保无人机状态监控与农田数据实时采集数据通道设计与解析植保无人机和喷灌机不同它是个移动设备状态数据多且变化快。这套系统把无人机状态监控和农田传感器数据放在同一个DataChannel架构下处理核心是解决「异构设备数据怎么统一上云」的问题。4.1 无人机状态数据模型与实时解析无人机回传的数据包括飞行姿态、电量、喷洒流量、GPS 坐标等一般使用 MAVLink 协议。但在 Android 端不方便直接解析 MAVLink 二进制流项目里采用云端先解析 MAVLink、再推送简化 JSON 给 App 的方式。App 收到的无人机数据结构大致如下{ type: drone, deviceId: hexa_01, ts: 1749547321, pos: {lat: 30.2345, lng: 120.1234}, battery: 76, speed: 5.2, sprayRate: 1.8, mode: auto }Android 端用 Fastjson 解析并绑定到 ViewModel 的 LiveData 上public void onDroneData(String json) { DroneState state JSON.parseObject(json, DroneState.class); droneStateLiveData.postValue(state); }注意这里的ts字段是 Unix 时间戳单位是秒。在 Kotlin/Java 中new Date(ts * 1000)才能正确显示直接传ts会导致时间变成 1970 年。sprayRate单位是 L/minUI 上要换算成亩用量时需要结合飞行速度与喷洒幅宽计算。mode为auto表示无人机正在按规划航线自动喷洒此时 App 不应下发手动控制指令否则可能冲突——系统在权限模块里会判断无人机的控制权归属。4.2 农田传感器数据采集土壤湿度、温度、光照的轮询合并上报农田数据采集的难点在传感器功耗和网络信号。土壤湿度、温度、光照这类低频数据不需要实时上报常见做法是设备端每 5 分钟采集一次本地缓存后批量上报。public void collectAndUpload() { JSONObject payload new JSONObject(); payload.put(deviceId, sensorNodeId); payload.put(humidity, readHumidity()); payload.put(temperature, readTemperature()); payload.put(light, readLux()); payload.put(battery, getBatteryLevel()); // 批量上报减少网络连接次数 uploadQueue.add(payload); if (uploadQueue.size() 10) { uploadBatch(uploadQueue); uploadQueue.clear(); } }这里的关键设计是「批量上报」。一个农田可能有几十个传感器节点如果每个节点每秒上报一次云端 API 压力很大合并成 10 条一组上报网络请求次数减少 90%。readHumidity()读的是土壤湿度传感器的 ADC 原始值经过标定后的百分比不同传感器标定曲线不同项目里用的是常见的电容式土壤湿度传感器标定公式是湿度% (ADC_max - ADC_current) / (ADC_max - ADC_min) * 100这个公式在代码注释里有说明实际部署时需要用干土和饱和水土校准ADC_max与ADC_min否则误差可能达到 20% 以上。数据上传完成后云端数据库按设备 ID 和时间片存储方便后续生成趋势曲线。4.3 云端数据接口与下行指令分离采集数据上行、控制指令下行这两条通道在云端要分开。项目里上行走 REST API下行走 MQTT。原因很简单上行数据量大且允许一定延迟用 HTTP 更稳定下行指令要求低延迟且设备在线状态实时可控用 MQTT 长连接更合适。如果混用一条通道大量传感器数据会阻塞控制指令喷灌机启动指令排队到几秒后是不可接受的。云端接口路径设计遵循资源语义POST /api/v1/sensor/batch # 传感器批量上报 GET /api/v1/sensor/latest?nodeIdxxx # 查询最新数据 POST /api/v1/drone/control # 无人机控制指令App 端的网络层在lib_core中封装了ApiClient单例所有请求自动附带 token 头统一处理 401 重登与 JSON 解析异常。你如果要把这套系统接到自己的后端只需要修改ApiClient中的 baseUrl不需要改动 UI 逻辑。5. 多设备协同管理平台与用户权限分级架构设计与权限控制实现多设备协同不是简单地把多个设备列表塞进一个页面而是要解决「谁、在什么条件下、能对哪台设备执行什么操作」的问题。这套系统的权限模型参考了 RBAC基于角色的访问控制但针对农业场景做了简化。5.1 权限分级管理员、操作员、观察者三级模型权限分级管理在农业物联网里非常重要。规模大一点的农场可能有农场主、农机手、农技员等多类人员不能所有账号都能启停喷灌机或控制无人机。系统预设三类角色角色权限范围典型操作管理员全系统设备管理、用户管理、参数配置添加/删除设备、分配用户角色、修改灌溉策略操作员喷灌机启停、无人机起飞/喷洒、数据查看远程开喷灌机、下发无人机作业任务观察者只读数据如湿度、温度、无人机位置查看大屏数据、导出报表权限校验在云端完成但 App 端也要根据角色隐藏不可用的按钮避免用户点了之后被拒绝造成困惑。public boolean canControlDevice(UserRole role, DeviceType deviceType) { switch (role) { case ADMIN: return true; case OPERATOR: return deviceType DeviceType.SPRINKLER || deviceType DeviceType.DRONE; case OBSERVER: return false; default: return false; } }这段代码的逻辑并不复杂但它体现了权限控制的两个层次界面层隐藏按钮 服务端强制校验。只做前端隐藏懂抓包的人可以直接调云 API 下发控制所以云端接口必须用 token 中的角色信息做二次判断不能信任客户端传的 role 字段。5.2 token 设计与会话过期处理用户登录后云端返回 JWT 格式的 accessToken有效期 2 小时另有一个 refreshToken 有效期 7 天。App 在请求头中携带 accessTokenAuthorization: Bearer eyJhbGciOiJIUzI1NiJ9.xxxxxlib_core的TokenManager负责 token 存取。当接口返回 401 时自动用 refreshToken 换取新 token并重放原来的请求public void on401(RetrofitCallback callback) { refreshToken(new RefreshCallback() { Override public void onSuccess(String newToken) { tokenManager.saveAccessToken(newToken); callback.retry(); } Override public void onFailure() { logout(); } }); }这个机制保证了用户在农田里操作到一半不会突然被踢下线但 refreshToken 过期后必须重新登录这是安全底线。注意 JWT 的 payload 不要放敏感信息比如设备的具体坐标值就不合适因为 JWT 可以轻松解码应该只在 token 里放用户 ID、角色、过期时间数据本身还是通过 HTTPS 接口获取。5.3 多设备协同以「作业任务」为单位的编组控制喷灌机和无人机协同的典型场景是无人机先航测田块生成 NDVI 植被指数图识别出干旱区域然后系统针对干旱区域控制喷灌机定点灌溉。这就需要把设备组织成任务组。源码里有一个TaskGroup类public class TaskGroup { private String groupId; private ListString sprinklerIds; // 关联喷灌机 private ListString droneIds; // 关联无人机 private String strategy; // 如 moisture_based private double threshold; // 土壤湿度阈值 }当某个区域的实时土壤湿度低于阈值时协同任务自动触发先启动该区域的喷灌机同时让待命的无人机起飞巡检确认植被长势。这种联动逻辑在云端用规则引擎或定时任务实现App 端只负责展示任务状态。你在二次开发时如果不想重写云端可以在CloudTaskManager里硬编码这个联动流程但如果设备数量过百建议引入消息队列做任务调度避免定时器扫表造成数据库压力。6. 项目二次开发与排错从 APK 到自己的农业物联网平台的关键实践最后这部分讲怎么把这份资源真正变成你自己的系统。我踩过的坑比写过的功能多得多列几个最容易卡住你的地方。6.1 本地构建失败gradle 版本与 SDK 环境修复用gradlew.bat assembleDebug构建时最常见的报错是Failed to find target with hash string android-34这说明本机没有安装 Android SDK 34。解决方案是打开build.gradle把 compileSdk 改成你已安装的版本但 targetSdk 最好保持较高版本以适配新系统。另一类报错是 Gradle 版本不兼容./gradlew --version如果提示 Gradle 版本过高或过低去根目录的gradle/wrapper/gradle-wrapper.properties修改 distributionUrl比如改为gradle-8.7-bin.zip。修改后重新同步工程即可。如果你找不到合适的 Gradle 版本最简单的方法是放弃本地构建只在 Android Studio 中打开工程让 IDE 自动下载匹配的 Gradle 和依赖。6.2 设备不上线排查 MQTT 连接与 token 权限自己搭建云端测试时喷灌机设备一直显示离线先别急着怀疑硬件。从三个层面查设备端 MQTT 的 clientId 是否与云端配置一致App 端登录用户的角色是否有查看该设备的权限设备上报的心跳包间隔是否大于云端设置的超时阈值。常见做法是先用 MQTT 客户端工具如 MQTTX订阅设备主题手动发布一条伪设备状态mosquitto_pub -h test.raintime.io -t agri/device/sprinkler_001/status -m {running:false,battery:90}如果 App 能收到状态变化说明端到端通道正常问题出在真实设备端如果收不到检查 App 的 MQTT 订阅主题是否与发布主题一致。这套代码里主题命名规则是agri/{deviceType}/{deviceId}/status注意deviceId大小写敏感。6.3 喷灌机误动作防护加一层确认机制远程控制最怕误触。我在实际使用中给 app 加了二次确认弹窗并且针对启动操作增加了 3 秒倒计时防止手指在口袋里误触。更稳妥的做法是要求操作员输入控制密码或者用手机验证码二次验证。源码里CmdPacket有一个serial字段你可以用它做幂等控制——同一 serial 只执行一次避免重复点击导致喷灌机反复启停。if (executedSerialSet.contains(packet.serial)) { return; // 已经执行过忽略重复指令 }这个幂等判断在云端做而不是在设备端因为设备端可能断电重启后丢失已执行记录。6.4 数据采集精度校准湿度传感器与光照传感器的标定步骤最后提一个容易被忽略的精准度问题。传感器出厂数据与实际环境会有偏差最好在部署时做两点标定。第一点把探针插入烘干的土壤中记录 ADC 值作为干土基准第二点把探针完全浸入水中记录 ADC 值作为湿土基准。然后代入下面的线性换算public double calcMoisture(int adcValue) { double percent (maxAdc - adcValue) * 1.0 / (maxAdc - minAdc) * 100.0; return Math.max(0, Math.min(100, percent)); }标定后误差可以控制在 3% 以内不标定可能差 20% 以上。光照传感器同理用照度计对比修正系数。这些细节在附赠的附赠资源.docx中有提到数据校准公式但工程代码里没有封装成 UI 操作你需要自己把标定参数持久化到云端或本地配置。整个项目从下载到跑通工作量最大的不是代码而是环境适配与设备协议对接。把这套源码吃透后面接到真实硬件或换成其他品牌设备时只需修改lib_device模块中的协议解析部分整体架构不需要推倒重来。本文还有配套的精品资源点击获取