简介本资源是一套基于Java与安卓UniApp开发的WiFi和GPS双定位学生课程考勤管理系统面向计算机、软件工程、通信工程等专业的在校学生与教师可用于毕业设计、课程设计或项目立项演示。项目采用SSM框架搭建后端前端以UniApp实现跨端考勤应用通过WiFi与GPS双重定位完成课堂签到与考勤统计属于高分优秀毕设作品答辩评审达95分。压缩包共455个文件约1019KB以270个js与112个vue文件为核心业务代码辅以scss、jsx、css等样式与组件文件另含sql数据库脚本、json配置、md使用文档及少量图片资源结构完整、层次清晰。目前已有98人学习关注。读者可获得完整可运行的源码、数据库脚本与使用说明代码经Mac与Windows10/11测试通过既能直接用于毕设答辩也便于在此基础上二次修改扩展功能适合进阶学习与实战参考。1. 双定位考勤系统为什么单靠 GPS 或 WiFi 都会翻车做过高校考勤类项目的工程师多半遇到过这种场景学生坐在教学楼三楼教室GPS 定位却飘到了隔壁操场或者明明人在宿舍连上校园 WiFi 后系统判定已到教室。单一定位方案在室内外交界处几乎必然翻车这不是代码写得不好而是物理层信号本身的局限。GPS 在室内衰减严重冷启动首次定位可能要 30 秒以上误差从 5 米到 50 米都出现过WiFi 定位依赖 AP 指纹库一旦路由器更换或信号被遮挡判定结果同样不可信。这套基于 Java 后端 安卓 uniapp 前端的双定位考勤系统核心思路就是让 GPS 和 WiFi 互相校验室外用 GPS 兜底室内用 WiFi 指纹补位两者都拿不到可信结果时降级为手动签到并标记异常。它适合正在做毕业设计、课程设计或者想给中小型机构搭一套轻量考勤工具的开发者。整套方案不依赖昂贵的硬件定位设备一部普通安卓手机加一套 Java 服务端就能跑起来这也是它在学生课程考勤场景里比专业定位方案更实用的原因。2. 双定位判定逻辑GPS 与 WiFi 怎么协同才不打架2.1 定位优先级与降级策略双定位不是简单地把两个坐标取平均那样只会让误差叠加。我一般采用的策略是分场景判定先看 GPS 是否可用且精度达标再看 WiFi 指纹是否命中已知 AP 列表最后根据课程配置的签到点类型决定采信哪个结果。具体判定流程是这样的客户端每次签到上报时同时携带 GPS 经纬度、定位精度accuracy 字段单位米、当前连接的 WiFi BSSID 和信号强度 RSSI。服务端收到后按下面的优先级处理优先级条件采信结果标记1GPS accuracy ≤ 30 米且距签到点 ≤ 100 米GPS 坐标正常2WiFi BSSID 命中签到点绑定 AP 列表WiFi 判定正常3GPS 可用但精度 30 米GPS 坐标精度存疑4两者都不可用无异常待审这个优先级表的关键在于GPS 精度达标时优先信 GPS因为它的坐标是连续的、可追溯的WiFi 只在 GPS 不可信时作为补充。很多同学一开始把 WiFi 放在最高优先级结果学生在教学楼外连上了教室的 AP信号穿墙照样能签到这就失去了考勤的意义。2.2 服务端判定接口的实现后端用 Spring Boot 写一个签到判定接口核心逻辑集中在AttendanceService里。下面是我常用的实现骨架Service public class AttendanceService { Autowired private CheckinPointMapper checkinPointMapper; // 签到判定主方法 public CheckinResult judge(CheckinRequest req) { CheckinPoint point checkinPointMapper.selectById(req.getPointId()); if (point null) { return CheckinResult.fail(签到点不存在); } // 第一优先级GPS 精度达标且距离在阈值内 if (req.getAccuracy() ! null req.getAccuracy() 30) { double dist GeoUtil.distance( req.getLat(), req.getLng(), point.getLat(), point.getLng()); if (dist point.getRadius()) { return CheckinResult.ok(GPS, dist); } } // 第二优先级WiFi BSSID 命中绑定列表 if (req.getBssid() ! null point.getApList().contains(req.getBssid())) { return CheckinResult.ok(WIFI, 0); } // 降级GPS 可用但精度差标记存疑 if (req.getLat() ! null) { return CheckinResult.suspect(GPS精度不足); } return CheckinResult.fail(无法定位); } }这段代码里几个参数需要重点说明。accuracy 30这个阈值不是拍脑袋定的实测中安卓手机在室外开阔地 accuracy 通常在 8 到 20 米之间教学楼附近会跳到 30 到 60 米取 30 米是兼顾覆盖率和可信度的折中值。point.getRadius()是每个签到点单独配置的允许半径教室场景一般设 80 到 150 米因为 GPS 在楼宇间的漂移可能达到这个量级。point.getApList()存的是该签到点绑定的 WiFi BSSID 白名单注意是 BSSID 不是 SSID因为同一栋楼里 SSID 可能重名BSSID 才是 AP 的唯一标识。GeoUtil.distance用 Haversine 公式计算两点球面距离不要用简单的平面勾股定理纬度差一度对应的实际距离在不同纬度下差别很大。这个工具类网上有成熟实现直接拿来用即可。2.3 uniapp 端定位数据的采集前端在 uniapp 里调安卓原生定位能力需要注意 manifest 配置和权限申请。下面是一段可复用的采集逻辑// 采集 GPS WiFi 信息 function collectLocation() { return new Promise((resolve) { // GPS 定位超时 8 秒 uni.getLocation({ type: gcj02, timeout: 8000, success: (res) { // 安卓端 accuracy 在 res.accuracy 里 const gps { lat: res.latitude, lng: res.longitude, accuracy: res.accuracy || 999 }; // 再取 WiFi 信息 getWifiInfo((wifi) { resolve({ ...gps, ...wifi }); }); }, fail: () { // GPS 失败也要尝试拿 WiFi getWifiInfo((wifi) resolve({ ...wifi })); } }); }); }type: gcj02是国内常用的坐标系如果后端存的是 WGS84这里要统一否则距离计算会差出几百米。timeout: 8000是防止 GPS 冷启动卡死8 秒拿不到就降级走 WiFi。accuracy字段在部分安卓机型上可能返回 null所以代码里给了 999 的兜底值让服务端判定时直接走降级分支。WiFi 信息的获取在 uniapp 里没有统一 API安卓端需要通过 plus 对象调原生function getWifiInfo(callback) { try { const main plus.android.runtimeMainActivity(); const Context plus.android.importClass(android.content.Context); const wifiManager main.getSystemService(Context.WIFI_SERVICE); const info wifiManager.getConnectionInfo(); if (info) { callback({ bssid: info.getBSSID(), rssi: info.getRssi() }); } else { callback({}); } } catch (e) { callback({}); } }这段代码必须在真机上跑模拟器拿不到真实 WiFi 信息。getBSSID()返回的是形如aa:bb:cc:dd:ee:ff的字符串存库时统一转小写避免大小写不一致导致匹配失败。getRssi()是信号强度单位 dBm一般 -30 到 -50 表示很近-80 以下基本不可用可以在服务端加一条 RSSI 阈值过滤防止连上远处弱信号的 AP 也算签到。3. 数据库设计与签到点配置把定位规则落到表结构里3.1 核心表结构与字段说明考勤系统的数据模型不复杂但定位相关的字段设计直接影响后续判定的灵活性。下面是我实际用过的几张核心表-- 签到点表 CREATE TABLE checkin_point ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT NOT NULL, name VARCHAR(64) NOT NULL, lat DECIMAL(10,7) NOT NULL, lng DECIMAL(10,7) NOT NULL, radius INT DEFAULT 100 COMMENT 允许半径(米), ap_list TEXT COMMENT 绑定的BSSID列表,逗号分隔, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 考勤记录表 CREATE TABLE attendance_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, point_id BIGINT NOT NULL, checkin_time DATETIME NOT NULL, locate_type VARCHAR(8) COMMENT GPS/WIFI/NONE, lat DECIMAL(10,7), lng DECIMAL(10,7), accuracy INT, bssid VARCHAR(32), status TINYINT DEFAULT 1 COMMENT 1正常 2存疑 3异常, INDEX idx_student_course (student_id, point_id) );lat和lng用DECIMAL(10,7)而不是FLOAT因为浮点数在距离计算时会有精度损失7 位小数对应约 1 厘米精度足够用。ap_list用逗号分隔的文本存 BSSID简单场景够用如果签到点很多、AP 列表很长建议拆成独立的checkin_point_ap关联表查询时用 JOIN避免文本解析开销。status字段区分正常、存疑、异常三态存疑记录不直接判缺勤留给教师人工复核这是实际使用中很关键的一个设计——机器判定不可能百分百准留个人工兜底的口子比追求全自动更靠谱。3.2 签到点配置的实操步骤配置一个签到点的完整流程是这样的第一步教师端在管理后台新建签到点填写课程、名称、经纬度。经纬度可以直接在地图上点选也可以用手机在教室现场采集一次 GPS 坐标填进去。第二步绑定 WiFi。教师站在教室门口用管理端 App 读取当前连接的 BSSID一键添加到该签到点的 AP 列表。注意要采集多个 AP因为一间教室可能覆盖两三个路由器学生手机连的可能是任意一个。第三步设置半径。教室场景建议 100 米阶梯教室或大教室可以放宽到 150 米室外场地按实际范围设。半径设太小会导致正常在教室的学生被判异常设太大则失去考勤约束力。第四步测试验证。用两三台不同品牌的安卓手机在教室不同位置签到观察判定结果和上报的 accuracy、bssid 值根据实测数据微调半径和 AP 列表。提示签到点配置完成后不要频繁改动每次改动都会影响历史记录的可比性。如果确实要调整建议新建签到点而不是修改旧的。3.3 考勤统计与异常处理签到记录落库后统计逻辑相对直接按课程和学生分组统计正常签到次数存疑记录单独列出。我一般会在服务端加一个定时任务课程结束后自动把当次考勤的存疑记录汇总推送给教师复核。异常处理有几个常见分支需要覆盖学生手机 GPS 完全不可用比如关闭了定位权限此时上报的 accuracy 为 999服务端走 WiFi 判定WiFi 也没连上则记录为异常允许学生在规定时间内提交补签申请教师审批。补签申请这个功能看起来是后悔药但在实际教学场景里必不可少因为总会有学生手机没电、信号差等客观情况。统计接口用一条 SQL 就能出结果SELECT student_id, SUM(CASE WHEN status 1 THEN 1 ELSE 0 END) AS normal_cnt, SUM(CASE WHEN status 2 THEN 1 ELSE 0 END) AS suspect_cnt, SUM(CASE WHEN status 3 THEN 1 ELSE 0 END) AS abnormal_cnt FROM attendance_record WHERE point_id IN (SELECT id FROM checkin_point WHERE course_id ?) GROUP BY student_id;这条 SQL 按学生聚合三类签到次数教师端直接展示成表格。注意status 3的异常记录不要直接算缺勤要结合补签审批结果一起看否则统计口径会和实际不符。4. 避坑与排查双定位考勤最容易翻车的五个地方4.1 现象学生人在教室系统判定距离 300 米原因安卓手机在室内 GPS 信号弱系统返回的是基站或 WiFi 辅助定位的粗略坐标accuracy 可能显示 50 到 200 米但部分机型不返回 accuracy 或返回一个偏小的假值导致服务端误信 GPS 结果。解决服务端不能只信客户端上报的 accuracy要加一层合理性校验。如果 GPS 坐标与签到点距离超过 500 米即使 accuracy 显示很小也强制降级走 WiFi 判定。另外可以在客户端连续采集 3 次 GPS取 accuracy 最小的那次上报减少单次漂移的影响。4.2 现象WiFi 判定时好时坏同一间教室有的学生能签有的不能原因学生手机连接的 AP 不同而签到点只绑定了其中一个 BSSID。一间教室可能有两三个 AP学生连到哪个是随机的。解决配置签到点时要采集教室内所有 AP 的 BSSID全部加入白名单。采集方法是在教室不同位置走动记录手机连过的所有 BSSID。另外注意 2.4G 和 5G 频段的 BSSID 通常不同两个都要加。4.3 现象uniapp 打包后 WiFi 信息拿不到返回空原因安卓 6.0 以上获取 WiFi 信息需要定位权限安卓 10 以上还需要额外申请ACCESS_FINE_LOCATION且部分机型要求开启系统定位开关才能返回 BSSID。解决在 manifest.json 里声明定位权限运行时动态申请。代码里对getBSSID()返回 null 的情况做兜底不要直接崩溃。测试时务必用真机模拟器和部分定制 ROM 会屏蔽 WiFi 信息。4.4 现象GPS 坐标存进去后距离计算偏差几百米原因坐标系不统一。uniapp 的getLocation默认返回 gcj02而有些地图 SDK 或后端存的是 WGS84两者在国内相差几十到几百米。解决全链路统一坐标系。我一般统一用 gcj02客户端采集、服务端存储、距离计算都用同一套。如果必须转换用成熟的坐标转换工具类不要自己写近似公式。4.5 现象签到高峰期接口响应慢大量请求超时原因每次签到都要查签到点、算距离、匹配 AP 列表数据库压力大尤其是上课前几分钟集中签到。解决签到点信息加缓存用 Redis 或本地 Caffeine 缓存避免每次查库。距离计算是纯计算不涉及 IO问题不大。AP 列表匹配如果用的是文本 contains数据量大时慢改成 Set 结构或独立关联表。另外客户端加一个简单的防重复提交同一学生 30 秒内只允许提交一次。5. 定位精度调优几个我踩过坑才总结出的参数技巧双定位考勤系统能不能用最终取决于判定准不准。前面把框架搭起来了这里说几个调参的实战经验都是踩过坑才摸出来的。第一个是 GPS 精度阈值的动态调整。固定 30 米不是最优解我后来改成按签到点类型区分室外签到点用 50 米室内签到点用 30 米因为室外 GPS 本身更准放宽阈值反而能提高通过率。这个阈值存在签到点表里每个点单独配。第二个是 WiFi 的 RSSI 过滤。光匹配 BSSID 不够还要看信号强度。我一般设 -75 dBm 为下限低于这个值说明学生可能在教室外很远的地方即使 BSSID 匹配也不给过。这个值可以根据教室大小微调大教室放宽到 -80。第三个是连续定位取最优。客户端签到前连续采集 3 次 GPS间隔 1 秒取 accuracy 最小的那次。实测能把室内定位的可用率从 60% 提升到 85% 左右。代价是签到多等 2 秒可以接受。第四个是签到时间窗口。不要让学生一进教学楼就能签要结合课程时间。我一般设签到开始时间为上课前 10 分钟结束时间为上课后 15 分钟窗口外的签到标记为异常。这样能防止学生提前很久签到然后离开。验证调优效果的方法很简单找 5 到 10 个学生在教室不同位置、不同时间段各签到 10 次统计正常判定率。正常判定率低于 90% 就说明参数还需要调重点看是 GPS 漂移多还是 WiFi 匹配失败多针对性调整。参数推荐值调整方向GPS accuracy 阈值室内30 米判定通过率低就放宽GPS accuracy 阈值室外50 米误判多就收紧签到半径教室100 米按教室实际大小调RSSI 下限-75 dBm大教室放宽到 -80连续采集次数3 次精度要求高可加到 5 次最后说个习惯每次调整参数后我都会把当次的签到记录导出人工核对一遍判定结果和实际情况是否一致。机器判定再智能也替代不了人对现场的判断。这套系统我前后调了两周才稳定下来前期翻车最多的就是太相信单次 GPS 上报值。希望帮到你。本文还有配套的精品资源点击获取