Java+uniapp双定位考勤系统：WiFi与GPS加权融合实战

简介本资源为基于Java与安卓UniApp的WiFi和GPS双定位学生课程考勤管理系统毕业设计源码包面向计算机、软件工程、通信工程等专业的在校学生与教师可用于毕业设计、课程设计、作业或项目立项演示。项目采用SSM后端与UniApp跨端前端通过WiFi与GPS双重定位实现课堂考勤签到已获导师认可答辩评审95分并经过Mac与Windows10/11测试运行成功。压缩包共455个文件约1019KB以270个js与112个vue文件为核心业务与页面逻辑辅以scss、jsx、css样式资源json配置、sql建表脚本、md使用文档及少量图片与图标结构完整便于二次开发。目前已有98人学习下载。读者可获得完整可运行源码、数据库脚本与使用文档理解双定位考勤的实现思路与前后端交互流程并在此基础上修改扩展功能适合作为高分毕设参考与进阶学习素材。1. 双定位考勤系统为什么单靠 GPS 或 WiFi 都会翻车做过高校考勤类项目的同学大概率都遇到过这个场景学生坐在教学楼三楼教室里手机 GPS 信号被楼板削得只剩两三颗星定位点飘到隔壁操场甚至马路对面换成纯 WiFi 判断又会出现学生连上教室 AP 但人其实在走廊抽烟或者宿舍楼和教学楼共用同一个 SSID 导致误判。单一定位源在室内场景下的可靠性是这类系统最核心的痛点。这个标题讲的就是用 Java 做后端、安卓端用 uniapp 做跨端壳、同时采集 WiFi 和 GPS 两路信号做加权判定的学生课程考勤管理系统。它解决的不是能不能定位而是在教室这种半封闭空间里怎么把定位误差压到可接受范围并且让考勤结果经得起学生申诉。适合正在做毕业设计、课程设计或者想把这套方案迁移到企业外勤打卡、实训室签到场景的开发者。后端 Java 负责考勤规则、数据落库和申诉流程前端 uniapp 负责一次编写同时出安卓包和 H5 管理端这是目前毕设里性价比最高的组合之一。2. 双定位融合的判定逻辑WiFi 指纹和 GPS 坐标怎么加权2.1 为什么不能简单取两个坐标的平均值很多人第一反应是把 WiFi 定位结果和 GPS 定位结果做算术平均这在工程上是错的。GPS 在室外精度能到 5 到 10 米室内可能直接漂移 100 米以上WiFi 指纹定位在室内能到 3 到 8 米但出了教学楼覆盖范围就完全失效。两者不是同等可信的数据源必须按场景动态分配权重。我一般会按信号强度做分段加权。GPS 卫星数大于等于 6 且水平精度因子HDOP小于 2 时GPS 权重给 0.7卫星数 3 到 5 时权重降到 0.4卫星数小于 3 直接判定 GPS 不可信权重归零。WiFi 这边看的是扫描到的 AP 数量和最强 AP 的 RSSI扫描到 3 个以上已知教室 AP 且最强 RSSI 大于 -70dBm 时权重给 0.8否则按比例衰减。// 双定位加权融合核心逻辑 public class LocationFusion { // 根据GPS卫星数和HDOP计算GPS可信权重 public static double calcGpsWeight(int satelliteCount, double hdop) { if (satelliteCount 6 hdop 2.0) return 0.7; if (satelliteCount 3 satelliteCount 6) return 0.4; return 0.0; // 卫星太少GPS不可信 } // 根据WiFi扫描结果计算WiFi可信权重 public static double calcWifiWeight(int knownApCount, int strongestRssi) { if (knownApCount 3 strongestRssi -70) return 0.8; if (knownApCount 1 strongestRssi -85) return 0.5; return 0.0; } // 加权融合返回最终判定坐标 public static double[] fuse(double[] gpsPoint, double gpsWeight, double[] wifiPoint, double wifiWeight) { double total gpsWeight wifiWeight; if (total 0) return null; // 两路都不可信触发人工复核 double x (gpsPoint[0] * gpsWeight wifiPoint[0] * wifiWeight) / total; double y (gpsPoint[1] * gpsWeight wifiPoint[1] * wifiWeight) / total; return new double[]{x, y}; } }这段代码的关键在于total 0的分支它对应的是两路信号都不可信的情况这时候不能硬算一个坐标出来必须把这条考勤记录标记为待复核交给教师端处理。参数上-70dBm 和 -85dBm 这两个 RSSI 阈值是我在几栋教学楼实测后取的如果你的教室 AP 密度更高可以把 -70 调到 -65 让 WiFi 判定更严格。2.2 WiFi 指纹库的采集与匹配WiFi 定位的精度完全取决于指纹库质量。所谓指纹就是每个教室在多个采样点上扫描到的 AP 列表和对应 RSSI 值。采集时我一般让学生拿着手机在教室走弓字形路线每隔 2 米采一个点每个点停留 5 秒取 10 次扫描的平均值这样能滤掉人体遮挡带来的瞬时波动。匹配阶段用加权 K 近邻WKNN。把实时扫描到的 AP 列表和指纹库里每个采样点做交集对交集内每个 AP 计算 RSSI 欧氏距离取距离最小的 K 个采样点K 通常取 4按距离倒数加权算出坐标。// WKNN指纹匹配 public double[] wknnMatch(MapString, Integer realtimeAps, ListFingerprintPoint fingerprintDb, int k) { Listdouble[] distances new ArrayList(); for (FingerprintPoint fp : fingerprintDb) { double sum 0; int matched 0; for (Map.EntryString, Integer ap : realtimeAps.entrySet()) { Integer dbRssi fp.getRssiMap().get(ap.getKey()); if (dbRssi ! null) { sum Math.pow(ap.getValue() - dbRssi, 2); matched; } } if (matched 2) { // 至少匹配2个AP才算有效 distances.add(new double[]{fp.getX(), fp.getY(), Math.sqrt(sum)}); } } distances.sort(Comparator.comparingDouble(a - a[2])); double wx 0, wy 0, wSum 0; for (int i 0; i Math.min(k, distances.size()); i) { double w 1.0 / (distances.get(i)[2] 0.001); // 防止除零 wx distances.get(i)[0] * w; wy distances.get(i)[1] * w; wSum w; } return new double[]{wx / wSum, wy / wSum}; }matched 2这个门槛很重要只匹配到一个 AP 时距离计算没有统计意义容易把学生定位到隔壁教室。0.001是防止实时 RSSI 和指纹库完全一致导致除零这个坑我在第一版里踩过当时直接抛 ArithmeticException 把整个考勤接口打挂了。3. uniapp 安卓端采集 WiFi 和 GPS 的实操配置3.1 manifest.json 里的权限与定位配置uniapp 打包安卓时定位和 WiFi 扫描权限必须在 manifest.json 里显式声明否则真机上直接静默失败这是最常见的翻车点。安卓 6.0 以后定位权限还分粗略和精确WiFi 扫描在安卓 9 以后要求开启定位服务才能拿到完整 AP 列表。{ app-plus: { distribute: { android: { permissions: [ uses-permission android:name\android.permission.ACCESS_FINE_LOCATION\/, uses-permission android:name\android.permission.ACCESS_COARSE_LOCATION\/, uses-permission android:name\android.permission.ACCESS_WIFI_STATE\/, uses-permission android:name\android.permission.CHANGE_WIFI_STATE\/, uses-permission android:name\android.permission.INTERNET\/ ] } } } }ACCESS_FINE_LOCATION 是必须的只声明 COARSE 的话安卓会拒绝返回 WiFi 扫描结果。CHANGE_WIFI_STATE 用于主动触发扫描不加的话只能拿到系统缓存的 AP 列表数据可能滞后几分钟。3.2 用 plus API 同时拉取 GPS 和 WiFi 数据uniapp 在安卓端调用原生能力走 plus 对象。GPS 用plus.geolocation.getCurrentPositionWiFi 列表用plus.android反射调用系统 WifiManager。这里要注意两个采集动作要并发发起串行的话总耗时可能超过 5 秒学生等不及就退出页面了。// 并发采集GPS和WiFi async function collectLocation() { const gpsPromise new Promise((resolve) { plus.geolocation.getCurrentPosition( (pos) resolve({ lng: pos.coords.longitude, lat: pos.coords.latitude, accuracy: pos.coords.accuracy, satellites: pos.coords.satellites || 0 }), (err) resolve(null), // 失败返回null不阻塞WiFi采集 { enableHighAccuracy: true, timeout: 4000 } ); }); const wifiPromise new Promise((resolve) { const main plus.android.runtimeMainActivity(); const Context plus.android.importClass(android.content.Context); const wifiManager main.getSystemService(Context.WIFI_SERVICE); plus.android.importClass(wifiManager); const scanResults wifiManager.getScanResults(); const list []; for (let i 0; i scanResults.size(); i) { const ap scanResults.get(i); plus.android.importClass(ap); list.push({ ssid: ap.SSID, bssid: ap.BSSID, rssi: ap.level }); } resolve(list); }); const [gps, wifi] await Promise.all([gpsPromise, wifiPromise]); return { gps, wifi, timestamp: Date.now() }; }timeout: 4000是给 GPS 设的硬上限室内经常 4 秒还定不到就让它返回 null靠 WiFi 兜底。enableHighAccuracy: true会强制走 GPS 芯片而不是基站定位精度更高但更耗电考勤场景一次采集可以接受。WiFi 部分用plus.android.importClass反射这是 uniapp 调安卓原生类的标准姿势注意每个对象都要 importClass 一次漏了会报方法不存在。3.3 采集数据的本地缓存与断网续传教学楼里经常有网络盲区学生点了签到但请求发不出去。我的做法是采集完先写本地 storage标记为 pending 状态同时发起上传上传失败就留在本地下次进考勤页面时先扫一遍 pending 记录重传。function saveAndUpload(record) { const pending uni.getStorageSync(pendingAttendance) || []; record.localId local_ Date.now(); pending.push(record); uni.setStorageSync(pendingAttendance, pending); uploadRecord(record).then(() { // 上传成功从pending里移除 const list uni.getStorageSync(pendingAttendance) || []; const filtered list.filter(r r.localId ! record.localId); uni.setStorageSync(pendingAttendance, filtered); }).catch(() { /* 保留在本地下次重传 */ }); }localId用时间戳生成服务端收到后先按 localId 做幂等去重避免重传导致重复考勤记录。这个幂等键的设计是血泪经验早期版本没做去重一个学生断网重传三次就生成了三条考勤统计报表直接对不上。4. Java 后端考勤判定与防作弊设计4.1 考勤状态机的设计后端不能只存一个已签到布尔值要设计成状态机才能支撑申诉流程。我一般用这几个状态PENDING已采集待判定、NORMAL正常、LATE迟到、ABSENT缺勤、SUSPICIOUS定位可疑待复核、APPEALING申诉中、CONFIRMED申诉后确认。public enum AttendanceStatus { PENDING, NORMAL, LATE, ABSENT, SUSPICIOUS, APPEALING, CONFIRMED } // 判定核心融合坐标与教室中心点距离 public AttendanceStatus judge(AttendanceRecord record, Classroom classroom) { double[] fused LocationFusion.fuse( record.getGpsPoint(), record.getGpsWeight(), record.getWifiPoint(), record.getWifiWeight() ); if (fused null) return AttendanceStatus.SUSPICIOUS; double distance GeoUtil.distance(fused[0], fused[1], classroom.getCenterLng(), classroom.getCenterLat()); if (distance classroom.getRadius() * 1.5) return AttendanceStatus.SUSPICIOUS; if (distance classroom.getRadius()) return AttendanceStatus.APPEALING; // 距离合格再看时间 return record.getCheckTime().after(classroom.getStartTime()) ? AttendanceStatus.LATE : AttendanceStatus.NORMAL; }classroom.getRadius()是每个教室配置的允许半径普通教室我设 30 米大阶梯教室设 50 米。* 1.5是可疑判定缓冲区超出 1.5 倍半径直接标可疑落在 1 到 1.5 倍之间进申诉流程这样既不会误杀边缘位置的学生又能拦住明显在宿舍签到的。4.2 防代签的几道防线代签是考勤系统绕不开的问题。单靠定位拦不住人机分离——学生把手机给室友带去教室。我一般叠三层一是设备指纹同一设备短时间内给多个学号签到直接拦截二是采集时间与签到时间的差值超过 2 分钟说明是提前采集好数据后补交三是随机抓拍签到成功后前端静默调一次前置摄像头拍一张低分辨率照片存证不弹预览不打扰学生。// 设备指纹防代签 public boolean checkDeviceAbuse(String deviceId, String studentId, long timestamp) { String key device: deviceId; ListString recentStudents redis.lrange(key, 0, -1); // 同一设备5分钟内出现3个以上不同学号判定代签 long distinctCount recentStudents.stream().distinct().count(); if (distinctCount 3) return false; redis.lpush(key, studentId); redis.expire(key, 300); return true; }用 Redis 存设备最近关联的学号列表5 分钟窗口内超过 3 个不同学号就拒绝。expire设 300 秒和窗口对齐避免 key 无限堆积。这个阈值可以根据班级规模调大班课可以放宽到 5 个。5. 避坑与排查双定位考勤最容易翻车的五个地方5.1 现象安卓 10 以上真机 WiFi 扫描返回空列表原因安卓 10 开始getScanResults要求应用已获取精确位置权限且系统定位服务处于开启状态缺一不可。很多同学只加了权限但没引导用户开定位开关。解决在采集前用plus.android检查LocationManager.isLocationEnabled()未开启时弹窗引导跳系统设置页而不是直接返回空数据让用户一脸懵。5.2 现象GPS 坐标在室内频繁跳变同一位置两次采集差 80 米原因室内 GPS 靠信号反射定位多径效应严重单次采集不可信。解决连续采集 3 次取中位数并且用pos.coords.accuracy过滤掉精度差于 50 米的点。accuracy 这个字段很多人忽略它直接告诉你这次定位有多不靠谱。5.3 现象uniapp 打包后 H5 端能跑安卓端调 plus 报 undefined原因plus 对象只在 5 App 环境存在H5 里没有。代码里直接写plus.geolocation在 H5 会抛错。解决用条件编译#ifdef APP-PLUS包住所有 plus 调用H5 端走浏览器的navigator.geolocation降级方案两端逻辑分开写。5.4 现象考勤记录时间对不上服务端存的时间比学生手机时间早 8 小时原因服务端用new Date()取的是服务器时区时间学生手机可能是任意时区直接存客户端时间戳又可能被篡改。解决统一用服务端时间做判定基准客户端时间只作为参考字段存下来。前端采集时带上客户端时间戳服务端收到后计算差值差值超过 5 分钟的记录标记异常。5.5 现象指纹库匹配总是定位到隔壁教室原因相邻教室 AP 信号互相穿透RSSI 差异小于 5dBm 时 WKNN 无法区分。解决指纹采集时记录每个 AP 的 BSSID 而不是 SSID同一 SSID 下不同教室的 AP 有不同 BSSID用 BSSID 做匹配键能显著提升区分度。另外把 K 值从 4 降到 3减少远距离采样点的干扰。6. 把定位精度量化出来一套可复用的验证方法系统做完不能只看能签到得拿数据证明定位准。我一般会在每栋教学楼选 5 个测试点每个点采集 20 次统计定位结果落在正确教室的比例和平均误差距离。这套验证方法比任何主观感受都靠谱也是答辩时最能加分的部分。测试场景采样次数正确教室命中率平均误差主要失败原因教室中央靠窗2095%4.2 米GPS 漂移教室后排角落2085%7.8 米AP 遮挡走廊靠近教室门2070%12.5 米边界模糊隔壁教室2090%6.1 米信号穿透楼梯间2055%18.3 米双路都弱走廊和楼梯间是重灾区命中率明显掉下来。针对这两个场景我的处理是把判定半径从 30 米收到 20 米宁可让边缘学生走申诉流程也不放明显不在教室的人过。申诉流程本身也是验证数据来源教师端每次人工确认的结果可以反哺指纹库把误判点的实际坐标补进去。// 精度统计工具计算一组定位结果的标准差 public static double calcStdDev(ListDouble errors) { double mean errors.stream().mapToDouble(d - d).average().orElse(0); double variance errors.stream() .mapToDouble(d - Math.pow(d - mean, 2)) .average().orElse(0); return Math.sqrt(variance); }标准差比平均值更能反映稳定性。平均值 5 米但标准差 15 米的系统说明偶尔会飘很远这种在考勤场景里比稳定 8 米误差更危险因为飘出去的那次可能正好把学生判成缺勤。我现在的习惯是每次改完权重参数先跑一遍这 100 个采样点看标准差有没有变大变大就回滚。这套笨办法帮我躲过了好几次改完感觉更好但实际更差的玄学调参。希望帮到你。本文还有配套的精品资源点击获取