简介本资源是一套完整的Android端人脸识别GPS定位签到系统实战项目面向移动开发初学者与中级工程师解决企业考勤、会议签到、教学点名等场景中身份核验与地理围栏双重验证需求。压缩包共5个文件含Android客户端源码StudentAttendenceSystem.zip、PHP后台服务代码、MySQL数据库脚本student_atendence_data.sql、系统部署说明readme.txt及全流程演示视频mp4总大小312.16MB结构清晰前后端分离明确。已有508人学习下载涵盖管理员任务发布/用户管理/公告推送与普通用户人脸注册对接百度云AI、扫码定位双因子签到、请假申请等核心功能模块。读者可直接部署运行深入理解Android Camera API调用、百度人脸识别SDK集成、GPS权限与位置校验逻辑、RESTful接口设计及前后端数据交互全流程。 最近帮一个学弟搭建人脸识别定位签到App顺带把源码整理了出来。他发现市面上的签到方案基本是两类要么只有GPS定位打卡要么用蓝牙/NFC碰一碰但都没法解决“人到底在不在手机前”的问题。我给他的建议很简单——把Android原生的人脸识别和定位能力结合起来做一个真正的“人位置”双重校验签到系统。这篇文章就把这个项目的完整实现路径拆开讲从整体架构到人脸识别和定位的具体接入方案再到后台数据闭环的设计和最终交付演示视频的录制要点都会给出可以直接复用的经验。无论你是正在做毕业设计、想在公司内部做个小工具还是单纯想练手Android开发这套方案都能作为不错的起点。项目本身是完整的源码演示视频所以你可以直接对照代码看这一篇的思路。1. 项目整体架构为什么“人脸定位”才是签到App的核心1.1 核心需求解析标题里的技术栈是“Android、人脸识别、定位、签到App”但真正决定一个签到产品能不能落地的是两件事一是如何确认签到者是本人二是如何确认本人在指定位置。传统的GPS定位只能拿到手机的位置无法确认与使用者的一致性而单纯的人脸识别只能证明“脸对了”但没法证明人不在外地的家中。所以这个项目的定位很清晰用活体检测人脸比对完成身份确认用基地位于地图SDK的定位能力完成位置判定两端通过服务端做联合校验。这也是目前主流考勤类App的通用逻辑做学生项目或者公司内训演示都足够具备参考价值。从技术结构上看整个项目可以拆成下面几个模块Android客户端负责UI交互、摄像头调用、人脸识别逻辑、定位采集。本地特征库注册阶段录入的人脸特征数据存储于本地或服务端数据库。后端服务接收人脸比对结果和定位数据进行距离计算和签到记录写入。管理端/查看端用于查询签到记录、导出考勤列表可以是Web页面也可以是App内嵌页面。我这份源码里客户端用的是Android Studio项目结构后端使用简约的Spring Boot服务数据库用MySQL。如果你不需要后端也可以把结果记录在SQLite或Room里但那样做的话“定位人脸”的联合校验就少了一个集中的数据出口本质上还是单机Demo。1.2 为什么选择Android原生开发而不是跨平台方案人脸识别环节涉及大量摄像头帧数据的实时处理而且Android自带的CameraX FaceDetector接口在原生环境下调用最顺畅。如果选用Flutter或React Native虽然UI跨端方便但人脸识别的Native层桥接反而会带来额外复杂度。最终选择原生Java/Kotlin还有一个原因定位SDK高德或百度在原生工程中的集成文档最齐全遇到启动崩溃、坐标偏差异常这些问题时能找到的排查经验也最多。对于教学演示来说稳定比炫技重要得多。1.3 功能模块与目录结构速览源码里的包结构大致如下阅读时可以按这个索引快速找到对应模块模块包名/路径主要职责启动页/权限申请activity.SplashActivity首启权限校验、引导注册模块activity.RegisterActivity采集人脸图像、录入特征登录/签到activity.SignActivity调起摄像头、定位、提交记录定位工具utils.LocationHelper封装高德/百度定位SDK人脸识别引擎engine.FaceEngine封装OpenCV / 系统API检测与比对网络层network.HttpClient提交到后端接口数据库db.AppDatabase本地留存签到记录这个结构的特点在于“每类功能一个入口”对新手来说想改哪个部分就去对应的包里找不会在一堆Activity里迷路。2. 人脸识别模块从照片采集到活体检测的完整链路2.1 人脸数据的采集要点很多人一开始做人脸签到直接用手机后置摄像头咔嚓一下结果入库的照片质量参差不齐导致后续识别率惨不忍睹。实际上注册阶段的人脸照片质量决定了大半识别成功率。我在这个项目里采集逻辑做了三个约束使用前置摄像头要求用户正对镜头保持面部在圆形取景框内。加入简单的清晰度判断通过OpenCV的Laplacian算子计算图像方差低于阈值就要求重拍。要求眨眼或张口动作触发两帧不同表情的图像检查防止直接用照片翻拍注册。代码上核心逻辑如下// 基于OpenCV的模糊检测 public boolean isFaceImageSharp(Mat src) { Mat gray new Mat(); Imgproc.cvtColor(src, gray, Imgproc.COLOR_RGBA2GRAY); Mat laplacian new Mat(); Imgproc.Laplacian(gray, laplacian, CvType.CV_16S); Mat abs new Mat(); Core.convertScaleAbs(laplacian, abs); Scalar mean Core.mean(abs); return mean.val[0] 80; // 阈值根据实际摄像头调整 }2.2 人脸比对的两种实现路线项目中写了两套比对方案方便根据实际场景切换。方案一Android系统自带FaceDetector示例、轻量Android的FaceDetector类支持检测眼睛和嘴巴的位置在API 21以上可用但它的局限是没有内建特征比对接口若只靠它做“同一人判断”基本不可行。所以这套方案我主要用于“画面中是否有人脸”“脸部姿态是否偏转”这些前置判断。方案二OpenCV人脸识别主推使用OpenCV的LBPHLocal Binary Pattern Histogram算法。流程是从图片中检测人脸区域使用Haar Cascade分类器裁剪并转为灰度图。归一化到固定尺寸例如200x200。调用LBPH模型的predict()方法得到与已注册人脸的置信度分数。// JNI层关键的比对代码 int label model-predict(gray_img, confidence); // confidence 值越小表示相似度越高通常 60 视为同一个人置信度阈值在项目中设为70这个值不是随便定的。实践测试中同一人不同光照的置信度通常在45-65之间不同人则在100以上。但要注意LBPH对光照敏感所以签到页面我会强制开启闪光灯或要求用户到光线充足区域并且在预处理阶段加了一步直方图均衡化能在很大程度上抵消光照差异。2.3 活体检测的轻量实现和进阶思路人脸识别最怕的就是“照片就能解锁”。我在这套源码里内置了一个简单但实用的活体检测逻辑随机要求用户眨眼或者左右摇头基于前置摄像头连续帧判断。具体实现不需要太炫技用TFLite的MobileNet加上一个简单的情感/动作分类模型或者直接用MediaPipe的Face Mesh检测特征点变化即可。我的源码里用的是较易上手的MediaPipe方案特征点68点位变化里眨眼会体现为上下眼皮间距骤减摇头会体现为鼻尖点的横向位移。在测试时要注意一个点必须在“动作发起后”才截取后续帧比对而不是提前几秒采集否则活体检测环节形同虚设。用我代码里的FaceActionDetector类建议先看一下它的事件回调时序。提示如果你只是为了演示Demo不会真正抵御恶意攻击但到了生产环境建议直接用商用SDK如Face或百度AI的活体接口毕竟自研活体检测涉及模型训练和设备适配成本并不低。2.4 识别过程实战中的几个坑人脸识别这部分我在调试里踩过几个比较典型的坑建议提前避开摄像头预览方向前置摄像头在后置横屏时容易出现镜像注册时人脸显示方向正常但识别时翻转导致特征比对失败。需要在CameraX里配置setTargetRotation(Surface.ROTATION_90)或者在后处理时统一旋转到固定方向。内存溢出CameraX的ImageAnalysis.Analyzer回调频率很高如果每一帧都做OCR、人脸检测、保存Bitmap很容易OOM。解决方法是设置setBackpressureStrategy(STRATEGY_KEEP_ONLY_LATEST)并且只对每一秒中的关键帧做完整检测。模型文件路径问题OpenCV的Haar Cascade文件和LBPH模型文件如果放在assets目录加载时不能直接传/assets/路径给C层要先复制到App的私有目录getFilesDir()再加载。源码中封装了FileUtils.copyAssetsToFiles()建议优先看这里。3. 定位模块坐标采集、模拟检测与签到范围判定3.1 定位SDK的选型与配置市面上的Android定位方案基本瞄准高德、百度、腾讯三家。这个项目源码里用的是高德定位SDK主要原因国内地图应用最普及逆地理编码和坐标转换工具最完善而且离线定位配合网络定位的吞吐表现也不错。在build.gradle中需要引入implementation com.amap.api:location:6.4.1AndroidManifest.xml中要申请权限uses-permission android:nameandroid.permission.ACCESS_COARSE_LOCATION / uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION / uses-permission android:nameandroid.permission.INTERNET / uses-permission android:nameandroid.permission.ACCESS_WIFI_STATE /提醒一下Android 10以上的“仅为一次”定位权限模式如果用户关闭了权限持久化允许App可能会在后台定位时出现失败。这个项目定位是前台签到场景所以不涉及后台持续定位问题不大。但如果你要扩展到“连续轨迹监控”那得单独适配前台Service。3.2 签到场景下定位精度的取舍做签到App的时候定位精度并不是越高越好反而因为精度抖动会导致误判。室外GPS能到5米但室内Wi-Fi定位可能直接漂到上百米。所以这里需要定义一个有效签到半径。我的源码里定义的是管理员在后台设置一个中心点经纬度例如公司前台位置学生或员工的当次定位点到该中心点的距离必须小于设定半径默认300米才认为签到有效。距离计算用球面距离公式而不是简单的欧几里得距离因为经纬度坐标下直接用平面距离会严重失真。源码中计算逻辑如下fun calculateDistance(lat1: Double, lon1: Double, lat2: Double, lon2: Double): Double { val R 6371000.0 val dLat Math.toRadians(lat2 - lat1) val dLon Math.toRadians(lon2 - lon1) val a Math.sin(dLat / 2) * Math.sin(dLat / 2) Math.cos(Math.toRadians(lat1)) * Math.cos(Math.toRadians(lat2)) * Math.sin(dLon / 2) * Math.sin(dLon / 2) val c 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a)) return R * c }实测中我发现一个问题**在室内靠近窗户的位置GPS漂移经常超过100米而Wi-Fi定位的误差反而能稳定在20-50米。**所以签到App的网络定位不可全关。源码里配置了GPS优先、网络补偿的混合策略调用AMapLocationClientOption.setLocationMode(LocationMode.Hight_Accuracy)。3.3 如何检测模拟定位这个需求几乎是每个签到App都逃不过的。源码里至少做了四层基础防护检查定位来源高德SDK返回的AMapLocation.getLocationType()若是固定值LOCATION_TYPE_GPS且海拔/速度均为空要标记可疑。检测开发者选项通过Settings.Secure.isLocationProviderEnabled或者反射读取Settings.Global.ALLOW_MOCK_LOCATION尝试读一下当前系统是否允许模拟位置。不过Android 6.0以上被限制读取需要额外手段。坐标漂移检测模拟定位的坐标往往长时间不动或瞬移可以通过连续两次定位的时间间隔和距离差若超过物理合理的速度如60秒内从北京到上海判定异常。位置与IP辅助后端同时记录IP归属地解析结果跟设备定位坐标做粗粒度匹配。不同运营商基站定位和IP解析结果差异很大这个匹配只做辅助不做一票否决。源码中的AntiMockLocationHelper把上述逻辑集中在了一起返回一个RiskLevel枚举NORMAL、SUSPICIOUS、HIGH_RISK。后端收到数据后会根据风险等级决定是否将记录标红。3.4 定位权限和后台限制的适配Android 11之后系统在后台访问定位权限时会弹窗而且小米、华为等厂商还有各自的省电策略会强杀App的后台定位请求。这套源码的签到场景是用户主动点击“签到”此时App处于前台所以只需要处理前台权限的运行时申请。但如果你后期想让App支持“自动打卡”就得留意Android的Geofencing地理围栏接口它可以在不进后台的轻量场景下回调位置是比死保后台Service更优雅的方案。源码里预留了Geofencing的接口位置但默认未开启原因是不想让演示流程变复杂。4. 服务端与数据闭环签到记录怎么才能真正“可追溯”4.1 接口结构设计很多初学同学只看客户端但一个真正能交付的签到项目后端至少需要三类接口接口方法请求参数返回值/registerPOST用户名、人脸特征向量、设备ID注册结果/signPOST用户ID、坐标、人脸比对分数、活体检测结果、时间戳签到结果成功/失败/异常/recordsGET用户ID/日期范围签到记录列表在后端部分我特意设计了“服务端二次校验”的逻辑。客户端的坐标、人脸比对结果只能看作“采集数据”最终判断都由后端完成是否在允许的时间窗口内该用户是否已经签到过该时段防止重复签到。坐标距离是否在有效范围内人脸置信度和活体得分是否同时达标这种方式的好处是客户端代码即使被篡改后台仍然保留最终决定权签到数据才有追溯意义。4.2 数据库表设计思路数据库使用MySQL最基本的表结构如下CREATE TABLE sign_record ( id INT AUTO_INCREMENT PRIMARY KEY, user_id VARCHAR(64) NOT NULL, sign_time DATETIME NOT NULL, latitude DECIMAL(10, 6) NOT NULL, longitude DECIMAL(10, 6) NOT NULL, face_score DOUBLE NOT NULL, is_live TINYINT NOT NULL DEFAULT 0, is_mock_location TINYINT NOT NULL DEFAULT 0, risk_level VARCHAR(16) DEFAULT NORMAL, device_id VARCHAR(64), remark VARCHAR(255) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有一个容易被忽略的细节经纬度不要用FLOAT而要用DECIMAL否则高精度坐标在存储时会被四舍五入导致距离计算得出错误结论。另外给user_id sign_time做联合索引因为查询考勤时最常用的筛选条件就是“某个人某个时间段”。4.3 前后端联调中的常见问题我调试时遇到过几个很有代表性的问题列出来供参考签名错误类如果后端配置了Token校验客户端每次请求都要在Header里带上Authorization。初学者常常只在登录时请求了Token后续访问其他接口未传服务端返回401前端又不提示结果看起来像“签到不成功”。时间戳时区问题后端服务器默认是UTC但客户端经JSON传输的时间可能是2024-01-01T12:00:00没有指定时区转换后差了8小时。在前后端协议里统一使用long毫秒时间戳或统一约定ISO 8601带时区格式可以避免这个坑。图片传输体积问题有些人脸信息是通过Base64上传的一张2MB的照片Base64之后约2.7MB在弱网环境下传输非常慢还容易超时。建议上传前压缩或者只上传人脸特征向量如128维float数组而不是整张图片。我的源码里默认上传的是特征向量注册照只在后台展示时使用。4.4 本地数据库的兜底作用我的源码还保留了一条本地记录逻辑当网络不可用或后端请求超时时签到结果先暂存本地Room等网络恢复后自动补传。这在演示时特别有用——即使现场断网也能先跑通流程再展示“补传成功”的能力。但注意本地缓存的数据要加上“待同步”标识不能让用户反复修改。每次补传前要向后端询问该时间戳是否已存在防止重复记录。5. 演示视频录制、源码自学路径与可能的扩展方向5.1 演示视频录制需要注意的点和录制脚本对于“源码演示视频”这种交付形式视频质量直接影响观感和技术说服力。我从录制的角度给你一份实际可用的脚本展示工程结构10秒用Android Studio打开项目展示包结构和关键类。注册演示20秒打开App输入用户名正对摄像头录入人脸展示注册成功Toast。定位签到30秒打开签到页点击按钮展示定位符号流转圈、人脸识别框出现、结果弹出。异常情况演示20秒换一个人来刷脸展示“人脸不匹配”的失败提示或者用模拟定位App打开后签到展示“定位高风险”警示。后台记录展示20秒打开网页管理端查看刚才的签到记录展示经纬度、分值和状态。整个视频尽量控制在2分钟以内因为平台上长视频的完播率会显著下降。录制时使用Android Studio自带的Screen Recording可以同时录到LogCat输出让代码运行日志和画面同步显示更有说服力。注意有些平台会压缩视频清晰度如果你录制时手机屏幕分辨率是2K导出时建议保持原始分辨率或者至少1080P以上。人脸识别画面一旦模糊观看者会立刻怀疑识别效果。5.2 源码阅读路线和建议如果在拿到源码后想从头理解建议按下列顺序读代码而不是来回乱翻README.md和数据库脚本先看部署步骤和环境依赖。FaceEngine类包含人脸检测的核心流程涉及OpenCV模型加载和预测。LocationHelper类看定位模式配置、回调处理。SignActivity把上面两者串起来理解签到交互逻辑。服务端Controller层看接收参数和校验逻辑理解“双重校验”到底校验了什么。阅读时建议时刻问自己一个问题“如果我是后端开发我该怎么验证这个坐标是不是伪造的”带着安全视角去看代码才能真正理解为什么某些方法要存在。5.3 项目扩展方向源码本身是一个完整基座再往下走你可以按自己需求做这些扩展签到报表导出后端增加/export接口导出Excel配套ECharts图展示每日出勤率。多人组队签到增加“班组”概念一次签到全员生效适合工地或巡检场景。地理围栏自动签到结合Geofencing进入区域后自动拉起签到页减少手动操作。人脸活体升级集成商用SDK可支持随机动作、光线活体将安全等级提升一个档次。离线模式将人脸模型移植到端侧支持在无网络环境下签到后续再同步数据适合偏远地区或现场网络不稳定的场景。我在实际运行这个项目的过程中最深的体会有两点一是人脸识别不能只看“能不能识别”还要看“能不能稳定持续识别”否则一次Demo跑通换个环境就翻车二是定位签到项目一定要想清楚“如果有人恶意作弊我靠什么发现”哪怕只做基础层的模拟定位检测也能在展示中明显拉开与其他方案的差距。5.4 最后补充一个在线演示环境建议如果你想把演示视频录得更有说服力建议准备一台Android真机而不是模拟器。模拟器虽然方便但有两处硬伤一是模拟器的人脸检测可能调用主摄像头失败二是模拟器的定位SDK经常返回默认坐标无法演示“距离判定”。真机调试时建议在开发者选项里把“不锁定屏幕”打开防止录制中途熄屏。定位相关的权限弹窗要提前允许因为录制中如果弹出系统对话框演示节奏会被打断。最好准备一张实体SIM卡有些定位算法在无SIM卡状态下会降低网络定位精度导致与实际位置偏差增大。这套项目如果你只是想要交作业或理解流程跟着源码跑通Demo足够如果你希望它变成真正可部署的考勤系统还需要加上管理后台的用户管理、部门管理、排班规则等功能。不过“人脸定位”的双重校验核心就是这套源码的骨架后续迭代万变不离其宗。本文还有配套的精品资源点击获取