简介面向手机使用检测、行为分析与使用习惯研究场景这份zip资料包提供了一套从数据集、训练权重到PyQt5可视化界面的完整流程适合计算机视觉学习者、算法工程师以及关注用户行为分析的开发人员。包内共2000个文件以1980个txt标注文件为核心对应YOLO格式的目标检测标签另有1个yaml配置文件可直接用于YOLOv5、v8、v9、v10、v11、v12等算法训练搭配18个md说明文档和1个pdf便于快速理解目录结构、数据划分与训练流程。数据集已按train、val、test划分类别为phone手机同时提供训练好的模型与PyQt5可视化界面可实时展示手机使用检测结果辅助完成使用习惯统计与行为分析压缩包整体约345.16MB包含使用教程与完整工程文件。目前已有35人学习下载适合需要快速搭建手机检测演示项目或开展行为分析研究的读者。1. 手机使用检测不是换模型比赛这份 yolov13PyQt5 资源到底能解决什么做手机使用检测的团队十个里有七个把精力耗在换模型上最后发现准确率上不去的原因是 label 没标干净或者标签格式不统一。这份资源不是丢给你一个训练好的权重就说完了而是一整套能直接跑的工作流YOLO 格式和 VOC 格式双份标签、已经划分好的 train/val/test 数据集、写好的 data.yaml、训练好的模型以及一个 PyQt5 可视化界面检测目标只有一个——phone。适合谁用做课堂专注度分析、工位行为审计、门店服务规范检查或者想把摄像头里的手机使用行为沉淀成统计报表的开发者。它能让你省掉从标注到训练再到界面联调的大部分体力活直接站在已跑通的基线上改自己的业务逻辑。2. 数据集是训练的地基先看清 YOLO 标签和 VOC 标签的坑2.1 解压后的目录结构与 data.yaml 解读拿到压缩包先别急着跑训练第一步是把目录结构摸清楚。一份能直接喂给 YOLO 的数据集目录组成是有固定套路的这套资源里常见的是 images、labels、Annotations 三个核心目录加一个 data.yaml。images 放原始图片labels 是 YOLO 需要的 txt 标签Annotations 是 VOC 风格的 xml 标签data.yaml 则负责告诉训练脚本「图片在哪、标签是哪几类」。路径内容说明images/train、images/val、images/test原始图像按划分好的子目录存放labels/train、labels/val、labels/testYOLO 格式 txt 标签每行一个目标class_id x_center y_center w hAnnotationsVOC 格式 xml 标签和 images 一一对应含 bndbox 坐标data.yaml数据集配置声明路径、类别数 nc、类别名weights/ 或 runs/训练好的权重一般是 best.ptdata.yaml 我建议你拿到手先打开看一眼这是排查训练异常的第一道关卡path: dataset/ train: images/train val: images/val test: images/test nc: 1 names: 0: phone这个配置最容易被改坏的就是 path。很多人在自己机器上把 dataset 文件夹挪了位置忘了同步改 path训练时直接报找不到图片。另一个注意点是 yolov5 的老版本对 train/val 写法比较宽容但 ultralytics 的新版本要求路径相对于 path 解析所以建议写成相对路径而不是绝对路径。names 从 0 开始编号如果 xml 里的类名和这里不一致转换时就会漏掉目标。2.2 YOLO 格式和 VOC 格式怎么互转从 XML 到 TXT 的脚本资源里同时给了两套标签相当于做了一次双保险。但如果你打算用自己的标注工具重新补一批数据大概率只会产出一种格式。常见做法是标注工具导出 VOC xml再写脚本转成 YOLO txt。我一般会用一个这样的小脚本核心逻辑几十行就够了import xml.etree.ElementTree as ET def voc_to_yolo(xml_path, out_path, class_names): tree ET.parse(xml_path) root tree.getroot() w int(root.find(size/width).text) h int(root.find(size/height).text) lines [] for obj in root.iter(object): cls obj.find(name).text if cls not in class_names: continue cls_id class_names.index(cls) box obj.find(bndbox) xmin float(box.find(xmin).text) ymin float(box.find(ymin).text) xmax float(box.find(xmax).text) ymax float(box.find(ymax).text) x_center (xmin xmax) / 2.0 / w y_center (ymin ymax) / 2.0 / h bw (xmax - xmin) / w bh (ymax - ymin) / h lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {bw:.6f} {bh:.6f}) with open(out_path, w, encodingutf-8) as f: f.write(\n.join(lines)) class_names [phone] voc_to_yolo(Annotations/0001.xml, labels/0001.txt, class_names)三个点必须说清楚。第一图片宽高要从 size 节点取不要自己猜不然归一化坐标全错。第二x_center 和 y_center 必须除以图片宽高而不是除以标注框的宽高单位搞错以后训练时 loss 大概率变成 nan。第三每一行是一个目标的完整信息目标之间换行分隔格式是 class_id 加四个浮点数多一个空格少一个空格一般没事但类名和编号对不上就会出大问题。转换完以后强烈建议随手做个边界检查。YOLO 的坐标是归一化到 0-1 之间的如果发现某个值大于 1 或者小于 0十有八九是图片分辨率读取错了或者是标注框越界了。这种脏数据不会让训练直接崩溃但会让模型在验证集上莫名其妙掉点属于最难排查的隐形炸弹。2.3 train/val/test 划分的边界为什么随机拆分会漏检很多做目标检测的人对划分这件事很随意直接 random split 一把梭。但手机使用检测这种场景数据往往来自连续拍摄的视频抽帧。同一个视频片段里手机的角度、光线、背景几乎没变化如果随机划分train 和 val 里会出现大量「孪生兄弟」般的相似帧看起来验证集指标很好看一放到真实摄像头画面里立刻现原形。正确的划分维度是按视频片段或者按时间段划分而不是按单帧随机分。这套资源里已经帮你划分好了所以直接拿来用就好。但如果你后续要往里面加自己的数据请记住一个原则宁可 train 少一点也要保证 val 和 test 里的场景在训练时完全没见过。这也是检测类项目翻车率最高的一个环节很多人口中的「模型泛化能力差」本质上不是模型问题而是数据划分泄漏了。3. 跑通训练全流程从 data.yaml 到权重文件的参数取舍3.1 环境准备torch 版本、显卡驱动与项目文件的对应训练之前先对环境做一次体检这一步能替你挡掉绝大多数兼容性玄学。资源里说得很明白data.yaml 可以直接用于 yolov5、v8、v9、v10、v11、v12 甚至标题里对应的新版本训练因为它们用的都是同一套 YOLO 标签格式。但不同训练框架对 PyTorch 版本的要求不一样我一般按下面这张表来配环境框架PythonPyTorchCUDA备注yolov5 官方仓库3.8-3.101.13/2.011.7/11.8用 train.py 启动ultralyticsv83.8-3.112.0/2.112.1新版本默认用 yolo 命令启动labelme PyQt5 标注端3.8-3.10无要求无要求和训练环境最好分开如果你电脑上已经有多个 Python 环境我强烈建议训练和标注分离。因为 PyQt5 在 Python 3.11 上的依赖解析偶尔会闹脾气而训练脚本对 PyTorch 版本有硬性要求两者混在同一个环境里容易互相踩脚。Pycharm 里新建项目时单独指定虚拟环境解释器这种基础操作能省掉后面大量「莫名其妙 import 失败」的排查时间。3.2 训练命令与参数语义从 batch-size 到 epochs 的取舍环境配好以后训练本身反而不复杂。yolov5 的老玩家习惯用 train.pyultralytics 新系列用 yolo 命令。两者读同一份 data.yaml只是参数名略有差异。# yolov5 官方仓库风格 python train.py --data data.yaml --weights yolov5s.pt \ --img 640 --epochs 100 --batch-size 16 --device 0 # ultralytics 风格v8 到新版本统一入口 yolo train datadata.yaml modelyolo11n.pt \ epochs100 batch16 imgsz640 device0参数含义逐个说。--img 或 imgsz 是训练分辨率640 是默认值如果你用 mobile 端部署可以降到 416速度换精度但数据集标注时框如果太小降分辨率会损失小目标。--epochs 不是越大越好检测模型一般 100 轮足够收敛单类目标的手机检测任务通常 50 轮就能看出效果后面是边际收益递减。--batch-size 取决于显存16 这个值在 8GB 显卡上配 640 分辨率刚好显存不够就调到 8 或 4不要硬刚。device 0 表示第一块 GPU没有 GPU 就 device cpu但训练速度会慢到你怀疑人生。还有一个常被忽略的参数是 --workers。在 Windows 上这个值设太高容易报 DataLoader worker 崩溃我一般设 2 或者干脆不设。数据读取速度确实会慢一点但换来的是训练过程不被打断算下来更省事。3.3 断点续训与早停策略不浪费算力的习惯训练不是一次跑完就万事大吉中间断电、显存爆掉、手滑关掉终端都是家常便饭。yolo 系列的设计早就考虑到了这一点last.pt 就是给你留的后悔药。# 从最近一次中断的地方继续跑 yolo train resume modelruns/detect/train/weights/last.pt # 或者 yolov5 的写法指定 last.pt 并加 --resume python train.py --data data.yaml --weights runs/exp/weights/last.pt --resume断点续训的原理是训练过程中每个 epoch 结束都会保存 last.pt 和 best.ptlast.pt 包含当前权重、优化器状态、epoch 数和学习率调度器状态。所以 resume 以后能无缝接上不需要重新热身。早停则是另一种省算力的手段在 ultralytics 里可以直接在训练参数里加from ultralytics import YOLO model YOLO(yolo11n.pt) model.train(datadata.yaml, epochs100, patience10)patience10 的含义是如果连续 10 个 epoch 验证集的 mAP 没有任何提升训练自动提前结束用 best.pt 作为最终产物。手机检测这种单类任务一般 30-50 轮就到平台期了早停能帮你少跑一半无用功。我第一次跑这种任务时傻乎乎设了 300 epochs 全跑完回头看看前 80 轮之后的曲线已经平得像一条直线。3.4 用训练好的模型做验证与导出训练收工后先别急着接 PyQt5用命令行做一次「裸检」确认模型没训练偏。比如随便抽一张 test 目录里的图跑一次推理# ultralytics 预测命令 yolo predict modelruns/detect/train/weights/best.pt \ sourcedataset/images/test/0001.jpg conf0.25 # 导出 onnx 方便后续部署 yolo export modelbest.pt formatonnx opset12预测命令里 conf0.25 是置信度阈值低于这个值的框会被过滤掉。手机检测场景里0.25 是个比较宽松的阈值适合看模型潜力实际界面里用 0.4-0.5 更合适能有效减少误检。导出 onnx 时 opset12 是因为有些推理框架对高版本 opset 支持不完整导出时固定到 12 能避开不少兼容性坑。导出完成以后这个 best.pt 就是要喂给 PyQt5 界面的核心资产。4. PyQt5 可视化界面把单帧检测变成手机使用行为统计4.1 界面功能与线程模型为什么实时检测会卡死这套资源里最容易被低估的是那个 PyQt5 可视化界面。很多人拿到手第一反应是「这不就是个带摄像头画面的检测 demo 嘛」但真正跑起来才会发现线程模型才决定它能不能长时间稳定运行。PyQt5 的 GUI 事件循环跑在主线程如果直接把 OpenCV 的 cap.read() 和模型推理塞进主线程画面会一卡一卡甚至整个窗口无响应因为视频读取是阻塞操作一帧一秒都得等。正确的做法是把摄像头读取、模型推理放进 QThread 后台线程主线程只负责把结果画到界面上。线程之间通过 signal 传数据这就是 PyQt5 检测界面的标准骨架。如果你在 PyCharm 里自己设计界面记住一个原则主线程里永远不要出现 while 死循环和 time.sleep否则窗口必然假死。4.2 摄像头实时检测的核心代码骨架一个能扛住长时间运行的检测线程代码量其实不大。我通常把这块抽成独立的 DetectWorker 类避免和主界面代码纠缠在一起import cv2 from PyQt5.QtCore import QThread, pyqtSignal from ultralytics import YOLO class DetectWorker(QThread): frame_ready pyqtSignal(object) result_ready pyqtSignal(object) def __init__(self, source, weightsbest.pt): super().__init__() self.source source self.model YOLO(weights) self.running True def run(self): cap cv2.VideoCapture(self.source) if not cap.isOpened(): return cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FPS, 15) while self.running: ret, frame cap.read() if not ret: break results self.model(frame, conf0.4, verboseFalse) self.frame_ready.emit(cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)) self.result_ready.emit(results) cap.release() def stop(self): self.running False self.wait()frame_ready 和 result_ready 两个信号分别把画面和推理结果发给主界面主界面的槽函数只需要做两件事把 RGB 帧转成 QImage 显示到 QLabel把 results 的框画上去。注意我在信号里发送之前先把 BGR 转成了 RGB因为 QImage 默认按 RGB 解析很多人第一个画面出现颜色偏蓝就是在这一步漏了转换。cap.set(cv2.CAP_PROP_FPS, 15) 这行很多人不知道它把摄像头的输出帧率限到了 15fps。手机检测这种场景不需要高帧率限流以后 CPU 占用和发热会明显下降界面反而显得更流畅。conf0.4 是检测置信度阈值前面说过 0.4-0.5 是生产环境比较稳妥的范围。最后一行的 wait() 是确保线程真正退出后再释放资源否则下次启动时可能出现摄像头被占用打不开的问题。4.3 行为和使用习惯的量化统计从框到报表如果只是把检测框画在画面上那跟普通 demo 没区别。这套资源真正的价值在于「行为分析和使用习惯研究」也就是说检测结果要被累积、被统计、被量化。单帧的检测结果只是一堆坐标但当你有连续时间轴上的检测序列时就能回答几个有价值的问题这个人在摄像头前有多少时间在看手机哪个时间段使用频率最高连续使用最长持续多久把这些统计逻辑做成一个简单的数据记录器我一般会在 DetectWorker 里同时维护一个计数器把每帧是否检测到 phone 以及当前时间戳记录下来。跑完一段视频后输出一张 CSV 表而不是只显示在界面上。后面第 6 章我会专门给这个统计逻辑写一段可用的代码这里先记住一个核心概念帧率和时间戳必须成对记录缺了任何一个统计出来的时长都是不可信的。5. 避坑与常见问题排查从 labelme 装不上到界面假死5.1 labelme 安装报 pyqt5 依赖冲突现象在干净环境里执行 pip install labelme报错提示无法安装 pyqt5 或 pyqt5-sip有时候还会蹦出一大段版本冲突的红字警告看起来像整个环境被搞坏了。原因labelme 的依赖声明里要求 PyQt5而新版 PyQt5 又会自动拉起 pyqt5-sip在 Python 3.10 以上的环境里pip 的依赖解析器偶尔会给出一个无法满足的组合。这个毛病在网络上有大量讨论属于标注工具里最常见的玄学问题不是你的环境坏了。解决最简单的办法是单独建一个 Python 3.8 或 3.9 的虚拟环境给标注专用然后先装 pyqt5 再装 labelme或者直接指定版本组合pip install pyqt55.15.7 labelme。装完以后在终端输入 labelme 能正常拉起窗口就说明环境通了。我一直坚持标注环境和训练环境分开就是因为这两个包偶尔互相看不顺眼。5.2 训练时 loss 变成 nan 或不收敛现象训练刚开始 loss 显示正常跑了几十个 iteration 后突然变成 nan或者 loss 一直在 2 以上下不来验证集 mAP 始终是 0。原因先说 nan。最常见的是标签文件里有越界坐标或者空行归一化后的值跑到 1 以外梯度直接爆炸。另一个容易踩的是学习率初始值太高尤其是用预训练权重微调时默认 0.01 在单类小数据集上经常起飞。loss 不收敛则多半是 data.yaml 的路径写错了模型实际上在空数据集上训练或者 train 里混入了一些和 val 完全同源的帧。解决拿一个检查脚本把所有 label 文件扫一遍看 class_id 是否小于 nc、坐标是否都在 0-1 区间先排除数据问题。然后看训练日志里 loss 下降曲线如果第一个 iteration 就是十几把学习率从 0.01 降到 0.001 再试。这两步能解决掉九成以上的训练异常。别一上来就换模型结构手机单类检测这种任务数据比结构重要得多。5.3 Windows 下 PyQt5 摄像头界面只显示一帧或直接假死现象界面能起来但画面显示一帧后就卡住或者拖拽窗口时直接变成「未响应」有时还会持续发出嗡嗡的硬件占用声音。原因最典型的主线程阻塞问题。摄像头读取如果放在主循环里一次 cap.read() 可能要等几十毫秒到上百毫秒而 PyQt5 的主线程必须在事件循环空闲时才能刷新界面。一旦 while 循环里再做模型推理每帧耗时到两三百毫秒界面就像冻住了一样。另一个次要原因是 OpenCV 在高帧率下读摄像头时缓冲取帧策略不同导致读取节奏不稳。解决用 4.2 节的 QThread 方案把读取和推理全部移出主线程。如果已经是 QThread 了还卡检查槽函数里有没有做耗时操作比如在 display 的槽里又调了一次 model.predict那就是二次阻塞。还可以在界面初始化时调用 label 的 setScaledContents(True)避免 QImage 缩放消耗过多 CPU。摄像头的高帧率缓冲则通过 cap.set(cv2.CAP_PROP_FPS, 15) 来限流这招在 Windows 下特别管用。5.4 导出的 ONNX 权重和原模型检测结果不一致现象用同一个 best.pt 跑推理效果不错导出 ONNX 后用 onnxruntime 跑同一张图框的数量或者置信度明显对不上甚至漏检了一半目标。原因YOLO 模型导出 ONNX 时原始模型里内置了一些预处理和后处理逻辑比如输入图像的归一化方式、坐标解码、NMS 参数。opsert 版本太低会导致某些算子行为不同固定输入尺寸出问题时动态尺寸更容易出现偏差。另外 onnxruntime 默认不做 NMS导出的 ONNX 输出的是原始的预测框集合你自己写的后处理必须和 PyTorch 里的逻辑保持一致。解决导出时固定 opset 和输入尺寸opset12、imgsz640 是最稳的组合。写推理脚本时预处理必须用 640x640 的 letterbox 缩放不能直接把原图 resize 进去。后处理里的 conf 阈值和 iou 阈值要和原模型一致。每次导完建议先跑同一张图把结果落盘对比框坐标而不是肉眼看这样能快速定位是预处理还是后处理的差异。作为部署前的通用做法我建议直接信任导出的 ONNX 文件以它为准重新校准阈值而不是回头质疑导出过程。6. 把行为分析做深按时间轴聚合手机使用时长的统计技巧检测模型跑通以后最后一公里是把帧级结果变成有业务含义的统计指标。手机使用检测的行为分析核心就一个指标目标出现在画面里的时间占比以及它在哪个时间段集中出现。这需要把帧索引和视频帧率换算成真实时间而不是用系统时钟。import time from collections import defaultdict from ultralytics import YOLO model YOLO(best.pt) cap cv2.VideoCapture(session_07.mp4) fps cap.get(cv2.CAP_PROP_FPS) detected_frames 0 total_frames 0 hour_count defaultdict(int) start_time time.time() while True: ret, frame cap.read() if not ret: break total_frames 1 results model(frame, conf0.4, verboseFalse) if len(results[0].boxes) 0: detected_frames 1 video_ts total_frames / fps hour_count[int(video_ts // 3600)] 1 use_ratio detected_frames / total_frames print(f视频时长约 {total_frames / fps:.0f}s手机出现帧占比 {use_ratio * 100:.1f}%) for hour in sorted(hour_count): print(f第 {hour} 小时区间检出 {hour_count[hour]} 帧)这段代码里最关键的是 video_ts total_frames / fps它把帧索引变成了视频内的相对时间。我第一次做这类统计时犯过一个错直接用 time.strftime 取系统当前小时数结果把中午 12 点记录成了下午 2 点整个时段分布图全错。从那以后我做的每个行为统计脚本都会先确认时间基准是「视频内部时间」还是「真实挂钟时间」再决定要不要信那个数字。统计结果出来后可以继续把 hour_count 渲染成 HTML 图表放到 PyQt5 界面的 QWebEngineView 里展示比塞一张 matplotlib 静态图直观得多这正是 pyqt5 显示 html 做可视化报表的典型用法。如果你要做的不是视频回放而是摄像头实时统计思路完全一样只是时间基准换成程序启动后的相对秒数。这类统计的价值在于它把一个「看起来在玩手机」的主观判断变成了可复现、可对比的数字。哪怕每天只做一份这样的报表积累一个月你就能看出某个工位或某节课的手机使用规律。这正是这份资源加上你的数据后能发挥到极致的地方——模型的权重只是半成品跑在真实场景里产出持续、可解释的行为指标才是这套工具链的真正意义。希望帮到你。本文还有配套的精品资源点击获取