简介：这份文档面向高校学生、企业考勤管理者及Android蓝牙开发初学者，围绕“基于蓝牙技术的考勤系统”展开蓝牙通信设计，用于解决传统点名、指纹与刷脸考勤效率低、成本高、易代签等问题。资源为单个doc文档，压缩包约1.21MB，内容涵盖蓝牙技术基础、客户端BluetoothSocket与服务端BluetoothServerSocket的职责划分、蓝牙设备搜索与连接流程，以及蓝牙考勤系统的实现思路与优缺点分析。文档还讨论了蓝牙设备可靠性、安全性与互操作性等落地挑战，并给出相应设计考量，适合作为课程设计、毕业设计或企业考勤方案的技术参考。目前已有145人学习，读者可从中获取蓝牙通信模块的设计要点、签到APP的功能框架与问题排查方向，快速理解短距离自动考勤的完整实现逻辑。
1. 蓝牙考勤系统到底在解决什么问题
很多团队做考勤，第一反应是扫码、刷脸或者连 Wi-Fi 打卡。扫码能代打，刷脸有隐私顾虑，Wi-Fi 打卡又受限于网络覆盖和定位漂移。基于蓝牙技术的考勤系统，核心思路是把「人是否在场」这件事，交给一个近距离无线信号来判断——手机和考勤终端之间通过蓝牙完成一次握手，握手成功即视为到场。它解决的是「无感打卡」和「近距离约束」这两个矛盾需求：既不想让员工掏手机扫码，又不想让打卡变成远程操作。
这套方案适合谁？适合中小型办公场景、实验室、教室这类固定出入口、人数在几十到几百之间的场合。它不需要额外布线，考勤终端可以是一块带蓝牙的开发板，也可以是一台常驻的旧手机或平板。蓝牙通信设计是整个系统的咽喉，握手协议怎么定、信号强度怎么用、断连怎么处理，直接决定这套考勤是「能用」还是「天天被投诉」。下面从通信设计一路讲到落地排错。
2. 蓝牙通信设计：从角色划分到握手协议
2.1 先定角色：谁广播，谁扫描
蓝牙低功耗（BLE）有两种基本角色：广播者（Advertiser）和扫描者（Scanner）。考勤系统里最常见的做法是让考勤终端做广播者，手机做扫描者；或者反过来，手机广播、终端扫描。两种方向各有取舍。
终端广播、手机扫描的好处是终端功耗极低，一块纽扣电池能撑几个月，适合固定在墙上的考勤点。缺点是手机端要常驻一个扫描服务，对手机电量有影响，而且 Android 和 iOS 对后台扫描的限制越来越严。手机广播、终端扫描则相反，终端要一直开着扫描，功耗高，但手机端只需要在打卡时广播一小段时间，对用户更友好。
我一般会选终端广播、手机扫描，因为考勤终端通常有稳定供电，而手机端可以引导用户把打卡页面放在前台，规避后台扫描限制。角色定下来之后，广播包里放什么就成了关键。
2.2 广播包结构：把设备标识和校验塞进 31 字节
BLE 广播包的有效载荷最多 31 字节，去掉 Flags、设备名等固定字段，真正能自定义的空间往往只有 20 字节左右。考勤系统需要在这个空间里塞进设备标识和一点校验信息。
# 构造 BLE 广播数据（伪代码，基于常见 BLE 库的接口风格） import struct def build_adv_payload(device_id: int, nonce: int) -> bytes: # 前 2 字节：厂商自定义标识，避免和通用设备混淆 manufacturer_id = 0xFFFF # 设备标识用 2 字节，支持 65535 个考勤点 # nonce 用 4 字节，每次广播轮换，防止重放 payload = struct.pack('<H', manufacturer_id) payload += struct.pack('<H', device_id) payload += struct.pack('<I', nonce) # 剩余字节留空或放信号强度参考值 return payload这段代码的逻辑是：厂商自定义标识让手机端能快速过滤出考勤设备，设备标识区分不同考勤点，nonce 每次广播轮换，手机端上报时带上这个 nonce，服务端校验时效性。参数上，device_id 用 2 字节是权衡了考勤点数量和广播包空间，如果考勤点超过 65535 个，就得压缩其他字段。nonce 用 4 字节，配合 30 秒轮换一次，能挡住大部分重放攻击。
注意：广播包长度是硬约束，字段加多了要么截断要么广播失败，调试时先用抓包工具确认实际发出的字节数。
2.3 连接还是无连接：握手方式的选择
BLE 通信分两种：广播式（无连接）和连接式。考勤打卡这种「一次握手、快速完成」的场景，广播式通常就够了。手机扫描到广播包，解析出设备标识和 nonce，直接通过 HTTP 或 MQTT 上报给服务端，服务端校验 nonce 和时间戳，完成打卡。整个过程不需要建立 BLE 连接，延迟低，终端功耗也低。
连接式则适合需要双向确认的场景，比如终端要回传「打卡成功」的提示音或屏幕反馈。连接式的问题是每次连接要经历扫描、发起连接、服务发现、特征读写，耗时可能到几百毫秒甚至一秒以上，高峰期排队会很明显。
我的做法是：打卡动作走广播式，终端本地用 LED 或蜂鸣器做即时反馈，不依赖 BLE 回传。这样既快又稳，终端也不需要维护连接状态。
2.4 信号强度（RSSI）怎么用才不玄学
RSSI 是蓝牙通信设计里最容易被滥用的参数。很多人想用 RSSI 判断「人是不是真的在门口」，但 RSSI 受人体遮挡、手机握持方式、环境反射影响极大，同一位置波动十几 dBm 很正常。
比较务实的用法是设一个宽松阈值，比如 RSSI 大于 -80 dBm 才允许打卡，用来挡住「隔着几堵墙远程打卡」的极端情况，而不是用来精确测距。阈值设太严，正常站在门口的人也会被拒；设太松，又挡不住远程。我一般会先采集一批现场数据，看正常打卡时的 RSSI 分布，取一个覆盖 95% 正常样本的值作为阈值。
# 服务端校验 RSSI 的简单逻辑 RSSI_THRESHOLD = -80 # 单位 dBm，根据现场采集调整 def validate_rssi(rssi: int) -> bool: if rssi is None: return False # 只做粗筛，不做精确距离判断 return rssi >= RSSI_THRESHOLD这段代码的意图很明确：RSSI 只做粗筛，不做精确定位。参数 RSSI_THRESHOLD 需要现场标定，不同手机发射功率不同，最好按机型做一点补偿，但不要过度拟合。
3. 把考勤终端跑起来：最小可复现步骤
3.1 硬件选型与开发环境
考勤终端可以用常见的 BLE 开发板，比如带蓝牙功能的单片机开发板，也可以用一台常驻的旧手机跑一个广播 App。开发板方案更稳定，适合固定安装；旧手机方案上手快，适合验证阶段。
开发环境方面，如果选开发板，通常用厂商提供的 SDK，语言可能是 C 或 Python。如果选旧手机，Android 上可以用常见的 BLE 外设库，iOS 上也有对应的 CoreBluetooth 接口。下面以 Python 风格的伪代码演示终端广播逻辑，实际移植到开发板时替换成对应 SDK 的 API 即可。
3.2 终端广播的最小实现
# 考勤终端广播循环（伪代码） import time import random DEVICE_ID = 1001 # 本考勤点标识 ADV_INTERVAL_MS = 200 # 广播间隔，单位毫秒 NONCE_ROTATE_SEC = 30 # nonce 轮换周期 def rotate_nonce(): return random.randint(0, 0xFFFFFFFF) def main_loop(): nonce = rotate_nonce() last_rotate = time.time() while True: # 到时间就换 nonce if time.time() - last_rotate > NONCE_ROTATE_SEC: nonce = rotate_nonce() last_rotate = time.time() payload = build_adv_payload(DEVICE_ID, nonce) # 调用底层广播接口，不同 SDK 名称不同 ble_advertise(payload, interval_ms=ADV_INTERVAL_MS) time.sleep(ADV_INTERVAL_MS / 1000.0) if __name__ == '__main__': main_loop()逻辑说明：终端持续广播，每隔 30 秒换一次 nonce。广播间隔 200 毫秒是功耗和发现速度的折中，间隔越小手机越快扫到，但终端功耗越高。参数 ADV_INTERVAL_MS 可以根据终端供电情况调整，插电的终端可以设 100 毫秒，电池供电的可以放宽到 500 毫秒甚至 1 秒。
3.3 手机端扫描与上报
手机端要做的事：扫描广播包，过滤出考勤设备，解析 device_id 和 nonce，连同本机标识和 RSSI 一起上报服务端。
// 手机端扫描逻辑（伪代码，基于常见 BLE 接口风格） const DEVICE_ID_FILTER = 1001; function onScanResult(device) { const payload = parseManufacturerData(device.manufacturerData); if (!payload || payload.deviceId !== DEVICE_ID_FILTER) { return; } const report = { deviceId: payload.deviceId, nonce: payload.nonce, rssi: device.rssi, userToken: getLocalUserToken(), timestamp: Date.now() }; // 上报服务端，走 HTTPS submitAttendance(report); }逻辑说明：手机端只处理目标考勤点的广播，解析出 nonce 和 RSSI 后上报。userToken 是用户登录后拿到的凭证，服务端用它关联用户身份。timestamp 用手机本地时间，服务端会做时间窗口校验，防止旧包重放。
3.4 服务端校验与防重放
服务端收到上报后，要做几件事：校验 nonce 是否在有效期内、校验用户是否已打卡、校验 RSSI 是否达标、记录打卡结果。
-- 打卡记录表结构（简化） CREATE TABLE attendance_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, device_id INT NOT NULL, nonce BIGINT NOT NULL, rssi INT, report_time DATETIME NOT NULL, status TINYINT DEFAULT 1, UNIQUE KEY uk_user_device_day (user_id, device_id, report_time) );nonce 校验可以用缓存实现：终端每次轮换 nonce 时，服务端并不需要提前知道，而是校验上报的 nonce 对应的时间戳是否在允许窗口内。更简单的做法是终端广播里带一个粗粒度时间片，服务端只接受当前时间片和上一个时间片的 nonce。这样不需要终端和服务端时钟严格同步，也能挡住大部分重放。
4. 避坑与排查：蓝牙考勤最容易翻车的五个点
4.1 现象：高峰期大量打卡失败，提示扫描不到设备
原因通常是广播信道拥塞。BLE 广播在 37、38、39 三个信道上轮询，如果周围蓝牙设备太多，广播包碰撞概率上升，手机扫描窗口内收不到完整包。另一个可能是终端广播间隔太长，手机扫描窗口太短，两者错开。
解决：把终端广播间隔从 1 秒缩短到 200 毫秒以内，手机端扫描窗口设成连续扫描或长窗口短间隔。如果现场蓝牙设备极多，考虑把考勤点分散到不同物理位置，减少同频干扰。
4.2 现象：部分手机能打卡，部分手机死活扫不到
原因多半是手机系统对 BLE 扫描的限制。Android 不同版本对后台扫描、位置权限的要求不一样，iOS 对未声明用途的扫描会直接拒绝。另外，部分手机厂商的省电策略会在锁屏后杀掉扫描进程。
解决：引导用户在打卡时保持页面在前台，申请必要权限时说明用途。如果必须支持后台，Android 上考虑前台服务，iOS 上受限于系统策略，基本只能前台扫描。机型兼容性最好在项目早期就用目标机型列表实测一遍。
4.3 现象：RSSI 阈值调好后，过几天又开始误判
原因是环境变了。人体、金属门、新搬来的文件柜都会影响信号反射。RSSI 阈值不是一劳永逸的参数。
解决：把 RSSI 阈值做成可配置项，现场变动后重新采集数据调整。更稳妥的做法是不要单独依赖 RSSI，结合打卡时间规律、用户历史行为做二次判断，比如短时间内同一用户在不同考勤点上报就标记异常。
4.4 现象：nonce 校验偶尔失败，日志显示时间窗口不匹配
原因是终端和服务端时钟不同步，或者网络延迟导致上报时间戳偏差。如果 nonce 窗口设得太窄，正常打卡也会被拒。
解决：nonce 窗口至少留两个时间片，比如终端 30 秒轮换，服务端接受 90 秒内的 nonce。同时终端上报时带上自己的时间片编号，服务端以编号为准而不是以收到时间为准，减少网络延迟影响。
4.5 现象：打卡记录重复，同一用户同一时间出现多条
原因是手机端重复上报，或者用户快速多次触发打卡。广播式打卡没有连接确认，手机端可能因为重试机制重复提交。
解决：服务端用唯一索引兜底，比如 user_id + device_id + 时间片 做唯一约束。手机端上报前做本地去重，同一 nonce 只提交一次。重试机制要加退避，不要短时间密集重试。
5. 进阶技巧：让蓝牙考勤从能用变成好用
5.1 用多广播包做粗定位
单个广播包只能判断「在不在附近」，如果想区分「从哪个门进来」，可以让每个考勤点广播不同的 device_id，手机端同时扫描多个考勤点，取 RSSI 最强的那个作为打卡点。这样不需要精确测距，也能实现区域区分。
# 手机端选择最强信号考勤点 def pick_best_device(scan_results): valid = [r for r in scan_results if r.rssi >= RSSI_THRESHOLD] if not valid: return None # 按 RSSI 降序，取最强 return sorted(valid, key=lambda x: x.rssi, reverse=True)[0]这个逻辑适合出入口相邻的场景，比如前台和侧门离得很近，用最强信号判断用户实际靠近哪个点。参数上，RSSI_THRESHOLD 仍然只做粗筛，排序用原始 RSSI 值。
5.2 打卡成功率的上报与监控
蓝牙考勤最怕的是「用户说打了，系统说没打」。要解决这个扯皮，手机端每次打卡无论成功失败都上报一条日志，服务端统计每个考勤点的成功率。成功率突然下降，往往是终端广播异常或环境干扰，能提前发现而不是等投诉。
监控指标建议看三个：扫描到设备的比例、上报成功的比例、服务端校验通过的比例。三个比例逐级下降，能快速定位是扫描问题、网络问题还是校验问题。
5.3 终端固件的远程配置
考勤终端装到墙上之后，改广播间隔、改 device_id 都很麻烦。如果终端支持远程配置，比如通过服务端下发参数，维护成本会低很多。简单做法是终端定期拉取配置接口，或者通过广播包里的保留字段传递配置版本号，手机端上报时顺带把版本号带给服务端，服务端发现版本不对就提示管理员。
5.4 一个我踩过的坑：别把 nonce 做成全局递增
早期版本我用全局递增计数器做 nonce，终端重启后计数器归零，服务端以为是旧包直接拒绝。后来改成时间片加随机数，终端重启也不影响。这个坑的血泪经验是：任何和「顺序」相关的字段，都要考虑设备重启、时钟回拨、多终端并发的情况，别假设单机顺序执行。
5.5 验证方法：用抓包工具看真实广播
调试蓝牙通信，最可靠的手段是抓包。用支持 BLE 抓包的设备或手机上的调试 App，直接看终端发出的广播包内容，确认 device_id、nonce、长度是否符合预期。很多「代码没问题但就是不通」的情况，抓一次包就真相大白。
我现在的习惯是：任何蓝牙相关的改动，先在抓包工具里确认广播包正确，再去看手机端解析和服务端校验。这样能把问题范围快速缩小到某一层，不用在整条链路上瞎猜。希望帮到你。
本文还有配套的精品资源，点击获取
