第26章传感器优化

课程目录第26章传感器优化

26、传感器优化：传感器采样率控制、批处理模式、传感器融合、功耗优化

传感器这块，说实话，很多Android开发同学容易忽略。大家总觉得「不就是调个API嘛」，结果一上线，电量哗哗往下掉。我见过太多App因为传感器没优化好，被用户直接卸载的案例。

今天咱们就聊聊传感器优化的四个核心方向：采样率控制、批处理模式、传感器融合、功耗优化。嗯，这四点搞明白了，你的App在传感器这块基本就稳了。

采样率控制：别让传感器「满负荷运转」

先问个问题：你的App真的需要每秒100次的方向数据吗？

我个人的习惯是，先问产品经理「这个功能需要多快的响应？」。如果只是检测手机横竖屏，那每秒5次就够了。如果是做体感游戏，那可能需要每秒50次以上。但大多数场景，其实用不了那么高的采样率。

核心原则：采样率够用就行，别贪多。

Android提供了几种采样率模式：

SENSOR_DELAY_NORMAL：约200ms一次，适合屏幕方向检测
SENSOR_DELAY_UI：约60ms一次，适合UI交互
SENSOR_DELAY_GAME：约20ms一次，适合游戏
SENSOR_DELAY_FASTEST：最快速度，能多快就多快

我在项目中遇到过这样一个坑：有个同事做计步器功能，直接用了SENSOR_DELAY_FASTEST。结果呢？手机半天就没电了。后来改成SENSOR_DELAY_UI，计步精度几乎没变，但功耗降了70%。

小技巧：如果实在不确定该用哪个，先从SENSOR_DELAY_UI开始，然后根据实际效果逐步调整。别一上来就上最猛的。

批处理模式：把数据「攒一波」再处理

你想想看，每次传感器来一个数据，你就唤醒CPU处理一次，这得多费电？

批处理模式（Batch Mode）就是解决这个问题的。它允许传感器在硬件层面缓存数据，等攒到一定数量再一次性上报给应用层。

// 开启批处理模式
Sensor sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER);
SensorEventListener listener = new SensorEventListener() {
    @Override
    public void onSensorChanged(SensorEvent event) {
        // 这里处理批处理后的数据
        // event.values 包含多个采样点的数据
    }
    
    @Override
    public void onAccuracyChanged(Sensor sensor, int accuracy) {
        // 精度变化回调
    }
};

// 第二个参数是采样率，第三个参数是最大延迟时间（微秒）
// 这里设置最大延迟100ms，意味着最多等100ms就会上报一次
sensorManager.registerListener(listener, sensor, 
    SensorManager.SENSOR_DELAY_GAME, 
    100 * 1000); // 100ms

这里有个关键参数：最大延迟时间。它决定了传感器最多能等多久才上报数据。设得太短，批处理效果不明显；设得太长，数据实时性又不够。

注意：不是所有传感器都支持批处理模式。你可以用sensor.getFifoMaxEventCount()来检查。如果返回0，说明不支持批处理。

我曾经在一个运动追踪项目里，把加速度计的批处理延迟设到了200ms。结果呢？CPU唤醒次数从每秒50次降到了每秒5次，功耗直接砍半。而且因为运动数据变化没那么快，200ms的延迟用户根本感觉不到。

传感器融合：1+1 > 2

单个传感器往往有局限性。比如加速度计测方向不准，陀螺仪有漂移，磁力计容易受干扰。但把它们的数据融合在一起，就能得到更准确的结果。

Android系统其实已经内置了一些融合传感器：

融合传感器	输入源	输出
TYPE_ROTATION_VECTOR	加速度计 + 磁力计 + 陀螺仪	设备旋转角度
TYPE_GRAVITY	加速度计 + 陀螺仪	重力方向
TYPE_LINEAR_ACCELERATION	加速度计 - 重力	线性加速度
TYPE_GAME_ROTATION_VECTOR	陀螺仪 + 加速度计	游戏中的旋转（无磁力计）

我个人建议：能用系统融合传感器就别自己写。系统级的融合算法是经过硬件厂商调优的，功耗和精度都比你手写的要好。

但如果你确实需要自己实现融合算法，比如做AR或者专业运动分析，那可以考虑卡尔曼滤波或者互补滤波。这里给个简单的互补滤波思路：

// 互补滤波伪代码
float alpha = 0.98f; // 权重系数
float angle = 0;

void update(float gyroRate, float accelAngle, float dt) {
    // 陀螺仪积分
    float gyroAngle = angle + gyroRate * dt;
    // 融合：陀螺仪占98%，加速度计占2%
    angle = alpha * gyroAngle + (1 - alpha) * accelAngle;
}

为什么alpha设成0.98？说白了就是信任陀螺仪的短期精度，同时用加速度计来修正长期漂移。这个值我调过很多次，0.98是个不错的起点。

经验之谈：如果你做的是游戏或者AR，建议用TYPE_GAME_ROTATION_VECTOR而不是TYPE_ROTATION_VECTOR。前者不用磁力计，省电而且不会因为周围有金属物体就飘。

功耗优化：从「电老虎」到「省电小能手」

传感器是耗电大户，尤其是GPS、陀螺仪、加速度计同时开着的时候。我见过一个导航App，后台开着传感器，一晚上能吃掉30%的电。

怎么优化？我总结了几个实战经验：

按需注册，用完就注销
很多开发者注册了传感器就忘了注销。Activity onPause的时候一定要注销监听器。别偷懒。
```
@Override
protected void onPause() {
    super.onPause();
    sensorManager.unregisterListener(listener);
}
```
降低后台采样率
App切到后台后，采样率可以降一个档次。比如前台用GAME模式，后台用UI模式。
使用触发器传感器
有些场景不需要连续数据，只需要「变化了通知我」就行。比如计步器，用TYPE_STEP_COUNTER或者TYPE_SIGNIFICANT_MOTION，比你自己用加速度计算省电得多。
合并传感器监听
如果你同时需要加速度计和陀螺仪的数据，尽量用同一个SensorManager实例注册，别搞多个实例。

避坑指南：我曾经在一个项目里，为了省电把采样率降得太低，结果导致计步数据严重不准。后来发现是采样率低于10Hz时，步态特征就提取不出来了。所以省电归省电，别牺牲核心功能。

知识体系总览

下面这张图总结了传感器优化的核心逻辑，你可以对照着梳理自己的优化思路：

说白了，传感器优化就一句话：用最少的资源，干最合适的事。采样率别贪高，数据别频繁上报，能用系统融合就别自己写，用完记得关。做到这几点，你的App在传感器这块就不会出大问题。

嗯，今天就聊到这儿。这些经验都是我在实际项目中一点点踩坑踩出来的，希望对你有帮助。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

26、传感器优化：传感器采样率控制、批处理模式、传感器融合、功耗优化

采样率控制：别让传感器「满负荷运转」

批处理模式：把数据「攒一波」再处理

传感器融合：1+1 > 2

功耗优化：从「电老虎」到「省电小能手」

知识体系总览