批处理

什么是批处理？

批处理是指在通过传感器 HAL报告事件之前在传感器集线器和/或硬件 FIFO 中缓冲传感器事件。缓冲传感器事件的位置（传感器集线器和/或硬件 FIFO）在此页面上称为“FIFO”。当传感器事件批处理未激活时，传感器事件会立即报告给传感器 HAL（如果可用）。

当许多传感器事件准备好处理时，批处理可以仅唤醒运行 Android 的主应用处理器 (AP)，而不是针对每个单独的事件唤醒它，从而显着节省电量。潜在的节能效果与传感器集线器和/或 FIFO 可以缓冲的事件数量直接相关：如果可以批量处理更多事件，则节能潜力更大。批处理利用低功耗内存来减少高功耗 AP 唤醒的次数。

仅当传感器拥有硬件 FIFO 和/或可以在传感器集线器内缓冲事件时，才会发生批处理。无论哪种情况，传感器都必须通过SensorInfo.fifoMaxEventCount报告可以一次性批处理的最大事件数。

如果传感器在 FIFO 内保留了空间，则传感器必须通过SensorInfo.fifoReservedEventCount报告保留事件的数量。如果 FIFO 专用于传感器，则SensorInfo.fifoReservedEventCount是 FIFO 的大小。如果 FIFO 在多个传感器之间共享，则该值可能为零。一个常见的用例是允许传感器使用整个 FIFO（如果它是唯一的活动传感器）。如果多个传感器处于活动状态，则每个传感器都保证有空间用于 FIFO 中至少SensorInfo.fifoReservedEventCount事件。如果使用传感器集线器，则可以通过软件强制执行保证。

传感器事件在以下情况下进行批处理：

  • 传感器当前的最大报告延迟大于零，这意味着传感器事件在通过 HAL 报告之前可以延迟至最大报告延迟。
  • AP 处于挂起模式，传感器是非唤醒传感器。在这种情况下，事件不得唤醒 AP，并且必须存储到 AP 唤醒为止。

如果传感器不支持批处理并且 AP 处于睡眠状态，则仅将唤醒传感器事件报告给 AP，而不得将非唤醒事件报告给 AP。

配料参数

控制批处理行为的两个参数是Sample_period_ns和max_report_latency_ns 。 sampling_period_ns确定生成新传感器事件的频率，而max_report_latency_ns确定必须将事件报告给传感器 HAL 的时间。

采样周期_ns

sampling_period_ns参数的含义取决于指定传感器的报告模式：

  • Continuous： sampling_period_ns是采样率，表示事件生成的速率。
  • 变化时： sampling_period_ns限制事件的采样率，这意味着事件的生成速度不会快于每个sampling_period_ns纳秒。如果没有生成事件并且测量值长时间内不发生变化，则周期可以长于sampling_period_ns 。有关更多详细信息，请参阅更改报告模式。
  • 一次性： sampling_period_ns被忽略。它没有任何作用。
  • 特殊：有关如何将sampling_period_ns用于特殊传感器的详细信息，请参阅传感器类型。

有关不同模式下sampling_period_ns的影响的更多信息，请参阅报告模式。

对于连续和变化传感器：

  • 如果sampling_period_ns小于SensorInfo.minDelay ，则 HAL 实现必须默默地将其限制为max(SensorInfo.minDelay, 1ms) 。 Android 不支持超过 1000 Hz 的事件生成。
  • 如果sampling_period_ns大于SensorInfo.maxDelay ，则 HAL 实现必须将其静默截断为SensorInfo.maxDelay 。

物理传感器有时对其运行速率和时钟精度有限制。考虑到这一点，实际采样频率可以与请求的频率不同，只要它满足下表中的要求即可。

如果请求的频率是

那么实际频率一定是

低于最小频率 (<1/maxDelay)

最小频率的 90% 到 110% 之间

最小和最大频率之间

请求频率的 90% 到 220% 之间

高于最大频率 (>1/minDelay)

最大频率的 90% 到 110% 之间，且低于 1100 Hz

最大报告延迟时间

max_report_latency_ns设置最长时间（以纳秒为单位），在 AP 唤醒时，事件在通过 HAL 报告之前可以延迟并存储在硬件 FIFO 中。

值为零表示必须在测量事件后立即报告事件，要么完全跳过 FIFO，要么一旦出现来自传感器的事件就清空 FIFO。

