读懂 onSensorChanged：理解 SensorEvent 的数据结构
好，咱们继续往下走。上一章我们聊了怎么注册监听器，但真正干活的地方，其实是 onSensorChanged 这个回调方法。你想想看，传感器数据就像流水一样源源不断地涌进来，而 onSensorChanged 就是那个接水的盆子——你得知道盆子里装的是什么，才能用好这些数据。
我个人习惯把 SensorEvent 比作一个「数据快递包裹」。系统每检测到一次传感器数值变化，就会给你扔过来一个包裹。你得学会拆包裹，看懂里面的每一件东西。
SensorEvent 里到底有什么？
先看一段最基础的代码，感受一下：
@Override
public void onSensorChanged(SensorEvent event) {
// event 就是那个包裹
float x = event.values[0];
float y = event.values[1];
float z = event.values[2];
int sensorType = event.sensor.getType();
long timestamp = event.timestamp;
int accuracy = event.accuracy;
}嗯，就这么几行。但里面藏着四个关键字段，我一个个说。
values[] —— 真正的数据核心
values 是一个 float[] 数组。不同传感器，数组长度和含义完全不同。我刚开始学的时候，就吃过这个亏——以为所有传感器都是三个值，结果处理光线传感器时拿 values[1]，读出来一堆莫名其妙的数据。
常见的对应关系是这样的：
| 传感器类型 | values 长度 | values[0] | values[1] | values[2] |
|---|---|---|---|---|
| 加速度传感器 | 3 | X 轴加速度 (m/s²) | Y 轴加速度 (m/s²) | Z 轴加速度 (m/s²) |
| 陀螺仪 | 3 | 绕 X 轴角速度 (rad/s) | 绕 Y 轴角速度 (rad/s) | 绕 Z 轴角速度 (rad/s) |
| 光线传感器 | 1 | 环境光照强度 (lux) | — | — |
| 磁场传感器 | 3 | X 轴磁场强度 (μT) | Y 轴磁场强度 (μT) | Z 轴磁场强度 (μT) |
| 接近传感器 | 1 | 距离 (cm) | — | — |
重要提醒： 永远不要硬编码 values 的长度。用 event.values.length 来判断，或者根据 event.sensor.getType() 来动态处理。我在项目中遇到过某款国产平板，它的加速度传感器居然返回了 4 个值——第 4 个是温度补偿数据。如果你写死了 values[3]，轻则数组越界崩溃，重则数据全错。
sensor —— 告诉你数据从哪来
event.sensor 是一个 Sensor 对象。你可能会问：我不是已经在注册监听器时指定了传感器类型吗？为什么还要读这个字段？
原因很简单：如果你用同一个 SensorEventListener 监听多个传感器，onSensorChanged 会被反复调用。这时候你就得靠 event.sensor.getType() 来区分数据来源。
@Override
public void onSensorChanged(SensorEvent event) {
switch (event.sensor.getType()) {
case Sensor.TYPE_ACCELEROMETER:
// 处理加速度数据
break;
case Sensor.TYPE_GYROSCOPE:
// 处理陀螺仪数据
break;
}
}这种做法在实际项目中非常常见。比如做一个导航应用，你可能同时需要加速度和磁场传感器来计算方向。用 switch 分支处理，代码清晰又安全。
timestamp —— 别小看这个时间戳
event.timestamp 记录的是传感器事件发生的系统时间，单位是纳秒。注意，它不是 System.currentTimeMillis()，而是 System.nanoTime() 类似的单调时钟。
为什么重要？因为你要算「两次事件之间的时间差」。比如计算速度变化、做数据平滑滤波，都需要精确的时间间隔。
我的小技巧： 如果你需要把时间戳转换成人类可读的时间，可以用 event.timestamp / 1000000 得到毫秒值，然后和 System.currentTimeMillis() 做差值。但注意，不同设备的时钟源可能不同，跨设备对比时间戳意义不大。
accuracy —— 数据的可信度
event.accuracy 是一个整型常量，表示传感器数据的精度等级。取值有三种：
SensorManager.SENSOR_STATUS_ACCURACY_HIGH(3) —— 数据很准，放心用SensorManager.SENSOR_STATUS_ACCURACY_MEDIUM(2) —— 还行，但可能有小偏差SensorManager.SENSOR_STATUS_ACCURACY_LOW(1) —— 数据不太靠谱，建议别用SensorManager.SENSOR_STATUS_UNRELIABLE(0) —— 数据不可信，需要重新校准
我曾经做过一个计步器应用，刚开始没检查精度，结果用户把手机放在桌上，步数也在涨。后来发现是磁场干扰导致加速度数据漂移。加上精度判断后，问题就解决了。
避坑指南： 当 accuracy 变成 UNRELIABLE 时，系统通常会很快回调一次 onAccuracyChanged()。但别指望每次都能收到。我建议在 onSensorChanged 里也做一次精度检查，双重保险。
一张图看懂 SensorEvent
说了这么多，咱们用一张 SVG 图把整个结构串起来：
实际项目中的使用套路
好了，理论说完了，咱们看看实际怎么写。我一般会封装一个工具类，把 SensorEvent 解析成更易用的数据模型：
public class AccelerometerData {
public float x;
public float y;
public float z;
public long timestamp;
public boolean isReliable;
public static AccelerometerData fromEvent(SensorEvent event) {
AccelerometerData data = new AccelerometerData();
data.x = event.values[0];
data.y = event.values[1];
data.z = event.values[2];
data.timestamp = event.timestamp;
data.isReliable = event.accuracy >= SensorManager.SENSOR_STATUS_ACCURACY_MEDIUM;
return data;
}
}这样做的好处是：业务代码里不用再关心 SensorEvent 的细节，拿到 AccelerometerData 直接用就行。而且万一以后 Android API 变了，你只需要改 fromEvent 这一个地方。
我的习惯： 在 onSensorChanged 里尽量少做事。数据来了，解析成模型，然后通过回调或 LiveData 抛出去。不要在回调里做 UI 更新、文件读写、网络请求——这些操作会阻塞主线程，导致传感器事件丢失。说白了，onSensorChanged 是数据管道，不是数据终点。
一个常见的坑：values 数组是复用的
这一点很多人不知道。系统为了减少内存分配，SensorEvent 里的 values 数组可能是复用的。什么意思？就是你如果在 onSensorChanged 里把 event.values 直接赋值给一个成员变量，下次回调时这个数组的内容就被覆盖了。
正确的做法是：要么在回调里立即使用，要么深拷贝一份：
// 错误示范
private float[] mValues;
mValues = event.values; // 危险！下次回调 mValues 就变了
// 正确做法
private float[] mValues = new float[3];
System.arraycopy(event.values, 0, mValues, 0, 3);我曾经因为这个 bug 排查了整整一个下午。数据时而正常时而异常，最后发现是引用没拷贝。嗯，从那以后我养成了「收到数据立刻拷贝」的习惯。
好了，关于 SensorEvent 的数据结构，核心就是这些。你只要记住：values 是数据本体，sensor 是数据来源，timestamp 是时间标记，accuracy 是质量标签。把这四个字段吃透了，onSensorChanged 对你来说就没有秘密了。