简介面向高校相关专业学生、毕业设计者及初学Android与SSM整合开发的程序员这是一份含前后端完整实现的安卓学生签到系统项目资源。项目覆盖扫码签到、数字签到与定位签到三类主流方式并支持签到记录修改和加课码选课功能可用于课程设计、毕业设计或课堂考勤场景的二次开发。资源包共3个文件、总大小139.01MB包含两个RAR工程压缩包与一个SQL数据库脚本RAR包分别对应基于IntelliJ IDEA开发的SSM后端和基于Android Studio开发的前端SQL为可直接导入的初始数据库便于快速跑通项目并理解运行机制。已有837人学习下载适合需要参考完整前后端交互、数据库设计及功能模块实现的读者。从中可获取项目源码、数据库表结构及部署配置思路减少从零搭建环境与排查基础问题的时间。1. 项目缘起为什么学生签到非得自己搞一套做这个基于安卓的学生签到系统最初是因为发现市面上现成的签到工具普遍存在三个让人头大的问题。第一绝大部分云签到平台都要收费按班级、按学期订阅算下来是一笔不小的开销。第二数据不在自己手里学生签到记录都存在别人的服务器上涉及隐私和合规问题。第三也是最致命的——那些通用工具只管签上不管签真。学生只要把二维码截图发到群里人在宿舍就能完成签到老师点名查勤直接失去意义。所以我想自己做一套能落地、能防作弊、能离线运行、还能灵活改需求的安卓签到系统。客户端的载体选安卓是因为教室里的设备生态基本被安卓平板和手机占据而且安卓的定位、WiFi、蓝牙硬件接口开放程度高方便做环境指纹采集这些是iOS没法比的。这套系统的目标很简单学生打开App在指定时间和范围内完成签到老师端能看到实时统计和异常记录。但从技术实现的角度看它涉及用户体系、课程班次管理、LBS定位、WiFi环境嗅探、离线缓存、数据同步、后台保活、防篡改等一系列问题每个点都能单独写一篇文章。这篇文章我会从项目整体设计思路讲起拆解客户端核心模块的写法再到服务端接口设计和数据表结构最后把我在开发中踩过的坑和排查经验整理出来。内容尽量具体到代码级别和操作步骤方便你直接照着搭一套自己的版本。2. 整体架构与方案选型想清楚再动手2.1 技术栈选型为什么用Uniapp 原生安卓混合客户端选型上我认真考虑过三条路纯原生安卓开发、Flutter、Uniapp。纯原生安卓开发当然是最稳的性能和系统API调用都没得说GPS定位、WiFi扫描这些也能拿到最底层的数据。但问题是开发周期长一套代码只能跑安卓老师端如果还想出iOS版就得重新写一遍。Flutter性能和跨端都不错但Dart语言生态相对小众团队招人不好找。最终我选了Uniapp 原生安卓插件混合开发。Uniapp负责界面层和业务逻辑打包成APK后运行在安卓设备上我用原生安卓写了一个自定义插件模块专门负责高精度定位采集、WiFi扫描、设备信息读取这些Uniapp搞不定或者不好搞的活儿。这样既保住了开发的迭代速度又拿到了底层硬件的完整控制权。服务端选了Spring Boot这是团队最熟悉的技术栈生态成熟出问题好排查。数据库用MySQL签到记录这种结构化数据用关系型数据库最合适事务和索引都现成。服务端和客户端之间的通信走HTTP接口用JSON传数据简单直接不引入额外的RPC框架增加复杂度。2.2 核心需求拆解签到系统到底要解决哪些问题立项第一天我就把需求写成了清单核心目标一共四条学生能通过GPS定位完成地理围栏签到系统自动判断是否在允许范围内防止学生通过虚拟定位App伪造位置支持离线签到网络不好时先本地记录恢复网络后自动同步老师和管理员能实时查看签到统计导出到课率报表每一条拆开来看都不复杂但合在一起就会互相影响。比如离线签到和防作弊就是矛盾的离线时无法联网验证那签到依据只能靠客户端本地采集的数据一旦客户端被逆向或篡改签到记录就能被伪造。所以我的处理思路是——离线签到可以放行但记录上明确标注离线签到等联网后再通过IP归属、WiFi环境等多维信息做二次风险检测把高风险记录踢出来人工审核。2.3 数据库设计签到系统的数据表这样建数据库设计了六张核心表我把结构贴出来你直接照着建就行。用户表user存学生和老师账号不分角色表靠type字段区分0学生、1老师、2管理员。密码用BCrypt加密存储不存明文。基础字段包括id、学号工号、姓名、手机号、角色类型、创建时间。课程表course记录课程基本信息包括课程名称、授课教师ID、上课周次、上课时间段。一张课程表可能会对应多个班级所以单独建了一张课程班级关联表course_class避免字段冗余。签到任务表sign_task是核心表记录了每次签到活动的配置信息包括课程ID、签到开始时间、结束时间、允许签到的GPS坐标和半径、WiFi的BSSID列表、签到码、是否允许离线签到等。老师在App端创建签到任务时其实就是往这张表插一条数据。签到记录表sign_record记录每一次签到行为包括学生ID、签到任务ID、签到时间、GPS坐标、WiFi信息、设备IMEI、签到状态正常/迟到/早退/缺勤/异常、是否离线签到、风险标记字段。这张表会加联合索引student_id, task_id确保同一个签到任务下学生只能有一条有效记录这就是防重复签到的第一道保险。设备表device_info记录每个学生常用的设备指纹信息包括IMEI、设备型号、安卓版本、MAC地址注意安卓6以上拿MAC有限制后面细说。每次签到时客户端会把设备信息上传服务端会对比历史设备如果发现一个学生频繁换设备签到就要拉高异常等级。课程表、班级表、学生选课关系表这些常规表就不一一列了各位按照标准教务系统去设计即可核心就是上面的sign_task和sign_record两张表签到业务逻辑都围绕它们展开。3. 安卓客户端核心模块解析这些代码是怎么工作的3.1 高精度定位采集模块GPS和网络定位的取舍定位是整个签到系统最核心的能力直接决定签到结果准不准。我同时使用GPS定位和网络定位两种方式采集后做对比。GPS定位精度高误差能到5-10米但在室内经常拿不到卫星信号冷启动可能需要几十秒甚至一分钟以上。网络定位WiFi热点定位基站定位速度快、室内也能用但精度一般在20-100米误差浮动很大。我的策略是这样签到界面打开时先立刻获取一次网络定位结果作为即时参考同时启动GPS定位监听。GPS拿到有效定位后精度小于30米把GPS坐标作为主坐标上报网络坐标作为辅坐标一起传。两者相差超过200米的情况会标记为可疑因为正常情况下两种定位的偏差不应该这么大。代码实现上我用LocationManager直接操作原生定位服务LocationManager locationManager (LocationManager) getSystemService(Context.LOCATION_SERVICE); if (ActivityCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION) ! PackageManager.PERMISSION_GRANTED) { // 申请权限回调里继续初始化 return; } LocationListener gpsListener new LocationListener() { Override public void onLocationChanged(Location location) { if (location.getAccuracy() 30) { // 精度合格的GPS定位缓存并上传 handleLocationUpdate(location, GPS); } } }; locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 0, 0, gpsListener);注意上面代码里的权限判断安卓6.0以上动态权限是必须处理的建议把定位权限和WiFi权限一起申请因为后面做WiFi指纹采集也需要权限。定位监听注册之后一定要在onDestroy或签到完成时removeUpdates否则会一直监听白白耗电这是我早期版本忽略的问题。3.2 WiFi环境指纹室内签到防作弊的第二道闸门只靠GPS定位肯定不够毕竟很多教室在室内GPS定位不一定稳定。我引入WiFi环境指纹作为补充方案原理很简单每一个位置的WiFi信号环境都是独特的在教室A签到时的WiFi列表和宿舍里的完全不一样。具体实现是客户端在签到时扫描当前环境中的所有WiFi热点信息包括BSSID即MAC地址、SSID名称、信号强度把这些打包传给服务端。服务端在老师创建签到任务时已经记录了教室的标准WiFi指纹——允许签到的BSSID白名单。学生签到时如果检测到的WiFi列表与白名单匹配至少命中一个就说明学生确实在教室里反之就算GPS坐标伪造成功WiFi指纹也对不上。安卓扫描WiFi的代码WifiManager wifiManager (WifiManager) getApplicationContext().getSystemService(Context.WIFI_SERVICE); ListScanResult results wifiManager.getScanResults(); for (ScanResult result : results) { // result.BSSID 就是热点MAC地址格式形如xx:xx:xx:xx:xx:xx // result.SSID 是热点名称比如TeachingBuilding-4F-301 // result.level 是信号强度dBm一般-30到-90之间 WifiInfoBean bean new WifiInfoBean(result.BSSID, result.SSID, result.level); wifiList.add(bean); }注意两个坑。第一getScanResults()返回的热点列表需要注册广播监听因为WiFi扫描是异步完成的扫描完成后系统会发一个SCAN_RESULTS_AVAILABLE_ACTION广播你需要在广播接收器里去读取结果。第二当你的App没有连接WiFi时部分安卓机型上getScanResults()返回的结果会被系统清空或延迟导致拿不到完整列表。我最终的方案是每3秒主动发起一次扫描请求连续采样5次取并集数据上传这样基本能覆盖绝大多数教室环境。这个方案实测下来效果很明显学生的签到记录如果WiFi指纹完全不匹配即使GPS坐标在范围内也会被我标记为疑似代签。3.3 虚拟定位检测四个维度交叉验证虚拟定位是签到系统最头疼的作弊方式。网上各种虚拟定位App能把GPS坐标随便改到任何地方单纯靠位置判断完全拦不住。我的方案是四个维度交叉验证单一维度可能被绕过但四个同时绕过难度就高很多了。第一个维度是定位来源检查。我在客户端标记了定位数据的来源渠道是通过系统LocationManager拿的GPS坐标还是通过虚拟定位App伪造的。安卓系统有LocationManager的isFromMockProvider()方法可以直接判断这个方法对大多数虚拟定位软件有效但技术好的开发者可以绕过。第二个维度是传感器辅助。虚拟定位App只能改位置但改不了加速度传感器和陀螺仪的数据。我让客户端在签到时判断手机是否在运动中如果GPS坐标显示学生在教学楼A但加速度传感器数值一直是0手机静止不动说明手机可能被放在某个地方自动运行脚本。这招能拦住脚本挂机代签的情况。第三个维度是设备信息一致性。每次签到都上传IMEI、设备型号、系统版本等服务端对比历史记录。如果一个学生的账号在短时间内出现在三个不同的设备上直接标记异常。第四个维度是WiFi环境匹配。就是上一节说的虚拟定位App改不了真实的WiFi环境。服务端把这四个维度的信息汇总成一个风险评分0-100分60分以上的签到记录自动进入人工审核列表老师端能看到风险标签比如设备不匹配传感器异常WiFi不匹配。3.4 离线签到与本地缓存没有网络也能签到教室里的网络环境确实没法保证尤其是阶梯教室一个教室几百人同时连WiFi基本等于没网。所以离线签到是刚需。客户端的方案是Room数据库做本地缓存签到数据先写本地网络恢复后自动同步到服务端。核心逻辑是这样的签到按钮点击后客户端先在本地生成一条签到记录状态为待同步同时把GPS坐标、WiFi信息、传感器数据都保存在本地数据库。然后尝试请求服务端接口如果请求成功把本地状态改成已同步如果失败记录保存在本地同时启动一个WorkManager定时任务每10分钟尝试同步一次。但如果所有签到都先写本地那服务端防重复签到的唯一索引就形同虚设了。我的补偿方案是客户端本地也维护一个已签到任务ID集合同一个任务ID在本地就拦截重复提交同时每次同步时带上本地记录的唯一标识服务端按学生ID任务ID做去重两重保险。Room数据库表设计Entity(tableName offline_sign_record) public class OfflineSignRecord { PrimaryKey(autoGenerate true) private Long localId; ColumnInfo(name task_id) private Long taskId; ColumnInfo(name student_id) private Long studentId; ColumnInfo(name sign_time) private Long signTime; ColumnInfo(name latitude) private Double latitude; ColumnInfo(name longitude) private Double longitude; ColumnInfo(name wifi_json) private String wifiJson; ColumnInfo(name device_imei) private String deviceImei; ColumnInfo(name sync_status) private Integer syncStatus; // 0待同步 1已同步 2同步失败 }离线签到的记录会在同步时打上离线标记服务端会对离线记录再做一次IP归属地检查。如果离线记录在同步时的出口IP和学校出口IP段相差十万八千里就会被标记为风险记录。这算是分布式系统里经典的最终一致性思想在业务上的落地用户侧体验是无感的但风控侧是完整的。4. 服务端设计与接口实现签到数据如何流转4.1 接口设计一个签到动作对应几个请求服务端我做了四个核心接口分别对应签到流程的四个阶段。第一个是获取签到任务接口路径为GET /api/sign/task/current。学生打开签到页面时客户端请求这个接口服务端根据学生ID查询当前时间有效且学生已选课的签到任务返回任务详情包括签到截止时间、允许GPS范围、WiFi白名单、签到码等信息。第二个是提交签到接口路径为POST /api/sign/submit。客户端把定位、WiFi指纹、设备信息、传感器数据打包成JSON发送给服务端服务端做校验返回签到成功或失败及风险标记。第三个是同步离线记录接口路径为POST /api/sign/sync/batch。支持客户端一次性提交多条离线签到记录服务端循环处理并返回每条记录的处理结果。第四个是查看统计接口路径为GET /api/sign/stats老师和管理员调用返回课程签到汇总、已到/未到/迟到/异常名单。提交签到的接口请求体示例{ taskId: 1024, studentId: 2021001, latitude: 31.2304, longitude: 121.4737, locationType: GPS, accuracy: 12.5, wifiInfos: [ {bssid: 50:4d:5a:7e:00:11, ssid: Class-301, level: -45}, {bssid: 50:4d:5a:7e:00:22, ssid: TeachingBuilding, level: -58} ], deviceInfo: { imei: 860000000000000, model: Xiaomi 12, androidVersion: 13 }, sensorData: { accelerometerX: 0.02, accelerometerY: 9.71, accelerometerZ: 0.35, isDeviceMoving: false }, isOffline: false, clientRecordId: uuid-1024-sha, signTime: 1710000000000 }4.2 服务端校验逻辑签到成功的判定条件服务端收到签到请求后会按顺序执行以下校验逻辑每一步不过直接拒绝第一步校验签到时间。当前时间必须在任务开始和结束时间之间早到或迟到都会被拒绝但状态分别记录为早退或迟到不是直接拒绝而是计入异常列表。第二步校验签到码。签到任务可以设置签到码学生需要输入老师公布的当天签到码才能完成签到。这一步的核心作用是防止学生提前截图签到的二维码或链接所以签到码最好是随机的四位数字或字母老师上课时口头公布。第三步校验GPS坐标。计算提交坐标与任务中心点的距离用Haversine公式它是球面两点距离的标准算法如果超出允许范围默认200米可配置拒绝签到。这里要注意校园里GPS漂移是正常现象所以范围不要设太小否则很多正常签到会被误杀我实测200米是一个比较合理的值。第四步校验WiFi指纹。如果任务配置了WiFi白名单会检查提交的WiFi列表里是否有命中的BSSID。如果完全没匹配上记录风险标签WiFi环境不匹配。第五步运行风险评分引擎也就是上面说的四个维度交叉验证。这个引擎不在本次请求里阻塞返回结果而是写入一个异步队列计算完成后更新签到记录的风险评分。这样做的原因是传感器、设备一致性检测需要查历史数据比较耗时不能让签到请求一直挂着等。5. 从开发到上架打包、测试与踩坑实录5.1 安卓打包细节签名、混淆与权限配置安卓打包整个过程我都走了一遍最耗时间的是签名和混淆配置。APK签名是必须做的安卓系统不允许安装未签名的应用。我这边创建了一个签名文件用keytool生成keytool -genkey -v -keystore signrelease.keystore -alias student_sign -keyalg RSA -keysize 2048 -validity 36500签名文件一定要妥善保存最好同时保存在本机和加密云盘里泄露了别人就能用你的身份发布App丢失了应用市场以后无法升级只能换包名重发。这个文件我吃过一次亏当时放在共享盘里后来离职同事格式化时把共享盘清了幸好云盘有备份不然只能被迫换签名重新上架老用户全部无法覆盖升级。混淆配置上由于项目用到了自定义插件Uniapp的原生插件混淆规则里需要把插件类的keep规则加上不然打出来的包运行时会报ClassNotFoundException。具体的做法是在proguard-rules.pro里添加-keep class com.example.locationsdk.** { *; } -keep class com.example.wifisdk.** { *; }权限配置是另一个大坑。安卓6.0以上不仅要在AndroidManifest.xml声明权限还要在代码里动态申请。签到业务需要定位权限和WiFi权限第一次打开App必须弹出权限请求用户拒绝就进不了签到页。我的做法是在欢迎页就统一请求这两个权限给用户一个明确的说明弹窗告诉用户不授予定位权限将无法完成签到减少后续沟通成本。另外提醒一下targetSdkVersion不能太低现在谷歌Play要求targetSdk必须是34以上国内某些应用市场也陆续跟进了。但targetSdk升高之后安卓对后台定位和WiFi扫描的限制会更严格需要适配新的隐私政策。我最终targetSdk定为34compileSdk 34minSdk 23兼容安卓6.0。5.2 常见问题速查表这些坑我踩过了开发过程中遇到的典型问题我整理成了一个速查表。问题现象根本原因解决方案签到时GPS一直定位不到室内GPS信号差冷启动慢先给网络定位结果GPS定位成功后更新提示用户走到窗边部分机型扫描不到WiFi安卓10以上需要定位权限才能扫描WiFi确认已申请ACCESS_FINE_LOCATION权限后台运行一段时间后签到页卡死系统杀掉了后台Service用前台Service保活通知栏显示正在监听定位离线签到记录丢了本地数据库被系统清理每次同步成功后清理后台定期检查未同步记录并重试同一个学生反复签到成功服务端唯一索引没建对sign_record表加( student_id, task_id )联合唯一索引虚拟定位检测误杀太高isFromMockProvider误报增加传感器辅助判断以多维度评分替代一刀切这里重点说下后台保活的坑。签到过程中如果学生切到其他应用安卓系统可能把签到App的进程杀掉导致定位监听中断。我用前台服务解决核心思路是用startForeground()启动服务并在通知栏显示相关的提示信息。但国内各家ROM对通知栏权限有不同的默认设置有的默认禁止通知权限前台服务会启动失败需要在代码里引导用户开启通知权限。这个适配工作确实繁琐但签到场景下App不能被杀掉是刚需绕不开。5.3 性能与电量优化签到App也要省电定位服务一直挂着是耗电大户实测下来每分钟GPS唤醒一次8小时待机耗电超过30%这是不能忍的。我在定位策略上做了三项优化第一动态调整定位频率。App在前台且签到页面打开时每5秒定位一次App在后台时停掉GPS只保留网络定位每30秒获取一次粗定位用于检测学生是否已离开教室范围。发现离开范围后再启动GPS精确定位做确认。第二WiFi扫描频率降频。签到页打开时扫描一次后续每2分钟扫描一次因为教室环境短时间内不会变化扫得越密越浪费电还容易被系统限制频率。第三服务端加了一层心跳保活优化。客户端每60秒上报一次心跳服务端判断心跳异常时自动更新签到状态为连接中断并向老师端推送告警。这样老师能及时发现谁在签到后偷偷关闭了App。实测优化后8小时待机耗电降到了8%基本在可接受范围内。6. 防作弊体系实战如何识别代签和虚拟定位6.1 代签行为的识别设备、时间和行为三个维度代签是签到系统里最常见的作弊场景A同学让B同学拿着自己手机签到或者用自己的手机登陆A的账号签到。三种情况我都能检测出来。第一种情况是B拿自己手机登A的账号签到。此时服务端收到的设备指纹和A同学历史记录的设备指纹不一致。我的服务端逻辑是每个学生默认关联1-2台常用设备在签到风险评分里设备匹配权重占到30%。设备不匹配但GPS和WiFi正常风险评分会在40分左右不直接拒绝但会进入人工审核列表老师可以点进去核实。第二种情况是A把账号密码发给外校朋友朋友在校外伪造位置签到。这种情况下GPS可能被伪装但WiFi指纹和IP归属地对不上。外校IP加无匹配WiFi风险评分直接上70分系统自动拒绝签到。第三种情况是A提前录好签到操作视频或者脚本让B在教室里帮忙跑了一遍。这种最隐蔽因为设备指纹、WiFi、GPS都是真实的唯一的破绽是签到时间可能极短——正常学生打开App加载定位至少需要5-10秒而脚本可以在1秒内完成提交。我在服务端记录了从进入签到页到提交签到的耗时低于3秒的签到记录全部标记为疑似脚本。在测试中有一批学生频繁触发脚本标记后来调监控发现他们用了Auto.js之类的自动化工具自动点击。把这类App的出现频率纳入风险指标后作弊率明显下降了。6.2 数据安全签到记录防篡改和防回放签到数据在传输过程中最怕两件事被篡改和被回放。篡改就是改签到的坐标或时间回放就是把之前的签到请求原样再发一遍造成重复签到。防篡改我用的是签名机制。客户端在提交签到时把所有参数按字典序拼接成字符串加盐后做SHA256摘要放在请求头里。服务端用同样的规则验证摘要。盐值是打包时内置在原生插件里的一个随机字符串这样别人就算抓包拿到请求体改数据后签名对不上自然被拒绝。盐值本身不能写在纯Java层会被反编译拿到我放在JNI的so库里虽然不能绝对防住但能提高破解门槛。防回放用的是时间戳加nonce方案。每次请求带上当前时间戳和一个随机字符串。服务端在Redis里维护一个nonce集合每个nonce只能用一次且时间戳偏差超过5分钟的请求直接拒绝。这样抓包之后重放的请求都会因为nonce重复被拦截。6.3 管理端后台异常签到的可视化处理做后台的目的不只是看数据更是要能快速处理异常。老师登录管理端后默认看到今日所有课程的签到汇总卡片每个卡片上有已到人数、异常人数、签到进度条。点进课程详情最上方是异常签到列表按风险分从高到低排序每条记录都有风险标签比如定位偏移异常设备不匹配签到耗时过短。老师可以一键标记为确认异常并通知辅导员也可以放行误判的记录。我还在后台加了一个全系签到热力图按教学楼展示各教室的签到率。上课十分钟后签到率还低于60%的教室会标红提示教务人员可以重点关注。这个功能虽然只是锦上添花但实际用下来老师们的反馈非常正向因为教学管理中最怕的就是不知道学生有没有来。7. 踩坑复盘安卓开发和Uniapp混合开发中的教训最后分享几个在开发中让我印象深刻的坑希望能帮你少走弯路。第一个是Uniapp调用原生插件的通信开销问题但要注意避免对返回大数据量JSON做频繁序列化。早期版本里我把WiFi扫描结果做成JSON字符串通过Uniapp的plus.android.importClass调用原生模块结果发现每次签到要等1到2秒才拿到结果用户体验很差。后来改成在原生侧完成数据采集和整理一次性把结果回传给业务层耗时降到300毫秒左右。第二个是安卓的MAC地址获取限制。安卓6.0之前可以通过WifiInfo.getMacAddress()拿到设备MAC地址用来做设备指纹识别但安卓6.0以上这个接口直接返回固定的02:00:00:00:00:00。后来我改用设备序列号加Android ID的组合生成设备指纹虽然不如MAC稳定但在现有体系下已经够用。第三个是混淆配置导致的诡异崩溃。上线前打混淆包结果同一个签到任务开发测试包能签正式包就闪退。排查了一下午发现是自定义插件的一个类被混淆了服务端下发数据时反射创建报错。明明是运行时错误编译期完全看不出来。从那以后我每次打新包都要完整跑一遍签到流程的冒烟测试再也不敢偷懒。第四个是关于定位权限的隐私合规。上架应用市场审核时对方要求说明收集定位信息的具体用途。我的反馈是写清楚定位信息仅用于考勤签到判断不存储位置轨迹不做用户画像同时要在隐私政策里申报这个权限。这里提醒一下最好在隐私政策里先写清楚不然审核被驳回再改会耽误上线时间。我个人的建议是如果你打算把这个系统用在几十个班的真实教学环境里不要一上来就做太复杂的功能先把发起签到-学生签到-查看统计这条主链路跑通验证稳定性和防作弊效果再加直播、弹窗提醒、积分奖励这些花活。签到系统的本质是约束和激励技术上做到位了用户体验和运营手段才是决定它能不能被长期用起来的关键。本文还有配套的精品资源点击获取