先说个真事。我之前做园区导览项目用户走出办公楼一百米定位点直接“飞”到隔壁马路中间导航语音还在那喊“您已偏航”。看日志GPS星数从15颗掉到4颗精度从3米飙到28米。当时我就明白了室内或半室外场景指望GPS就是给自己挖坑。后来转向Android手机传感器这条路线用加速度计、陀螺仪、磁力计做步行轨迹记录效果反而稳定得多至少“人在楼里走”这件事能画出来了。这套方案业内叫PDRPedestrian Dead Reckoning行人航位推算核心思路很粗暴如果你能知道每一步的长度和方向就能从起点一路累加画出轨迹。不需要卫星不需要基站只要手机里那几颗MEMS传感器。这篇文章我把原理、代码、以及我踩过的十几个坑一次性讲清楚希望能帮你少走弯路。1. 先搞清楚为什么GPS在室内必然翻车1.1 GPS信号在室内的衰减到底有多严重GPS信号从两万公里外传下来地面接收功率大概只有-125dBm左右比噪声底还低。卫星信号能穿云、穿玻璃但穿不了钢筋混凝土。实测数据是普通办公楼室内GPS信号衰减通常在15到30dB高层建筑核心筒区域直接失锁。我在写字楼B2层做过一次测试手机放在窗边还能收到5颗星往走廊中间走两步就剩下2颗而且全是低仰角、多路径反射后的“假星”。所谓多路径效应就是卫星信号被墙体、金属门、玻璃幕墙反射后再被天线接收伪距被拉长定位结果像喝多了一样乱飘。这也是为什么你站在高楼旁边看手机地图蓝点会莫名其妙跳进楼里。所以室内轨迹记录的第一原则别依赖GPS哪怕它偶尔能收到信号。如果你把GPS的漂移轨迹当真出门右转就是河你也会被画成在河面漂流。1.2 手机上到底有哪些传感器能帮上忙既然GPS靠不住就得靠手机自己的“身体感知”。Android手机目前能用来做步行轨迹的传感器主要有这四种加速度计Accelerometer测量三轴加速度单位m/s²主要用来检测步频、步数和垂直方向的起伏。陀螺仪Gyroscope测量三轴角速度单位rad/s主要用来计算航向变化量。磁力计Magnetometer测量地磁场强度单位μT用来获取绝对朝向相当于电子罗盘。气压计Barometer部分手机有测量气压变化楼层识别就靠它。我把这四个传感器比作“人走路时的身体感受”加速度计是脚步的颠簸感陀螺仪是转弯时的晕眩感磁力计是皮肤对方向的直觉气压计是上下楼时耳朵的闷胀感。把这几个信号拼起来就能还原一个人怎么走的。1.3 PDR方案为什么更适合室内步行PDR全称Pedestrian Dead Reckoning中文常叫行人航位推算。它的工作逻辑是三段式检测步数从加速度波形里数出你迈了多少步。估计步长综合身高、步频、加速度幅值估算每步距离。计算航向用陀螺仪加磁力计算出每步的方向。然后从起点开始不断按“当前坐标 步长 × sin(航向)、cos(航向)”叠加就能得到一条行走轨迹。这套方法的好处是纯本地计算没有外部信号依赖室内、地下、隧道都能跑。缺点也很明显它是个积分系统误差会累积。后面我会专门讲怎么抑制漂移。2. 核心原理拆解人肉惯导系统到底怎么运转2.1 用加速度计做步数检测从波形里数步子手机加速度计输出的三轴加速度是带重力分量的。你静止站着加速度模值约等于重力加速度9.8m/s²。走起来后每一步会有一个垂直方向的加速度起伏近似一个正弦波。最常用的检测算法是峰值检测加阈值判断。流程如下计算三轴加速度的模值acc sqrt(ax² ay² az²)。之所以用模值而不是单轴是因为手机在口袋里的姿态不固定单轴信号会失真。对模值做高通滤波或减去重力分量突出人体运动的动态变化。用滑动窗口寻找局部最大值当峰值高度超过设定阈值且与上一个有效步峰的时间间隔在合理范围内约300ms到2s判定为一步。判断步行是否有效的核心参数有三个峰值高度阈值、最小步间隔、采样窗口。阈值设太高容易漏步设太低会把颠簸、开关门误判成步数。我常用的做法是先拿一组静止数据把噪声底测出来再在噪声底之上加1.2到1.5倍富余量做阈值。2.2 步长估计不是每个人都是0.7米步长是PDR里最头疼的参数之一。很多人直接套公式“步长 身高 × 0.45”但实际效果忽好忽坏。因为步长跟行走速度、路面情况、鞋底、疲劳程度都有关。同一个1米75的人快走和散步的步长能差到20厘米。工程上常用动态步长模型步长 A × 步频² B × 步频 C其中A、B、C是拟合系数。还有一种更简单的做法用加速度波形的峰谷差来估计步长步长 ≈ K × (acc_peak - acc_valley)的1/4次方K需要通过一段已知距离校准。首次使用建议做一次性校准找一条50米标准跑道正常速度走完全程记下实际步数算出你的平均步长。项目里把这个步长作为初始值后续再用步频动态修正。这个方法虽然土但比任何公式都可靠。2.3 航向估计陀螺仪加磁力计才是正解方向搞错轨迹越画越离谱。Android里早期有个TYPE_ORIENTATION传感器后来被废弃了因为它是单纯基于磁力计的在室内受钢筋、钢制门、电箱影响极大稍微转个角度朝向能跳几十度。正确做法是陀螺仪积分加磁力计融合。陀螺仪短时间非常准能灵敏捕捉你这1秒转了5度还是8度但积分久了会漂移。磁力计长时间稳短时间容易被干扰。两者互补常用的融合算法是互补滤波。互补滤波的公式简化下来是这样final_heading α × (previous_heading gyro_delta) (1 - α) × magnetometer_heading。α通常取0.95到0.98意思是“大部分信任陀螺仪偶尔用磁力计拉回来一下”。这个方案跑起来方向稳定性比单独用磁力计强很多。2.4 坐标合成从步数和方向到一条路有了每步的距离和方向位置更新就是一道小学几何题。假设起点是(x0, y0)当前航向角θ以正北为0度顺时针增加这一步的方向增量是x stepLength × sin(θ)y stepLength × cos(θ)把这个循环跑1000步就得到1000个坐标点连起来就是轨迹。3. 动手前的准备工作工具、权限和坐标系3.1 Android传感器编程的正确入口Android里操作传感器用的是SensorManager。获取方式如下SensorManager sensorManager (SensorManager) getSystemService(Context.SENSOR_SERVICE); Sensor accelerometer sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER); Sensor gyroscope sensorManager.getDefaultSensor(Sensor.TYPE_GYROSCOPE); Sensor magnetometer sensorManager.getDefaultSensor(Sensor.TYPE_MAGNETIC_FIELD);注册监听器时采样率我用SensorManager.SENSOR_DELAY_GAME大约是20ms到50ms一次足够捕捉步行波形的峰谷。SENSOR_DELAY_FASTEST虽然更快但耗电高、噪声也大步行场景没必要。3.2 Android 12以上要注意的传感器SDK要求从Android 12API 31开始部分传感器的数据精度会受到限制。我记得当时查文档发现低功耗传感器和后台传感器访问都增加了限制而且Google Play对利用传感器数据做用户画像有严格的隐私声明要求。如果只是做本地轨迹记录建议把targetSdk放在当前主流版本的同时在AndroidManifest.xml里声明传感器权限uses-permission android:nameandroid.permission.ACTIVITY_RECOGNITION /申请时还要动态请求响应权限。这里有个坑如果用户拒绝授权SensorManager不会直接报错而是可能导致步数检测结果完全为0。项目上线前一定要做“拒绝授权”的回归测试。3.3 坐标系和手机姿态决定你数据处理方式Android传感器返回的坐标系是设备坐标系X轴向右Y轴向上Z轴垂直于屏幕向外。手机放在口袋、拿在手里、放在包里三种姿态下同一根轴的加速度读数天差地别。我推荐的处理思路是在步数检测时用加速度模值规避姿态问题在航向估计时根据手机的主要使用姿态做坐标系变换。我的项目默认假设用户手持手机且屏幕朝上所以会把设备坐标系的Y轴投影到水平面当作前进方向。如果你要支持“手机放口袋”的模式就得用另外的姿态判断逻辑。4. 实操环节写一个能跑的室内步行轨迹记录Demo4.1 项目结构规划我建议把传感器部分拆成一个单独类不要塞进Activity里。结构大概这样PdrManager负责传感器注册、数据读取、步数检测、航向计算、坐标更新。StepDetector负责加速度处理与峰值检测。HeadingEstimator负责陀螺仪/磁力计融合。主界面只负责显示坐标轨迹和实时步数。这样分开写的好处是方便调试单独测StepDetector时不用跑整个界面。4.2 步数检测的完整代码下面是StepDetector的核心结构我已经删掉了无关冗余保留了关键逻辑public class StepDetector implements SensorEventListener { private static final float GRAVITY_THRESHOLD 9.0f; private static final float STEP_THRESHOLD 1.8f; private static final float STEP_MIN_INTERVAL_MS 300f; private long lastStepTime 0; private float lastAccMagnitude 0; private OnStepListener listener; Override public void onSensorChanged(SensorEvent event) { float ax event.values[0]; float ay event.values[1]; float az event.values[2]; double magnitude Math.sqrt(ax * ax ay * ay az * az); float accDynamic (float) (magnitude - GRAVITY_THRESHOLD); if (accDynamic STEP_THRESHOLD) { long currentTime System.currentTimeMillis(); if (currentTime - lastStepTime STEP_MIN_INTERVAL_MS) { lastStepTime currentTime; if (listener ! null) { listener.onStep(currentTime); } } } lastAccMagnitude (float) magnitude; } public interface OnStepListener { void onStep(long timestamp); } }这个版本是简化版适合先跑通链路。它的主要问题是单一阈值遇到手机颠簸、过减速带之类场景容易误判。真实项目里需要做低通滤波预处理用二阶Butterworth滤波器或滑动平均把高频噪声干掉。另外这里还是用了“重力阈值”会受手机姿态影响。更好的做法是先用低通滤波把重力分量分离出来再用原始模值减重力得到动态分量。Android里可以用以下方式算重力private float[] gravity new float[3]; private float[] linearAcceleration new float[3]; // 在onSensorChanged里 gravity[0] alpha * gravity[0] (1 - alpha) * event.values[0]; gravity[1] alpha * gravity[1] (1 - alpha) * event.values[1]; gravity[2] alpha * gravity[2] (1 - alpha) * event.values[2]; linearAcceleration[0] event.values[0] - gravity[0]; linearAcceleration[1] event.values[1] - gravity[1]; linearAcceleration[2] event.values[2] - gravity[2];alpha通常取0.8对应截止频率大约5Hz左右既能保留步行信号的波形特征又能滤掉高频抖动的干扰。4.3 航向融合的完整代码航向融合我直接用互补滤波简洁且效果可接受。核心代码如下public class HeadingEstimator implements SensorEventListener { private static final float ALPHA 0.97f; private float[] magnetometer new float[3]; private float[] accelerometer new float[3]; private float[] rotationMatrix new float[9]; private float[] orientation new float[3]; private float currentHeading 0f; private long lastGyroTime 0; Override public void onSensorChanged(SensorEvent event) { if (event.sensor.getType() Sensor.TYPE_MAGNETIC_FIELD) { magnetometer event.values.clone(); } else if (event.sensor.getType() Sensor.TYPE_ACCELEROMETER) { accelerometer event.values.clone(); } else if (event.sensor.getType() Sensor.TYPE_GYROSCOPE) { long now event.timestamp; if (lastGyroTime ! 0) { float dt (now - lastGyroTime) / 1000000000f; float deltaHeading -event.values[2] * dt; currentHeading deltaHeading; } lastGyroTime now; } if (magnetometer ! null accelerometer ! null) { SensorManager.getRotationMatrix(rotationMatrix, null, accelerometer, magnetometer); SensorManager.getOrientation(rotationMatrix, orientation); float magneticHeading (float) Math.toDegrees(orientation[0]); if (magneticHeading 0) magneticHeading 360f; currentHeading ALPHA * currentHeading (1 - ALPHA) * magneticHeading; } } public float getHeading() { return currentHeading; } }这里我取陀螺仪的Z轴角速度作为方向变化量假设手机在水平面上旋转。如果你要支持竖屏状态下的行走Y轴可能才是旋转轴需要结合姿态矩阵。注意陀螺仪的timestamp单位是纳秒做时间差时除以10亿才能换算成秒。这个坑我栽过一次忘记除单位结果航向一秒钟转了540度画出来的轨迹像个电风扇。4.4 轨迹坐标更新的计算方法拿到每步的步长和航向后位置更新如下public class PositionTracker { private double posX 0.0; private double posY 0.0; private double stepLength 0.7; // 初始步长建议校准 public void update(double headingDegrees) { double headingRad Math.toRadians(headingDegrees); posX stepLength * Math.sin(headingRad); posY stepLength * Math.cos(headingRad); } public double[] getPosition() { return new double[]{posX, posY}; } }headingDegrees是当前航向角0为正北顺时针增大。这个坐标是相对坐标如果要用地图定位最后需要做一次坐标平移和旋转跟真实地图对齐。我在项目里会在起点记录GPS坐标哪怕飘起点附近还算能用或让用户手动选一个起点。5. 避坑指南这十几个坑我是真金白银踩出来的5.1 陀螺仪不是零漂的积分久了必飘陀螺仪虽准但存在零偏bias静止时输出也不完全为0。把这段零偏积分进航向一分钟下来就可能偏了5度到10度。如果开着导航走10分钟轨迹末端可能跟实际位置差了50米以上。解决办法有几种定期归零检测到静止状态时把当前角速度当作零偏记录后续读数减去零偏。用磁力计周期性校准互补滤波已经有了但要确保磁力计不被大面积金属物干扰。控制单次记录时长我在项目里建议单次连续记录不超过10分钟超过后就提示“重新校正起点”或自动触发一次方向校准。我实际用的静止检测很简单加速度模值连续1秒波动小于0.3m/s²就判定为静止然后采样陀螺仪100个点求平均作为零偏。效果不输专业校准。5.2 磁力计在室内就是个玻璃花瓶别全信室内电磁环境复杂钢筋、电线、电箱、电梯、钢制防火门都会扭曲磁场。磁力计在这种环境下的读数能让你怀疑人生。我测过办公楼走廊里的磁力计航向同一位置转一圈返回的朝向误差能到30度以上。所以不要把磁力计当作长期绝对参考。我的策略是启动时让用户做一个“八字校准”校准完的磁力计在开阔区域用进入室内后主要通过陀螺仪积分走磁力计只作为低频修正而且只有在磁场变化量不大的时候才信任它。磁场突变时直接把融合权重压到0.99甚至1.0完全靠陀螺仪撑过去。5.3 手机怎么拿直接决定航向算得对不对PDR最大的隐藏变量是手机姿态。同样往前走手机屏幕朝上拿在手里和装在口袋里陀螺仪Z轴角速度所代表的方向含义完全不同。如果不做姿态识别航向误差轻松破百。我的方案是引入姿态识别模块先用重力方向判断手机是“手持”、“口袋”、“通话”还是“桌面”状态然后针对不同状态选择不同的旋转轴映射。手持模式最简单直接用Z轴角速度口袋模式要复杂一些需要把设备坐标系的角速度投影到世界坐标系的垂直轴。这一块没有捷径必须采集数据、画图、看波形把姿态逻辑调准。我建议在开发初期给三轴角速度分别打日志配合手机屏幕方向回放能很快看清问题。5.4 步幅参数要动态但别指望全自动步长固定会导致一个结果走得快时轨迹变短走得慢时轨迹变长。因为步频改变了实际步长但你还在用固定值。动态步长可以解决一部分问题但它需要准确的身体参数比如身高、腿长、标定距离。我给一个“够用就行”的建议工程上做一个校准页让用户输入身高然后按下“走20步”通过GPS或已知距离把实际步长算出来。这个值存进本地下次使用直接套用。跑了100米后的平均步长比任何频率模型都贴地气。5.5 后台运行时传感器的保活与耗电如果你打算做成后台记录工具注意Android的后台限制。锁屏一段时间后系统可能杀掉进程传感器事件也会中断。我的经验是使用前台服务Foreground Service配合通知常驻避免进程被杀。在onSensorChanged里做高频写入前先检查时间戳避免同一时刻重复写数据库。采样率不要用SENSOR_DELAY_FASTEST用GAME档足够功耗能减少一半。电池优化白名单要提示用户手动加入。5.6 测试时别偷懒多测几台手机不同厂商对传感器的调校质量天差地别。我用过某款千元机和旗舰机做对比同一段路径轨迹误差能差出20%。这是因为MEMS器件的温漂、噪声参数、采样频率实现都有差异。建议测试矩阵至少覆盖三个维度低端、中端、旗舰各一台。手持、口袋、通话三种姿态。开机刚启动、热机运行10分钟、手机发热后三种状态。每次测试记录原始传感器日志方便对比波形。这个工作量大但做产品就必须接受。6. 常见问题速查表问题现象可能原因解决办法步数偏多阈值太低颠簸误判提高峰值阈值增加静止期滤除逻辑步数偏少阈值太高或手机固定太牢降低阈值确保手机随身体自由晃动轨迹不走直线陀螺仪零偏开机后静止校准定期归零轨迹起点漂磁力计受金属干扰做八字校准远离金属物重新启动轨迹越走越偏累计误差过大缩短单次记录时长加入地标校正停止后轨迹还在动误把静止颠簸当步行增加连续静止判定检测到静止后暂停步数累积后台记录被系统杀掉少后台定位、缺前台服务升级为前台服务申请忽略电池优化保护7. 你应该怎么做才能避免重走我的弯路关于这套方案的落地我想梳理几条核心链路帮你快速验证是否适合你的场景。第一条链路是“只做步数统计”。如果你只需要知道“今天走了多少步”完全不需要自己写算法。Android有官方的Step Counter传感器由计步协处理器硬件实现耗电极低精度远高于自研算法。缺点是部分低端机没有硬件计步器返回null时需要降级到加速度计方案。第二条链路是“室内地图上的实时轨迹”。这是PDR的完整应用需要结合建筑平面图做匹配。开局时选好起点和朝向后续每走一步就推算一个新点然后用粒子滤波把轨迹吸附到走廊中心线上。粒子滤波的实现成本较高但效果远胜裸PDR。如果建筑结构简单也可以简化成“走廊中心线映射”把每个坐标点投影到最近的走廊线上。第三条链路是“室内外无缝切换”。我的建议是室外用GPS当检测到GPS精度变差、且加速度计显示连续步行时自动切换成PDR。切回室外时利用GPS重新校准PDR的累积误差。这个小逻辑不算复杂但体验提升非常明显。我已经用这套思路做过三个项目最成功的一个是在大型商场里做顾客动线分析连续记录30分钟300米左右的路径最终误差控制在12米内。虽然不能跟GPS室外场景比但作为纯手机端的室内方案已经够用。最后再分享一个小技巧PDR的测试不能只看终点误差一定要画出整条轨迹叠加到真实地图上看。有时候终点对上了中间却穿了两堵墙这种失效是终点误差体现不出来的。我习惯把每次测试的轨迹导出成KML文件在Google地球里跟真实路径做对比一眼就能看出哪个转弯算错了哪段步长估大了。这个方法我一直沿用到今天。