例如，当 AP 唤醒时，以 50 Hz 激活且max_report_latency_ns=0的加速计将每秒触发中断 50 次。

当max_report_latency_ns>0时，传感器事件不需要一检测到就上报。它们可以临时存储在 FIFO 中并批量报告，只要没有事件延迟超过max_report_latency_ns纳秒。这意味着自上一批以来的所有事件都会立即记录并返回。这减少了发送到 AP 的中断量，并允许 AP 在传感器捕获和批处理数据时切换到较低功耗模式（空闲）。

每个事件都有一个与之关联的时间戳。延迟报告事件的时间不会影响事件时间戳。时间戳必须准确，并且对应于事件实际发生的时间，而不是报告的时间。

允许传感器事件临时存储在 FIFO 中不会修改向 HAL 提交事件的行为；来自不同传感器的事件可以交错，并且来自同一传感器的所有事件都是按时间顺序排列的。

唤醒和非唤醒事件

来自唤醒传感器的传感器事件必须存储在一个或多个唤醒 FIFO 中。常见的设计是采用单个大型共享唤醒 FIFO，其中来自所有唤醒传感器的事件交错。或者，您可以为每个传感器配备一个唤醒 FIFO，或者为特定唤醒传感器配备专用 FIFO，并为其余唤醒传感器配备共享 FIFO。

类似地，来自非唤醒传感器的传感器事件必须存储在一个或多个非唤醒 FIFO 中。

在所有情况下，唤醒传感器事件和非唤醒传感器事件不能在同一 FIFO 中交错。唤醒事件必须存储在唤醒 FIFO 中，非唤醒事件必须存储在非唤醒 FIFO 中。

对于唤醒 FIFO，单个大型共享 FIFO 设计可提供最佳功耗优势。对于非唤醒 FIFO，单个大型共享 FIFO 和多个小型保留 FIFO 设计具有相似的功耗特性。有关如何配置每个 FIFO 的更多建议，请参阅FIFO 分配优先级。

挂起模式之外的行为

当 AP 唤醒（未处于挂起模式）时，只要事件延迟不超过max_report_latency ，事件就会临时存储在 FIFO 中。

只要 AP 不进入挂起模式，就不会丢弃或丢失任何事件。如果内部 FIFO 在max_report_latency过去之前变满，则会在此时报告事件以确保没有事件丢失。

如果多个传感器共享同一个 FIFO，并且其中一个传感器的max_report_latency已过，则即使其他传感器的max_report_latency尚未到期，也会报告 FIFO 中的所有事件。这减少了报告批量事件的次数。当必须报告一项事件时，将报告来自所有传感器的所有事件。

例如，如果激活以下传感器：

  • 加速度计批处理max_report_latency = 20s
  • 陀螺仪批处理max_report_latency = 5s

即使加速度计和陀螺仪不共享相同的 FIFO，也会在报告陀螺仪批次的同时报告加速度计批次（每 5 秒）。

挂起模式下的行为

批处理特别有利于在后台收集传感器数据，而无需保持 AP 处于唤醒状态。由于传感器驱动程序和 HAL 实现不允许保持唤醒锁*，因此即使在收集传感器数据时，AP 也可以进入挂起模式。

AP 挂起时传感器的行为取决于传感器是否为唤醒传感器。有关更多详细信息，请参阅唤醒传感器。

当非唤醒 FIFO 填满时，它必须回绕并像循环缓冲区一样运行，用新事件替换旧事件来覆盖旧事件。 max_report_latency在挂起模式下对非唤醒 FIFO 没有影响。

当唤醒 FIFO 填满时，或者当唤醒传感器之一的max_report_latency过去时，硬件必须唤醒 AP 并报告数据。

在这两种情况下（唤醒和非唤醒），一旦 AP 退出挂起模式，即使某些传感器的max_report_latency尚未过去，也会使用所有 FIFO 的内容生成一个批次。这可以最大限度地降低 AP 在返回挂起模式后不久必须再次唤醒的风险，从而最大限度地降低功耗。

*不允许驱动程序保持唤醒锁的一个值得注意的例外是，当具有连续报告模式的唤醒传感器被激活且max_report_latency < 1 秒时。在这种情况下，驱动程序可以保持唤醒锁，因为 AP 没有时间进入挂起模式，因为在到达挂起模式之前它会被唤醒事件唤醒。

