巡检系统开发

项目背景

这是一套现场巡检与巡查方向的 Android 应用，共 2 个仓库，覆盖 2021 年 1 月至 3 月，Java 为主要实现语言。两个仓库的体积分别为 130MB+ 与 96MB+，提交数分别为 23 次与 12 次，属于该阶段提交较密集的项目。应用功能围绕巡检任务下发、拍照与点位打卡、离线暂存与回传，以及巡检报告的生成与归档。

客户当时的状态

巡检类应用有一个容易被低估的前提：现场网络不稳定。很多同类产品是在办公室网络环境下开发验证的，到了现场才发现断网就等于停工。另一个问题是记录的可证明性——巡检的价值在于「什么时候、在哪里、看到什么」，照片如果脱离了位置信息，事后无法说明它对应的是哪个点位，记录就成了没有依据的材料。此外，如果巡检结果散在每个人的手机里，汇总就要靠人工，时间一长数据也就沉没了。巡检任务的类型差别也很大，有的要求逐点拍照，有的只要求确认状态，任务结构必须能容纳这些差别。

我们的做法与取舍

第一个取舍是把离线能力当成设计前提，而不是可选项。数据先在本地暂存，网络恢复后回传。代价是本地存储与状态管理变复杂，收益是应用在现场真正可用。

第二个取舍是照片与点位强绑定。打卡记录同时留下位置与图像，让记录具备事后可核验的价值，而不只是一张照片。

第三个取舍是把结果收回系统并归档。报告由系统根据回收数据整理生成，不依赖人工汇总。这一步不做，前面的采集就白做了。

系统怎么承载这条链路

终端层负责任务接收、拍照与点位打卡；本地暂存层处理离线数据留存、网络状态判断与回传幂等；服务与归档层接收回传数据、生成报告并归档。三层之间的数据流向是单向的，避免现场与中心各存一份造成不一致。暂存数据带有状态标记，只有收到回传确认之后才清除本地副本。

交付状态与边界

两个仓库覆盖 2021 年 1 月至 3 月，最近一次提交在 2021 年 3 月，目前没有再更新的记录。边界说明：巡检终端设备的采购与配发由贵方负责，我们按机型做适配；巡检制度与点位划分由贵方业务部门确定，系统按配置承载，不预设业务规则；定位与地图能力以既有或签约的服务方案为准。应用按贵方确认的机型做适配，更换机型时需要重新做一轮兼容验证。