简介：这是一款面向Android平台的跌倒检测识别Demo，主要面向移动端AI应用开发者、安防及智慧养老领域的技术人员，用于快速验证和应用实时摔倒识别功能。Demo基于YOLOv5检测模型，完整呈现了从模型部署到Android应用构建的工程流程，适合有一定目标检测基础、想在手机端落地跌倒检测的开发者参考学习。压缩包共2个文件，包含一个可直接安装运行的app-release.apk安装包和一份output-metadata.json构建元数据，整体大小约50.44MB，结构清晰，拿到后即可安装体验跌倒识别效果，也可结合元数据了解构建配置。目前已有1933人学习下载，开发者可通过该Demo快速掌握YOLOv5在Android端的应用思路，参考作者配套的博文教程和跌倒检测数据集，进一步完成模型优化、重新训练与场景化定制，从而应用于智能监控、独居老人看护、医院病房巡视等真实场景中的跌倒预警需求，省去从零搭建工程和调试模型的时间成本，非常适合快速启动相关项目。 从被塞到手机里的“跌倒检测识别Android Demo.zip”说起。我收到过不少类似的项目包，文件名都叫“XX识别Demo”，解压出来一个能跑的工程，但绝大多数人把它跑起来之后就不知道下一步该怎么办了——报警逻辑写哪里？阈值怎么调？为什么我正常走路它也喊摔倒？这篇文章我不打算逐行带你念代码，而是把这套跌倒检测识别Demo从传感器数据、判定逻辑到工程实现拆开讲清楚。无论你是刚用Android Studio打开工程的同学，还是想把这套东西集成到自己App里的开发者，按照这篇文章的思路都能把Demo吃透，并且知道怎么改才靠谱。
1. 拿到Demo先别急着跑：跌倒检测到底在检测什么
1.1 “跌倒”不是一个动作，而是一段状态序列
很多人刚开始接触这类项目时有个误区，觉得跌倒检测就是识别“摔这个动作”。实际上从算法角度看，一次完整的跌倒由三个阶段组成：失重、撞击、静止（或者缓慢起身）。
拿手机传感器数据说话：你把手机握在手里正常站立时，三轴加速度计读到的合加速度大概稳定在9.8 m/s²附近，也就是1个g的重力加速度。当人体真正跌倒时，首先是身体失去平衡、处于自由落体状态，这时合加速度会明显掉到0.5g以下，专业说法叫“失重期”；紧接着身体砸向地面或硬物，加速度会在几十毫秒内猛冲到2.5g甚至3g以上，这是“撞击期”；最后人倒在地上一段时间不动，或者仅有小幅移动，这就是“静止期”。
这套Demo的核心能力，就是通过传感器把这三个阶段识别出来，而不是去“看”一个人有没有摔倒。理解这一点非常重要，因为它直接决定了后面所有阈值设计、滤波策略和误报漏报的取舍。如果你一上来就盯着“识别准确率”这个指标较劲，很容易忽略掉这个前提。
1.2 视觉方案与传感器方案怎么选
类似的Demo在Android平台上一般有两条路线：一条是调用摄像头做姿态估计，比如用MediaPipe的人体骨骼关键点检测判断人的中心点高度是否骤降；另一条就是本例用到的传感器路线，读取加速度计、陀螺仪、方向传感器数据做判断。
两条路线各有利弊。视觉路线直观，适合固定摄像头监控场景，比如装在客厅角落，但耗电高、受光照和遮挡影响大，而且涉及摄像头权限和隐私问题，在手机上做被动监控是重场景。传感器路线轻量，可以做成后台常驻的守护服务，功耗低，也不需要摄像头权限，手机放口袋里就能工作，缺点是没办法区分“人摔了”和“手机被甩出去了”。
我个人的结论是：Demo用传感器路线是合理的，因为Android端的跌倒检测主要面向随身场景——老人随身携带手机、独居人士把手机放在口袋里。用传感器做后台监控，比用摄像头靠谱得多。后面我再讲从Demo到产品的扩展方向，也都是沿着这条线走。
2. Android端数据采集：传感器信号怎么变成判据
2.1 加速度计、陀螺仪各负责什么
Android的SensorManager里有非常多的传感器类型，但跌倒检测Demo里真正起核心作用的就两个：TYPE_ACCELEROMETER（加速度计）和TYPE_GYROSCOPE（陀螺仪），有的实现还会用TYPE_ROTATION_VECTOR（旋转向量）参与计算姿态角。
加速度计测量的是设备受到的加速度，单位是m/s²，静止时读到的数值里包含重力加速度；陀螺仪测量的是设备绕三轴的角速度，单位是rad/s，用来感知身体旋转。跌倒过程中身体不仅有平动，还有大幅度的转动——比如后仰摔倒时身体绕某个轴转过去，这时候单靠加速度计不够，因为加速度计在剧烈运动下会混入大量线性加速度，难以区分重力方向，用陀螺仪可以辅助判断姿态变化。
有些教程会把陀螺仪说得可有可无，实际上在区分“真正摔倒”和“猛蹲一下”的时候，姿态角变化率是特别重要的特征。Demo源码里如果只用了加速度计，你可以留意一下它的误报率，大概率在快速弯腰捡东西时会失灵。
2.2 采样率不是越高越好
Android注册传感器监听时有一个采样率参数，从SENSOR_DELAY_NORMAL到SENSOR_DELAY_FASTEST。SENSOR_DELAY_NORMAL大概是200ms一次，只有5Hz，这样采样率在人体跌倒检测里根本不够用——撞击期也就几十毫秒，5Hz采样很可能一个撞击尖峰直接漏掉。SENSOR_DELAY_FASTEST能到1ms一报，但那是传感器硬件的极限频率，对大多数手机来说没必要，还会把CPU和电池都耗进去。
Demo里比较常见的做法是用SENSOR_DELAY_GAME，也就是大约20ms一报，等效于50Hz。为什么选这个档位？因为人体跌倒动作的关键频段基本在0.5Hz到10Hz之间，50Hz采样率已经足够捕获撞击尖峰了，而且功耗可控。我个人在实际项目里也是先按50Hz来，后面再看数据决定是否降频省电。
2.3 坐标系和重力分离：最容易踩的坑
每个做过Android传感器开发的人都会被坐标系坑过一次。设备默认坐标系是：屏幕向右为x正方向，屏幕向上（竖屏时）为y正方向，垂直屏幕向外为z正方向。手机平放在桌面上的时候，读到的加速度是x≈0，y≈0，z≈9.8；竖着拿在手里的时候，y轴上会有约9.8的重力分量。
所以拿着原始xyz值直接算特征是很危险的事。同样一次跌倒，手机在口袋里是竖着、横着还是屏幕朝内，读出来的三个轴数值差别非常大。正确的做法是先用低通滤波把重力分量分离出来，得到“线性加速度”和“重力方向”，再由重力方向推算出设备倾角。低通滤波的原理不复杂：重力是缓慢变化的低频信号，运动冲击是突变的高频信号，用一个带遗忘因子的递推公式保留低频部分。网上大部分开源代码都有这步，但很多人会抄漏，最后导致不同拿姿下检测效果天差地别。
3. 阈值判定不够“AI”但足够稳：核心检测算法拆解
3.1 SVM信号向量幅值：先把三维压成一维
前面说了一堆三轴数据，但真正做阈值判断时，一般先算一个叫SVM（Signal Vector Magnitude）的指标：
[ SVM = \sqrt{ax^2 + ay^2 + az^2} ]
这个公式把三个轴上的加速度值合成为一个标量，取值范围天然包含了重力。静止站立时SVM约等于9.8（即1g），跌倒失重阶段会掉到0.4g以下，撞击阶段会冲到2.5g以上。这样一来，三维空间里的复杂问题就变成了“一条曲线的峰值谷值”问题，非常方便做阈值判定。
在Demo的代码里，你大概率能看到类似if (svm > HIGH_THRESHOLD)这样的判断语句，这就是在捕捉撞击期。需要提醒的是：千万不要直接用原始加速度的低通滤波结果去算SVM，低通滤波会把撞击尖峰抹平，你会漏掉大量真实跌倒。滤波要分路做——一路低通来算倾角，一路保留原始或轻微平滑来计算SVM。
3.2 特征组合：撞击之外还需要角度和静止
如果只看SVM这一个特征，Demo的误报率会高到你怀疑人生。跑步时每一步落地，SVM也能冲到2g以上；被人拍肩膀、手机被人拍一下，也会出现尖峰。所以成熟一点的Demo都会加配两个辅助判据。
第一个是姿态角变化。通过重力方向在三个轴上的投影分量，可以算出设备当前的倾角。正常直立时倾角接近90度（手机竖放）或者0度（手机平放，看你定义），跌倒后如果人倒地，设备倾角会发生大幅变化，通常设定为变化量超过50度算有效。为什么要看变化量而不是绝对角度？因为手机在口袋里的初始姿态因人而异，看变化量对佩戴位置更鲁棒。
第二个是撞击后的静止判定。真正的跌倒者倒地后不会立刻站起来，会有1到3秒的低活动期。算法会在检测到撞击后，继续观察一段时间，如果这期间SVM一直维持在小幅波动状态（比如低于1.2g且波动范围很小），就确认这是一次跌倒。这个设计直接过滤掉了“人还在剧烈运动但手机被甩飞”的假阳性。
3.3 状态机架构：代码里最值得看的部分
把这些判据串起来的通常是一个简单的状态机，状态迁移大概是：
正常站立 -> 失重状态（SVM < 0.6g） -> 撞击状态（SVM > 2.5g） -> 静止确认（持续1s低活动） -> 触发告警
为什么用状态机而不是一个巨大if？因为状态机能自然表达“时序关系”，并且可以通过超时机制自动复位——比如失重之后没有撞到东西，过500ms就回到正常状态，而不是误触告警。这个思想非常值得学，后续你在这个Demo里加新特征，比如角度变化、心率数据，都是往状态迁移条件里追加，比在回调函数里堆if清晰一百倍。
阈值参考值我这里给一组我实际调过的初始值，方便你在不同机型上起步，注意是参考不是金标准：
| 参数 | 推荐初始值 | 说明 |
|---|---|---|
| 失重阈值 | 0.6g | SVM低于该值进入失重状态，可上下调整0.1g |
| 撞击阈值 | 2.5g | SVM高于该值判定撞击，跟手机佩戴松紧有关 |
| 姿态角变化 | 50度 | 跌倒后倾角变化一般超过该值 |
| 静止等待时间 | 1.5s | 撞击后低活动持续该时间确认跌倒 |
| 失重复位时间 | 500ms | 失重后未撞击，超时回正常状态 |
4. Demo工程实现要点：从Sensor到告警的完整链路
4.1 工程结构：几个包各管什么事
正规一点的Demo会把代码分成几个模块。如果你解压后看到的目录结构乱七八糟，那大概率不是一个值得深用的工程；如果是模块清晰的，可以参考这个分层逻辑：
- 数据采集层：封装SensorManager的注册、注销、回调，把三轴数据打包成数据类，统一抛给上层
- 算法层：不依赖Android API的纯Java/Kotlin类，输入传感器数据，输出检测结果。这一层建议不要有任何Log、Toast、UI操作，方便单测和迁移
- 状态管理层：维护状态机、计时器、阈值配置
- 告警与UI层：收到检测结果后发通知、播放音频、弹窗或者上报位置
这套分层的价值在于：算法层不依赖Android系统，你可以直接在本地写单元测试，输入一段模拟的跌倒数据，验证算法逻辑是否正确。这是我拿到一个Demo之后第一件会做的事。
4.2 后台采集：服务保活与Android版本适配
跌倒检测是典型的后台常驻场景，所以Demo里一般都存在一个前台服务（Foreground Service）。为什么必须用前台服务？因为从Android 8.0开始，系统对后台服务的限制非常严格，后台App在几秒钟内就会被系统回收，跌倒检测这种需要持续监听传感器的任务如果不用前台服务，手机放口袋里几分钟，进程就没了。
使用前台服务需要注意两点。一是必须同时提供通知栏常驻通知，告诉用户“XX应用正在监听跌倒事件”，这既是系统强制要求，也是用户知情权的一部分，你不能偷偷摸摸在后台跑传感器。二是Android 14（API 34）开始，前台服务必须声明具体类型，跌倒检测这类用途需要仔细看官方对foregroundServiceType的要求，选错类型会直接崩溃。这个坑在Demo代码里一般不体现，你自己在真机上跑新版系统时才会遇到。
4.3 传感器监听的生命周期管理
传感器回调是高频事件，50Hz的频率意味着每20ms回调一次，如果在回调里做哪怕一点点耗时操作，比如写文件、发网络请求，都会造成数据堆积和界面卡顿。正确的做法是在回调里只做“读数据、过滤、算特征、状态判断”这些轻量计算，把告警发送等低频操作丢到主线程Handler或协程里异步执行。
另一个很常见的坑是忘记在onPause/onStop里解绑传感器监听。Demo在调试阶段你可能觉得无所谓，但实际使用时，前台服务里注册了监听，Activity销毁了却不注销，会导致传感器一直工作，电量哗哗往下掉。这不是什么高深问题，但是代码审查时最容易被人挑出来的问题之一。
4.4 告警链路：通知、声音与回调接口
Demo触发跌倒后的默认动作一般是弹一个全屏通知。稍微好一点的实现会预留一个“告警回调接口”，让你在检测到跌倒时能接出去做自己的事——发短信给紧急联系人、上传定位、推送服务器告警。如果你拿到手的是个Demo，我强烈建议不要只停留在“弹通知”这步，检查一下代码里有没有类似OnFallDetectedListener的接口，如果有，那这个工程的扩展性就合格了；如果没有，需要自己抽象一层。因为真实场景里，跌倒检测的价值一定在“跌倒之后做了什么”，而不是“检测到了”。
5. 实测与调优：误报、漏报和我的避坑记录
5.1 误报重灾区：弯腰、坐下、甩手和扔手机
拿Demo直接上真机，你大概率会遇到的第一个问题就是误报高。我自己初测时，光“快速下蹲捡东西”这个动作就能触发七八次报警。原因很简单：下蹲也有失重、有冲击，姿态角也会大变，如果静止确认时间设置得太短，算法就会把“蹲下后停顿”误判成“跌倒后静止”。
多轮调整之后，我的结论是把静止等待时间从1s拉到1.5s到2s，同时增加一个“撞击后姿态角必须先出现较大变化”的逻辑——下蹲时姿态角变化往往没有后仰跌倒那么剧烈。另外一个容易被忽略的误报源是手机从手里滑落或者被随手甩到沙发上，这类情况SVM和姿态角都符合，但人并没有摔倒。这时候只能靠使用场景约束，比如检测到跌倒后先播放一段询问语音“您是否摔倒？我可以帮您呼叫紧急联系人”，给用户3秒取消时间，用交互消除部分误报。这个思路很土，但在产品层面非常有效。
5.2 漏报更麻烦：慢速滑倒和扶着墙倒下
误报烦人，但漏报要命。最典型的漏报场景是：老人扶着墙慢慢滑坐下去，加速度曲线几乎没有明显的撞击尖峰，SVM根本达不到2.5g；或者有人倒在软垫、沙发上，冲击被缓冲掉了。这类跌倒恰恰是真实场景里最容易发生的，但单靠阈值很难识别。
要缓解漏报，可以在算法层把“检测模式”分为两种：一种是标准模式，用于明显跌倒；另一种是慢速模式，识别“长时间姿态异常+低活动量”的组合。慢速模式不看撞击尖峰，而是看姿态角是否长时间偏离直立状态，并且伴随非常低的运动量。说白了，就是“倒了但没摔出动静”也能被发现。如果你拿到的Demo不支持这种双模式，这会是你要做的第一个算法增强。
5.3 手机佩戴位置：裤子口袋、上衣口袋还是手里
传感器数据跟佩戴位置强相关。手机放在裤子前口袋和后口袋，初始姿态角就完全不同；放在上衣口袋和拿在手里，跌倒时手机的运动轨迹也不一样。Demo里如果只按一种佩戴位置调试，换一个位置测试效果就会崩。
我能给的建议是：在Demo里加一个“佩戴位置”配置项，预设裤袋、上衣口袋、手持三种模式，分别调整初始姿态角和阈值方向。最简单的实现就是在设置页面放三个按钮，切换时重置算法参数。这不需要改算法核心结构，但对实测效果的提升非常明显。如果你在帮家里老人做这个，先确定好老人习惯把手机放哪个位置，再把这个位置写死，比做一个“全场景自适应”靠谱得多。
5.4 科学的测试方法：别拿真摔开玩笑
调试跌倒检测最大的痛点是测试数据。谁也不愿意真的摔几次，安全风险太大。更合理的做法是设计跌倒模拟：站在软垫旁边，手里握着手机做“假摔”动作，让身体顺势倒下但用手肘缓冲；或者使用“甩手机法”——把手机用绳子绑着快速甩落到软垫上，模拟一个自由落体加撞击的曲线。
我还会把实时传感器数据画成折线图，打印到Log或屏幕上边测边看。看到SVM曲线的谷值和峰值分别落在什么区间，你就知道阈值该怎么调了。这一步别省，没有可视化的阈值调试完全就是盲人摸象。磨刀不误砍柴工，Demo自带的Activity里如果能画个实时波形，这个项目的调试体验就赢了一大半。
6. 从Demo走向产品：这个项目还能怎么延伸
6.1 什么时候值得换成机器学习模型
阈值方案在Demo阶段完全够用，但它的缺点是泛化能力有限：换了手机型号、换了佩戴习惯，阈值可能就要重调。如果你把数据录下来打上标签，观察特征分布之后发现阈值方法已经很难再压误报漏报，就可以考虑上轻量模型了。
Android端最顺手的路线是先试传统的SVM分类器或多层感知机（MLP），输入特征可以包括：SVM峰值、谷值、峰值谷值间隔、姿态角变化量、撞击后静止时长等。这些特征都是从现有逻辑里直接提取的，不用额外开发。再往前走一步才是LSTM或者TinyML方案，把原始时序喂进网络，但模型训练和端侧部署成本都高不少，Demo项目里不建议一上来就搞。
6.2 融合定位、历史数据与穿戴设备
跌倒检测最落地的场景还是老人看护。到了这个层面，算法本身只是整个系统的一小块。完整的看护系统一般还需要：跌倒后自动获取GPS定位并发送给紧急联系人；结合历史活动数据判断老人是不是比平时安静太久；如果有智能手表/手环，可以再接入心率数据，作为跌倒后身体状态确认的辅助信号。
我在好几个类似项目里看到，团队的精力最后大多花在“跌倒之后怎么办”的流程上，而不是检测算法上。给紧急联系人拨电话、发短信、App推送、短信带定位链接，这些链路在Demo里往往没有，但产品上线时一个都不能少。如果时间有限，我建议优先做“一键拨号+定位短信”这两个能力，它们是老人跌倒场景里最刚需的。
6.3 我的一些真实体会
最后说几个个人经验里的感受。这类识别Demo的最大价值不在于“能跑通过一次测试”，而在于你能不能把它变成一个可以稳定运行、批量复现的系统。我在实际调试中最深的三点体会是：传感器数据一定要可视化，否则你根本不知道算法为什么误判；阈值参数一定要做成可配置而不是写死，因为每台手机、每种佩戴习惯都不一样；检测到跌倒后的确认交互一定不能省，取消误报的几秒钟能让你省下无数投诉。
每增加一个功能点，都先问自己一个问题：这个改动在真实场景里是增强了老人安全感，还是只是让代码看起来更酷。跌倒检测说到底是给人用的，稳定、可靠、少误报、不漏报，比任何花哨的模型结构都重要。
本文还有配套的精品资源，点击获取