批量唤醒传感器时的注意事项

根据设备的不同，AP 可能需要几毫秒才能完全退出挂起模式并开始刷新 FIFO。必须在 FIFO 中分配足够的空间，以允许器件退出挂起模式而不会导致唤醒 FIFO 溢出。任何事件都不应丢失，并且必须遵守max_report_latency 。

批处理非唤醒变化传感器时的注意事项

变化传感器仅在其测量的值发生变化时生成事件。如果在 AP 处于挂起模式时测量值发生变化，则应用程序期望在 AP 唤醒后立即接收事件。因此，如果传感器与其他传感器共享其 FIFO，则必须仔细执行非唤醒变化传感器事件的批处理。每个变化传感器生成的最后一个事件必须始终保存在共享 FIFO 之外，因此它永远不会被其他事件覆盖。当 AP 唤醒时，在报告 FIFO 中的所有事件后，必须报告最后一个变化传感器事件。

这里有一种情况需要避免：

  1. 应用程序注册到非唤醒计步器（变化时）和非唤醒加速度计（连续），两者共享相同的 FIFO。
  2. 应用程序接收计步器事件step_count=1000 steps code>。
  3. AP 进入暂停状态。
  4. 用户走了 20 步，导致步数计数器和加速度计事件交错，最后一个步数计数器事件为step_count = 1020 steps 。
  5. 用户长时间没有移动，导致加速计事件继续在 FIFO 中累积，最终覆盖共享 FIFO 中的每个step_count事件。
  6. AP 唤醒，并且 FIFO 中的所有事件都发送到应用程序。
  7. 应用程序仅接收加速度计事件并认为用户没有行走。

通过将最后一个计步器事件保存在 FIFO 之外，HAL 可以在 AP 唤醒时报告此事件，即使所有其他计步器事件都被加速度计事件覆盖。这样，当 AP 唤醒时，应用程序会接收到step_count = 1020 steps 。

实施批处理

为了节省电量，批处理必须在没有AP的帮助下进行，并且必须允许AP在批处理期间暂停。

如果在传感器集线器中执行批处理，则应最大限度地减少传感器集线器的功耗。

最大报告延迟可以随时修改，特别是在指定传感器已启用时；这不应该导致事件丢失。

先进先出分配优先级

在硬件 FIFO 和/或传感器集线器缓冲区大小有限的平台上，系统设计人员可能必须选择为每个传感器保留多少 FIFO。为了帮助您做出选择，下面列出了在不同传感器上实施批处理时可能的应用。

高价值：低功耗行人航位推算

目标批处理时间：1 至 10 分钟

要批量的传感器：

  • 唤醒计步器
  • 5 Hz 时的唤醒游戏旋转矢量
  • 5 Hz 唤醒气压计
  • 以 5 Hz 唤醒未校准的磁力计

批处理此数据允许执行行人航位推算，同时让 AP 暂停。

高价值：中等功率间歇性活动/手势识别

目标批处理时间：3秒

要批处理的传感器：50 Hz 时的非唤醒加速度计

批量处理这些数据可以定期识别任意活动和手势，而无需在收集数据时保持 AP 唤醒状态。

中等值：中等功率连续活动/手势识别

目标配料时间：1 至 3 分钟

批处理传感器：50 Hz 唤醒加速度计

批量处理这些数据可以连续识别任意活动和手势，而无需在收集数据时保持 AP 唤醒状态。

中高值：减少中断负载

目标批处理时间：< 1 秒

要批处理的传感器：任何高频传感器，通常是非唤醒的。

如果陀螺仪设置为 240 Hz，即使仅批处理 10 个陀螺仪事件也可以将中断数量从 240 次/秒减少到 24 次/秒。

中等价值：持续低频数据收集

目标批处理时间：1 至 10 分钟

要批量的传感器：

  • 1 Hz 唤醒气压计
  • 以 1 Hz 频率唤醒湿度传感器
  • 其他频率相似的低频唤醒传感器

允许以低功耗创建监控应用程序。

中低值：连续全传感器采集

目标批处理时间：1 至 10 分钟

要批处理的传感器：所有唤醒传感器，高频

允许完整收集传感器数据，同时使 AP 处于挂起模式。仅考虑 FIFO 空间是否不是问题。