15、传感器系统：Sensor HAL、数据上报、低功耗模式

传感器这块，说实话，是嵌入式Android里最“接地气”的部分。你想想看，手机知道你横着拿还是竖着拿，计步器怎么知道你走了几步，这些全靠传感器。我在做第一代智能手表项目时，就被传感器折腾得够呛——功耗、精度、上报频率，哪个没踩过坑？今天咱们就把它彻底聊透。

15.1 Sensor HAL 架构：承上启下的关键层

Android的传感器系统，说白了就是三层：应用层、Framework层、HAL层。HAL层是硬件厂商必须实现的接口。我习惯把HAL层比作“翻译官”——它把芯片厂商那些千奇百怪的寄存器操作，翻译成Android系统能理解的统一接口。

来看一下最核心的数据结构：

// 来自 hardware/libhardware/include/hardware/sensors.h
struct sensor_t {
    const char*     name;       // 传感器名称，比如 "BMI160 Accelerometer"
    const char*     vendor;     // 供应商，比如 "Bosch"
    int             version;    // 版本号
    int             handle;     // 传感器句柄，唯一标识
    int             type;       // 传感器类型，比如 SENSOR_TYPE_ACCELEROMETER
    float           maxRange;   // 最大量程
    float           resolution; // 分辨率
    float           power;      // 功耗，单位 mA
    int32_t         minDelay;   // 最小上报间隔，单位微秒
    uint32_t        fifoReservedEventCount; // FIFO保留事件数
    uint32_t        fifoMaxEventCount;      // FIFO最大事件数
    const char*     stringType; // 字符串类型
    const char*     requiredPermission; // 所需权限
    int32_t         maxDelay;   // 最大上报间隔
    int32_t         flags;      // 标志位
    void*           reserved[2];// 保留字段
};

嗯，这里要注意 minDelay 和 maxDelay。我见过不少新手把这两个搞反。minDelay 是传感器能支持的最快上报速度，maxDelay 是最慢速度。比如一个加速度计，minDelay 可能是 5000 微秒（200Hz），maxDelay 可能是 1000000 微秒（1Hz）。

15.2 数据上报机制：从硬件到应用的全链路

数据上报，说白了就是传感器怎么把数据“喂”给系统。我遇到过最典型的问题：为什么我明明在驱动层打印了数据，但App就是收不到？

整个链路是这样的：

传感器芯片 → 驱动层(内核) → HAL层 → SensorService → 应用层

每一层都可能丢数据，每一层都有缓冲。我个人习惯在HAL层加一个调试开关，可以实时查看数据流是否通畅。

HAL层上报数据的关键函数是 poll()：

static int poll_sensors(struct sensors_poll_device_t *dev,
                        sensors_event_t* data, int count) {
    // 从硬件读取原始数据
    // 转换为 Android 标准格式
    // 填充 sensors_event_t 结构体
    data[0].type = SENSOR_TYPE_ACCELEROMETER;
    data[0].acceleration.x = accel_x;
    data[0].acceleration.y = accel_y;
    data[0].acceleration.z = accel_z;
    data[0].timestamp = get_current_ns();
    return 1; // 返回上报的事件数量
}

15.3 低功耗模式：让传感器“聪明地”工作

低功耗模式，这是传感器系统里最考验功力的地方。你想想看，手机待机时，计步器还在工作，但你不能让CPU一直跑着。怎么办？

Android 提供了几种低功耗策略：

模式	说明	功耗	适用场景
正常模式	CPU主动轮询传感器	高	游戏、AR等实时性要求高的场景
FIFO模式	传感器数据暂存到硬件FIFO，批量上报	中	计步器、姿态检测
中断模式	传感器检测到事件后触发中断唤醒CPU	低	抬手亮屏、翻转静音
硬件批处理	传感器在硬件层面完成数据处理，只上报结果	极低	计步器（步数累加）

我曾经在做一个运动手环项目时，发现计步器功耗居高不下。排查了半天，原来是FIFO配置错了——每次只存一个数据就上报，CPU频繁被唤醒。后来改成FIFO存满64个数据再上报，功耗直接降了70%。

15.4 传感器批处理：批量上报的艺术

批处理（Batch Mode）是低功耗的核心。说白了，就是让传感器自己攒一批数据，然后一次性上报。这样CPU可以长时间休眠。

HAL层需要实现 batch() 函数：

static int batch(struct sensors_poll_device_t *dev,
                 int handle, int flags,
                 int64_t sampling_period_ns,
                 int64_t max_report_latency_ns) {
    // sampling_period_ns: 采样周期
    // max_report_latency_ns: 最大上报延迟
    // 如果 max_report_latency_ns > 0，启用批处理模式
    if (max_report_latency_ns > 0) {
        // 配置硬件FIFO
        // 设置FIFO深度
        // 配置水印中断
    } else {
        // 实时模式，每次采样立即上报
    }
    return 0;
}

这里有个关键点：max_report_latency_ns 决定了数据能延迟多久上报。比如设为10秒，那么传感器可以攒10秒的数据，然后一次性上报。但如果你做的是游戏，延迟必须小于20毫秒，那就得用实时模式。

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

单个传感器往往不够用。比如做姿态检测，加速度计+陀螺仪+磁力计融合，才能得到稳定的姿态角。这就是传感器融合。

Android 提供了 SENSOR_TYPE_ROTATION_VECTOR 这种虚拟传感器，它底层就是融合了多个物理传感器的数据。我在项目中实现过自己的融合算法，用的是卡尔曼滤波：

// 简化的卡尔曼滤波融合
void sensor_fusion_update(float accel[3], float gyro[3], float mag[3]) {
    // 预测步骤：根据陀螺仪积分
    // 更新步骤：用加速度计和磁力计修正
    // 输出：四元数或欧拉角
}

15.6 传感器校准：数据准确的前提

传感器出厂时都有偏差。加速度计可能有零偏，磁力计可能受硬铁干扰。不校准的话，数据根本没法用。

Android 提供了校准框架：

• 在线校准：运行时根据数据统计自动校准
• 离线校准：工厂生产时写入校准参数
• 用户校准：让用户画“8”字校准磁力计

我遇到过最离谱的事：某款手机的磁力计，因为PCB布局问题，受到扬声器磁铁的干扰。校准参数写死了也没用，因为扬声器工作时磁场会变化。最后只能加一个磁力计数据有效性检测，发现异常就丢弃。

15.7 知识体系总览

下面这张图，是我梳理的传感器系统核心逻辑。你看一遍，基本就能把握住整个脉络了。

这张图把传感器系统的五层架构和三大核心机制都串起来了。你写代码时，脑子里要有这张图——知道当前在操作哪一层，要跟哪一层打交道。

---

好了，传感器系统就聊到这儿。说实话，这部分内容在面试里经常被问到，尤其是低功耗和批处理。你把这些搞懂了，面试官问啥都不怕。下次咱们聊聊更深入的话题。