12、低功耗模式：使用SensorManager的flush方法、批量处理传感器事件

霍尔传感器本身功耗不高，但如果你在项目中频繁地轮询或注册高频监听，那电量消耗一样会蹭蹭往上涨。我记得有一次做智能门锁项目，用户反馈说电池两周就没电了。排查下来，罪魁祸首就是霍尔传感器的事件处理太“积极”了——每次磁场变化都立刻上报，CPU频繁被唤醒。

嗯，今天我们就聊聊怎么用SensorManager.flush()和批量处理机制，把功耗降下来。

12.1 为什么需要批量处理？

传感器事件默认是“来一个报一个”。你注册了监听器，传感器每采集到一个数据，系统就回调一次onSensorChanged()。这在数据量小的时候没问题，但如果传感器以几十甚至几百Hz的频率上报，CPU就会被频繁打断。

说白了，每次回调都意味着一次线程切换、一次IPC通信。积少成多，功耗就上去了。

批量处理的核心思路是：攒一批数据，一次性上报。这样CPU可以集中处理，然后继续休眠。

12.2 批量模式怎么开启？

Android从4.4（API 19）开始支持批量传感器事件。你不需要额外调用什么特殊API，只需要在注册监听器时设置maxReportLatencyUs参数。

这个参数的意思是：最多延迟多少微秒上报。比如你设成1秒（1000000微秒），那传感器事件最多会缓存1秒，然后一次性回调给你。

SensorManager sensorManager = (SensorManager) getSystemService(SENSOR_SERVICE);
Sensor hallSensor = sensorManager.getDefaultSensor(Sensor.TYPE_MAGNETIC_FIELD);

// 设置最大延迟为500毫秒
int maxReportLatencyUs = 500 * 1000; // 500ms

sensorManager.registerListener(
    sensorEventListener,
    hallSensor,
    SensorManager.SENSOR_DELAY_NORMAL,
    maxReportLatencyUs
);

12.3 flush()方法：强制刷新缓冲区

批量模式有个问题：数据攒在缓冲区里，如果一直没达到上报条件，那你就永远拿不到最新数据。比如你设了1秒延迟，但用户只用了0.5秒就关上了翻盖——这时候你希望立刻拿到数据，而不是再等0.5秒。

flush()就是干这个的。它强制传感器把当前缓冲区里的所有事件一次性上报，然后清空缓冲区。

// 在需要立即获取最新数据时调用
sensorManager.flush(sensorEventListener);

调用flush()后，你会先收到一个onFlushCompleted()回调，然后才是批量的事件数据。这个顺序是固定的，别搞反了。

12.4 批量事件的处理方式

批量模式下，onSensorChanged()回调里拿到的SensorEvent对象，它的values数组里可能包含多个采样点。你需要通过event.timestamp来区分每个采样点的时间。

我曾经踩过一个坑：以为每次回调只包含一个数据点，结果在批量模式下只取了event.values[0]，漏掉了后面几十个数据。嗯，后来老老实实遍历了所有数据。

@Override
public void onSensorChanged(SensorEvent event) {
    // 批量模式下，event可能包含多个采样点
    // 通过event.timestamp获取每个采样点的时间戳
    long timestamp = event.timestamp;
    float x = event.values[0];
    float y = event.values[1];
    float z = event.values[2];

    // 这里处理数据...
    // 注意：如果批量数据量大，不要在回调里做耗时操作
}

12.5 知识结构图

12.6 实际项目中的避坑指南

我总结了几条实战经验，希望能帮你少走弯路：

• 不要滥用flush()：频繁调用flush()会抵消批量模式带来的省电效果。我建议只在关键事件发生时调用，比如检测到翻盖闭合、设备进入休眠前。
• 注意回调线程：onSensorChanged()默认在主线程回调。如果批量数据量大，记得把数据处理逻辑放到子线程，否则会卡UI。
• 测试不同设备：不同厂商对批量模式的支持程度不一样。我曾经在某个低端平板上发现，设了延迟参数后传感器干脆不回调了。嗯，最后加了个兜底逻辑：如果5秒内没收到数据，就主动flush一次。
• 合理选择延迟值：不是越大越好。延迟太大会导致数据“跳跃感”明显，用户体验变差。我个人习惯在100ms~500ms之间调试，找到省电和实时性的平衡点。

12.7 完整示例代码

下面是一个完整的霍尔传感器低功耗监听示例，包含了批量注册、flush调用和事件处理：

public class HallSensorLowPowerActivity extends AppCompatActivity 
        implements SensorEventListener {

    private SensorManager sensorManager;
    private Sensor hallSensor;
    private static final int BATCH_DELAY_US = 300 * 1000; // 300ms

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_hall);

        sensorManager = (SensorManager) getSystemService(SENSOR_SERVICE);
        hallSensor = sensorManager.getDefaultSensor(Sensor.TYPE_MAGNETIC_FIELD);

        if (hallSensor == null) {
            // 设备不支持霍尔传感器
            return;
        }

        // 注册监听器，开启批量模式
        sensorManager.registerListener(
            this,
            hallSensor,
            SensorManager.SENSOR_DELAY_NORMAL,
            BATCH_DELAY_US
        );
    }

    @Override
    public void onSensorChanged(SensorEvent event) {
        // 批量模式下，这里可能一次收到多个采样点
        // 通过event.timestamp区分不同时间点的数据
        long timestamp = event.timestamp;
        float x = event.values[0];
        float y = event.values[1];
        float z = event.values[2];

        // 处理数据...
        // 建议放到子线程处理，避免阻塞主线程
    }

    @Override
    public void onAccuracyChanged(Sensor sensor, int accuracy) {
        // 精度变化时处理
    }

    // 在需要立即获取最新数据时调用
    public void forceFlush() {
        sensorManager.flush(this);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        sensorManager.unregisterListener(this);
    }
}

好了，关于低功耗模式就聊这么多。说白了就是一句话：别让CPU频繁醒来干活，攒一批再处理。配合flush()方法，你既能省电，又能在关键时刻拿到最新数据。

---