简介这是一套面向高校课程考勤场景的安卓学生签到系统完整源码适合具备SSM框架与Android基础、需要完成课程设计或毕业设计的开发者参考。项目采用Android Studio开发移动端后端基于SSM框架并在IntelliJ IDEA中构建实现扫码签到、数字签到与定位签到三种考勤方式同时支持修改签到记录并附带加课码选课功能覆盖了从选课到考勤的完整业务闭环。资源包共3个文件包含2个rar压缩包与1个sql数据库文件分别对应后端工程、Android前端工程以及初始数据库脚本整体约139MB解压后可直接导入IDEA与AS进行二次开发。目前已有837人学习下载读者可借此获得一套结构清晰、功能完整的签到系统实现方案快速理解移动端与服务端的数据交互流程并参考数据库设计完成部署与调试。1. 基于安卓的学生签到系统从定位签到到离线补签的完整落地路径课堂点名这件事做过教务系统的人都知道真正的痛点从来不是“能不能点”而是“怎么证明学生真的到了现场”。早期方案靠老师肉眼扫一圈后来换成二维码轮播再后来是 GPS 定位打卡每一步都在跟“代签”这个对手博弈。基于安卓的学生签到系统本质上是把签到终端从浏览器搬到原生 App利用安卓的定位、网络状态感知和本地存储能力把“到没到、什么时候到、有没有网”这三件事同时管住。它适合两类人一类是高校教务或实验室里需要自建签到工具的开发同学另一类是正在做安卓课程设计、想找一个有真实业务闭环的练手项目的人。这篇文章不讲空泛的架构图只讲一条能跑通的路径定位怎么取、距离怎么算、离线怎么存、补签怎么防。2. 签到系统的技术选型为什么是安卓原生而不是小程序2.1 定位精度与后台存活能力的取舍选安卓原生最直接的理由是定位权限的颗粒度。小程序或 H5 拿到的定位通常是系统浏览器封装后的结果精度被限制在百米级而且页面切到后台就容易被冻结。安卓原生通过FusedLocationProviderClient可以拿到PRIORITY_HIGH_ACCURACY级别的坐标配合ACCESS_FINE_LOCATION权限在室外开阔环境下能稳定在 5 到 15 米。这个精度对于判断“是否在教学楼内”已经够用。另一个关键点是后台存活。签到场景里学生可能锁屏后走到教室再打开 App如果进程被系统回收重新冷启动会丢失上一次的定位上下文。原生方案可以用ForegroundService在签到窗口期内保持一个低功耗的前台服务配合WorkManager做延迟补传。小程序做不到这一点它的生命周期完全由宿主控制。提示不要用getLastKnownLocation作为唯一数据源它可能返回几小时前的缓存坐标在跨楼栋场景下会直接判错。2.2 服务端最小闭环三个接口撑起整个签到流程服务端不需要复杂三个接口就能跑通接口方法作用关键参数/api/session/createPOST教师发起签到生成签到码和有效窗口courseId,teacherLat,teacherLng,radius,duration/api/sign/inPOST学生提交签到sessionId,studentId,lat,lng,timestamp,deviceId/api/sign/statusGET查询某次签到的完成情况sessionId教师端发起签到后服务端返回一个sessionId和expireAt。学生端拿到这两个值在有效期内提交坐标。服务端做两件事算距离、查重。距离用 Haversine 公式查重靠studentId sessionId的唯一索引。-- 签到记录表唯一索引防止重复提交 CREATE TABLE sign_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, session_id VARCHAR(64) NOT NULL, student_id VARCHAR(32) NOT NULL, lat DECIMAL(10,7) NOT NULL, lng DECIMAL(10,7) NOT NULL, distance_m INT NOT NULL, sign_time DATETIME NOT NULL, device_id VARCHAR(64), UNIQUE KEY uk_session_student (session_id, student_id) );distance_m字段存的是服务端算出来的实际距离不是客户端上报的。客户端只报坐标距离由服务端统一计算这样即使有人篡改本地代码也改不了判定结果。device_id用于辅助识别同一台设备替多人签到的异常情况但不作为唯一拦截依据因为设备号本身也可能被改。2.3 安卓端权限申请与定位初始化安卓 6.0 之后定位权限是运行时申请12 之后还区分了精确和粗略。下面这段代码是签到页onCreate里的初始化逻辑// 检查并申请定位权限优先精确位置 private void ensureLocationPermission() { if (Build.VERSION.SDK_INT Build.VERSION_CODES.S) { // Android 12 需要同时申请 FINE 和 COARSE if (ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION) ! PackageManager.PERMISSION_GRANTED) { ActivityCompat.requestPermissions(this, new String[]{ Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION }, REQ_LOCATION); } else { startLocationUpdates(); } } else { if (ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION) ! PackageManager.PERMISSION_GRANTED) { ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.ACCESS_FINE_LOCATION}, REQ_LOCATION); } else { startLocationUpdates(); } } } // 启动定位更新间隔 3 秒最小位移 5 米 private void startLocationUpdates() { LocationRequest request LocationRequest.create() .setPriority(Priority.PRIORITY_HIGH_ACCURACY) .setInterval(3000) .setFastestInterval(1000) .setSmallestDisplacement(5); fusedClient.requestLocationUpdates(request, locationCallback, Looper.getMainLooper()); }setInterval(3000)是正常回调间隔setFastestInterval(1000)是其他应用也在请求定位时允许的最快回调setSmallestDisplacement(5)表示移动小于 5 米不触发回调。这三个参数配合使用既保证精度又不会把电量吃光。locationCallback里拿到Location对象后取getLatitude()、getLongitude()和getAccuracy()如果getAccuracy()大于 50 米就丢弃这次结果等下一次回调。3. 核心逻辑实现距离计算、离线缓存与补签机制3.1 Haversine 距离计算与半径判定服务端算距离用 Haversine 公式地球半径取 6371000 米。下面是一个可以直接用的 Java 实现// Haversine 公式计算两点间距离单位米 public static double haversine(double lat1, double lng1, double lat2, double lng2) { final double R 6371000; // 地球平均半径米 double dLat Math.toRadians(lat2 - lat1); double dLng Math.toRadians(lng2 - lng1); double a Math.sin(dLat / 2) * Math.sin(dLat / 2) Math.cos(Math.toRadians(lat1)) * Math.cos(Math.toRadians(lat2)) * Math.sin(dLng / 2) * Math.sin(dLng / 2); double c 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a)); return R * c; }lat1、lng1是教师端发起签到时上报的坐标lat2、lng2是学生端提交的坐标。算出来的距离跟radius比较默认设 100 米教学楼内可以收紧到 50 米。这里有个容易翻车的点教师端坐标如果是在办公室随手取的可能跟教室实际位置差几十米导致全班都签不上。常见做法是让教师在教室讲台位置发起签到或者允许教师手动微调坐标。3.2 离线签到本地队列与网络恢复后的补传学生进教学楼后信号差是常态离线签到必须支持。安卓端用 Room 建一张本地待传表// 本地待传签到记录 Entity(tableName pending_sign) public class PendingSign { PrimaryKey(autoGenerate true) public int id; public String sessionId; public String studentId; public double lat; public double lng; public long timestamp; public String deviceId; }提交时先写本地表再尝试调接口。接口成功就删掉本地记录失败就留着。网络恢复的监听用ConnectivityManager注册回调一旦onAvailable触发就起一个WorkManager任务把pending_sign表里的记录逐条上传。上传时带上原始timestamp服务端根据timestamp判断是否在签到窗口内而不是根据收到请求的时间。这一点很关键否则学生离线时签的到联网后补传会被判超时。// 网络恢复后触发补传 ConnectivityManager cm (ConnectivityManager) getSystemService(CONNECTIVITY_SERVICE); cm.registerDefaultNetworkCallback(new ConnectivityManager.NetworkCallback() { Override public void onAvailable(NonNull Network network) { // 网络可用启动补传任务 OneTimeWorkRequest syncWork new OneTimeWorkRequest.Builder(SyncWorker.class).build(); WorkManager.getInstance(context).enqueue(syncWork); } });SyncWorker里查pending_sign表逐条 POST 到/api/sign/in服务端返回成功就删本地记录。如果返回“已签到”也删本地记录避免死循环。3.3 补签机制教师端手动放行与日志留痕总会有学生因为设备问题、权限没开、定位漂移等原因签不上。系统必须给教师一个补签入口但不能让补签变成后门。做法是教师端可以针对某个sessionId手动添加一条sign_record但这条记录的device_id字段写死为MANUAL_BY_TEACHER并且额外写一条操作日志。-- 补签操作日志 CREATE TABLE sign_audit ( id BIGINT PRIMARY KEY AUTO_INCREMENT, session_id VARCHAR(64) NOT NULL, student_id VARCHAR(32) NOT NULL, operator_id VARCHAR(32) NOT NULL, reason VARCHAR(255), created_at DATETIME DEFAULT CURRENT_TIMESTAMP );补签接口只对教师角色开放且每次补签都要填reason。期末导出签到时补签记录单独标色方便复核。这样既解决了实际问题又留下了可追溯的痕迹。4. 避坑与排查签到系统上线后最容易翻车的五件事4.1 定位漂移导致全班签不上现象教师发起签到后大量学生反馈“距离超出范围”但学生确实在教室里。原因安卓定位在室内主要靠 Wi-Fi 和基站精度可能到 100 米以上。如果教师端坐标本身也有偏差两个误差叠加就超半径了。解决把radius默认值从 50 米放宽到 150 米同时客户端上报accuracy服务端在accuracy 80时自动把判定半径临时放大 1.5 倍。另外建议教师在教室窗户边发起签到GPS 信号会好很多。4.2 离线补传被判定超时现象学生离线时签了到联网后补传系统提示“签到已过期”。原因服务端用System.currentTimeMillis()做超时判断没有读客户端上报的timestamp。解决服务端校验逻辑改成先解析客户端timestamp判断是否在[sessionStart, sessionEnd]区间内再用服务端当前时间判断是否超过sessionEnd 24小时防止无限期补传。两个条件都满足才写入。4.3 同一设备多人签到现象一个deviceId在短时间内提交了多个不同studentId的签到。原因学生之间互相帮忙签到用同一台手机切换账号。解决服务端加一条规则同一sessionId下同一deviceId出现超过 2 个不同studentId时后续记录标记为SUSPICIOUS不直接拒绝但推送给教师端复核。不要一刀切拒绝因为有些学生确实可能换手机或借同学手机应急。4.4 前台服务被系统杀掉现象学生锁屏后走到教室打开 App 发现定位没更新签到按钮一直转圈。原因安卓省电策略在锁屏后限制后台定位ForegroundService如果没有正确配置foregroundServiceType也会被限制。解决在AndroidManifest.xml里给服务声明android:foregroundServiceTypelocation并且在onStartCommand里调用startForeground时传入FOREGROUND_SERVICE_TYPE_LOCATION。同时引导用户在系统设置里把 App 的电池优化设为“无限制”。4.5 签到码被截图转发现象教师把签到码投屏学生拍照发给不在教室的人对方远程签到。原因签到码是静态的没有跟设备或位置绑定。解决签到码改成动态的每 30 秒刷新一次由服务端用sessionId 时间片做 HMAC 生成。学生端提交时带上当前码服务端校验时间片是否在允许的偏移范围内前后各 1 个时间片。这样截图转发后对方必须在 30 秒内完成签到且仍然要过定位判定成本高很多。5. 进阶技巧用签到数据做课堂行为分析签到系统跑通之后积累的sign_record表其实是一份很有价值的课堂行为数据。我一般会从三个维度去挖首次签到时间分布、补签率、异常设备聚集度。首次签到时间分布能看出学生的到课习惯。把每次签到的sign_time减去sessionStart得到“提前到达时长”。如果一个学生长期在签到开始后 5 分钟才提交说明他可能踩点到或者在路上签的。这个指标不需要额外采集直接从现有数据算。补签率按课程统计。如果某门课的补签率持续高于 15%要么是教室定位环境太差要么是这门课本身吸引力有问题。前者调半径后者就不是技术能解决的了。异常设备聚集度是防代签的进阶手段。把同一deviceId在不同sessionId下关联的studentId做成图如果某个设备节点连接了超过 5 个学生节点就标记为高风险设备。这个分析可以离线跑用一条 SQL 就能出初步结果-- 找出关联学生数超过 5 的设备 SELECT device_id, COUNT(DISTINCT student_id) AS student_cnt FROM sign_record WHERE device_id IS NOT NULL AND device_id ! MANUAL_BY_TEACHER GROUP BY device_id HAVING student_cnt 5 ORDER BY student_cnt DESC;查出来的设备列表交给教务人工复核不要自动封禁。我见过一个案例某个deviceId关联了 8 个学生最后发现是教室里的公用平板学生排队用它签到。如果自动封了反而影响正常教学。还有一个细节sign_record表的数据量一个学期下来可能几十万条session_id和student_id上都要建索引否则教师端查签到状态会越来越慢。我一般会在session_id上建普通索引在(session_id, student_id)上建唯一索引sign_time上建一个用于范围查询的索引。三个索引足够覆盖绝大多数查询场景。最后说一个我自己的习惯每次上线新的签到规则之前先拿上一个学期的历史数据跑一遍模拟。比如把半径从 100 米改成 80 米先算一下历史记录里有多少人会因此判失败。如果失败率超过 5%这个改动就要慎重。这个习惯帮我避免了好几次“拍脑袋改参数导致全班炸锅”的事故。希望帮到你。本文还有配套的精品资源点击获取
