18、传感器与电量：传感器功耗排行、批处理模式、传感器融合、合理使用传感器

各位同学，今天我们来聊聊传感器和电量的那些事儿。

说实话，传感器是手机里最「勤劳」的一批零件。它们一直在工作，一直在采集数据。但勤劳是要付出代价的——电量。我见过不少项目，就是因为传感器没管好，导致手机待机一晚上掉电 20%。嗯，这显然不能忍。

18.1 传感器的功耗排行

先给大家一个直观的概念。不同传感器，功耗差距非常大。我习惯把它们分成三个梯队：

梯队	传感器类型	典型功耗	说明
低功耗	加速度计、陀螺仪、磁力计	0.1~2 mW	MEMS 传感器，常驻运行没问题
中等功耗	气压计、环境光传感器、接近传感器	2~10 mW	需要时开启，不要一直跑
高功耗	摄像头、GPS、麦克风	50~500 mW	能不用就不用，用完立刻关

你想想看，GPS 跑一小时，可能比加速度计跑一天还费电。所以，选对传感器，比优化代码更重要。

18.2 批处理模式：让传感器「攒一波再上报」

很多同学写传感器代码，习惯来一个数据就上报一次。这其实很浪费。

为什么？因为每次上报都要唤醒 AP（应用处理器），而 AP 从休眠到唤醒，一次就要消耗几十毫瓦。你想想，如果每秒上报 100 次，光唤醒功耗就爆炸了。

批处理模式（Batch Mode）就是解决这个问题的。传感器先把数据存到自己的 FIFO 里，攒够一批，再一次性上报。AP 只需要被唤醒一次，处理一批数据，然后继续睡。

我在项目中遇到过这样一个案例：一个运动追踪 App，每秒上报 50 次加速度数据。改成批处理模式后，每 5 秒上报一次，每次 250 个数据。结果呢？功耗直接降了 70%。

Android 里怎么用？看代码：

// 开启批处理模式，设置最大报告延迟为 5 秒
Sensor sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER);
SensorEventQueue queue = sensorManager.createSensorEventQueue();

// 关键：设置 maxReportLatencyUs
sensorManager.registerListener(queue, sensor,
    SensorManager.SENSOR_DELAY_NORMAL,
    5000000); // 5秒 = 5000000微秒

注意这个 maxReportLatencyUs 参数。设为 0 就是实时上报，设得越大，批处理效果越明显。

18.3 传感器融合：1+1 > 2

单个传感器往往有缺陷。比如陀螺仪有漂移，加速度计有噪声。但把它们的数据结合起来，就能得到更准确的结果。这就是传感器融合。

最常见的例子是姿态检测。只用陀螺仪，角度会越偏越远。只用加速度计，动态响应太慢。两者融合，用卡尔曼滤波或互补滤波，就能得到稳定又灵敏的姿态角。

我曾经在一个 AR 项目里，就是因为没做融合，手机转个 45 度，虚拟物体飘了 10 度。后来加了互补滤波，误差控制在 2 度以内。

Android 从 4.0 开始就提供了虚拟传感器，比如 TYPE_ROTATION_VECTOR，它就是硬件融合后的结果。直接用，省心又省电。

18.4 合理使用传感器：实战避坑指南

讲了这么多理论，最后来点实战经验。合理使用传感器，说白了就三句话：

1. 按需开启，用完即关——别在 Activity 的 onResume 里注册，onPause 里注销。很多新手犯这个错。
2. 降低采样率——不是所有场景都需要 SENSOR_DELAY_FASTEST。游戏用 FASTEST，计步用 NORMAL 就够了。
3. 利用 Sensor Hub——现在主流 SoC 都有独立的低功耗传感器处理器。把数据采集和简单处理交给它，AP 可以继续睡大觉。

我曾经接手过一个项目，GPS 和加速度计同时开着，每 100ms 上报一次数据。我一看，这手机能撑 4 小时就不错了。后来改成：GPS 每 10 秒定位一次，加速度计用批处理模式每 2 秒上报一次。续航直接翻了三倍。

嗯，今天就聊到这里。记住这些原则，你的 App 在电量排行榜上，就不会是那个「耗电大户」了。