バッチ処理とは
バッチ処理とは、センサーハブやハードウェア FIFO でセンサー イベントをバッファリングしてから、センサー HAL を介してこれらのイベントをレポートすることです。このページでは、センサー イベントがバッファリングされている場所（センサーハブやハードウェア 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 にはセンサーのウェイクアップ イベントのみがレポートされ、非ウェイクアップ イベントはレポートされないようにする必要があります。
バッチ処理パラメータ
バッチ処理の動作を管理する 2 つのパラメータは、sampling_period_ns と max_report_latency_ns です。sampling_period_ns は、新しいセンサー イベントが生成される頻度を決定するために使用され、max_report_latency_ns は、イベントをセンサー HAL にレポートするのに要する時間を決定するために使用されます。
sampling_period_ns
sampling_period_ns パラメータの意味は、指定したセンサーのレポートモードによって異なります。
- 連続モード:
sampling_period_nsはサンプリング レートであり、イベントが生成される頻度を示します。 - 変化時モード:
sampling_period_nsはイベントのサンプリング レートを制限します。つまり、イベント生成の頻度はsampling_period_nsナノ秒ごとに 1 回を超えません。イベントが生成されず、長い期間にわたって測定値が変わらない場合、期間はsampling_period_nsより長くなることがあります。詳細については、変化時のレポートモードをご覧ください。 - ワンショット モード:
sampling_period_nsは無視されます。このパラメータは影響しません。 - 特殊モード:
sampling_period_nsを特殊センサーに使用する方法について詳しくは、センサータイプをご覧ください。
各モードでの sampling_period_ns の影響について詳しくは、レポートモードをご覧ください。
連続モードのセンサーと変化時モードのセンサー:
sampling_period_nsがSensorInfo.minDelay未満の場合、HAL 実装はこのパラメータを暗黙的にmax(SensorInfo.minDelay, 1ms)に制限する必要があります。Android は、1,000 Hz を超える周波数でのイベント生成をサポートしていません。sampling_period_nsがSensorInfo.maxDelayより大きい場合、HAL 実装はこのパラメータを暗黙的にSensorInfo.maxDelayに切り捨てる必要があります。
物理センサーの動作速度とクロック精度は制限される場合があります。したがって、実際のサンプリング周波数は、下表の要件を満たしている場合に限り、要求された周波数とは異なる場合があります。
リクエストされた周波数の状況 |
実際の周波数の条件 |
|---|---|
最低周波数未満（<1/maxDelay） |
最低周波数の 90%～110% |
最低周波数から最高周波数まで |
リクエストされた周波数の 90%～220% |
最高周波数超（>1/minDelay） |
最高周波数の 90%～110% かつ 1,000 Hz 未満 |
max_report_latency_ns
max_report_latency_ns は、最大時間（ナノ秒単位）を設定します。この値は、HAL を介してレポートされる前に、AP のウェイクアップ中にイベントを遅らせてハードウェア FIFO に保存できる最大時間を指します。
ゼロの値は、測定が完了した直後にイベントをレポートする必要があることを意味します。つまり、FIFO が完全にスキップされるか、センサーからのイベントが FIFO に出現するとすぐに FIFO がクリアされます。
たとえば、50 Hz で有効化された加速度計は、max_report_latency_ns=0 の場合、AP のウェイクアップ中に毎秒 50 回の割り込みをトリガーします。
max_report_latency_ns>0 の場合、センサー イベントを検出した直後にレポートする必要はありません。すべてのイベントのレイテンシが max_report_latency_ns ナノ秒を超えない限り、イベントは一時的に FIFO に保存され、一括でレポートされます。つまり、レポートされたイベントの最後のバッチ以降のすべてのイベントが記録され、一度に返されます。これにより、AP に送信される割り込みの数が減少し、センサーがデータをキャプチャしてバッチ処理を実行している間に、AP は低消費電力モード（アイドル）に切り替えることができます。
各イベントにはタイムスタンプが関連付けられています。イベントのレポート時間が延期しても、イベントのタイムスタンプには影響しません。タイムスタンプは正確であり、レポートされた時間ではなく、イベントの実際の発生時間に対応しています。
センサー イベントを FIFO に一時的に保存できるようにしても、HAL にイベントを送信する動作は変更されません。異なるセンサーからのイベントをインターリーブすることができ、同じセンサーからのすべてのイベントが時間順で並べ替えられます。
ウェイクアップ イベントと非ウェイクアップ イベント
ウェイクアップ センサーからのセンサー イベントは、1 つ以上のウェイクアップ FIFO に保存する必要があります。一般的な設計としては、すべてのウェイクアップ センサーからのイベントがインターリーブされる、1 つの大きな共有ウェイクアップ FIFO の使用が挙げられます。また、センサーごとに 1 つの FIFO を用意することも、特定のウェイクアップ センサーに専用 FIFO を用意し、残りのウェイクアップ センサーに共有 FIFO を用意することもできます。
同様に、非ウェイクアップ センサーからのセンサー イベントは、非ウェイクアップ FIFO に保存する必要があります。
いずれの場合でも、ウェイクアップ センサー イベントと非ウェイクアップ センサー イベントを同じ FIFO にインターリーブすることはできません。ウェイクアップ イベントはウェイクアップ FIFO に保存する必要があり、非ウェイクアップ イベントは非ウェイクアップ FIFO に保存する必要があります。
ウェイクアップ FIFO の場合、1 つの大きな共有 FIFO 設計が最も省電力になります。非ウェイクアップ FIFO の場合、1 つの大きな共有 FIFO の電力消費は、複数の小さな予約済み FIFO 設計と似た程度になります。各 FIFO の設定方法について詳しくは、FIFO 割り当ての優先度をご覧ください。
停止モード以外の動作
AP がウェイクアップ状態にあるとき（停止モードではない）、イベント レイテンシが max_report_latency を超えない限り、イベントは一時的に FIFO に保存されます。
AP が停止モードに入らない限り、イベントがドロップされることも失われることもありません。max_report_latency を経過する前に内部 FIFO がいっぱいになった場合、システムはこの時点でイベントをレポートして、イベントが失われないようにします。
複数のセンサーが 1 つの FIFO を共有している場合、1 つのセンサーが max_report_latency に到達すると、他のセンサーが max_report_latency に到達していなくても、その FIFO からのすべてのイベントがすぐにレポートされます。これにより、イベントが一括でレポートされる回数が減少します。レポートするべきイベントがある場合、すべてのセンサーからのイベントがすべてレポートされます。
たとえば、次のセンサーが有効になっている場合:
max_report_latency= 20 秒でバッチ処理された加速度計max_report_latency= 5 秒でバッチ処理されたジャイロスコープ
加速度計とジャイロスコープが 1 つの FIFO を共有していなくても、加速度計のバッチはジャイロスコープのバッチと同時にレポートされます（5 秒ごとにレポート）。
停止モードでの動作
バッチ処理は、AP をウェイクアップ状態にせずにバックグラウンドからセンサーデータを収集する場合に特に便利です。センサー ドライバと HAL 実装は wake lock*を保持できないため、AP はセンサーデータを収集している間も停止モードに入ることができます。
AP が停止しているときのセンサーの動作は、センサーがウェイクアップ センサーであるかどうかによって異なります。詳しくは、ウェイクアップ センサーをご覧ください。
非ウェイクアップ FIFO がいっぱいになると、ラップ アラウンドしてリングバッファのように動作し、古いイベントを上書きする必要があります。つまり、新しいイベントが古いイベントに置き換わります。max_report_latency は、停止モードのときでも非ウェイクアップ FIFO に影響しません。
ウェイクアップ FIFO がいっぱいになるか、ウェイクアップ センサーの 1 つの max_report_latency が経過すると、ハードウェアは AP をウェイクアップし、データをレポートします。
ウェイクアップと非ウェイクアップのどちらの場合でも、AP が停止モードを終了するとすぐに、一部のセンサーの max_report_latency がまだ経過していなくても、FIFO の内容をすべて含むバッチが生成されます。これにより、AP が再び停止モードに入った直後にウェイクアップするリスクが最小限に抑えられ、エネルギーを最大限に節約できます。
*ドライバが wake lock を保持できない例外として、max_report_latency が 1 秒未満の状況で継続レポートモードのウェイクアップ センサーを有効化する場合が挙げられます。この場合、AP は停止モードに入る前にウェイクアップ イベントによってウェイクアップされるため、ドライバは wake lock を保持できます。このため AP は停止モードに入る機会がありません。
ウェイクアップ センサーをバッチ処理する際の前提条件
デバイスによっては、AP が停止モードを完全に終了して FIFO のフラッシュを開始するまでに数ミリ秒かかる場合があります。したがって、ウェイクアップ FIFO をオーバーフローさせることなく、デバイスが停止モードを終了できるように、FIFO に十分なヘッドルームを割り当てる必要があります。イベントが失われることなく、max_report_latency が適用されます。
変化時モードの非ウェイクアップ センサーをバッチ処理する際の前提条件
変化時モードのセンサーは、測定値が変化したときにのみイベントを生成します。AP が停止モードにあるときに測定値が変化した場合、アプリは AP がウェイクアップするとすぐにイベントを受信することを期待します。そのため、変化時モードの非ウェイクアップ センサーが他のセンサーと FIFO を共有する場合、センサー イベントのバッチ処理は慎重に行う必要があります。変化時モードのセンサーで生成される最後のイベントは、常に共有 FIFO の外部に保存して、他のイベントで上書きされないようにする必要があります。AP がウェイクアップすると、FIFO 内のすべてのイベントをレポートした後、最後の変化時モードのセンサー イベントもレポートする必要があります。
次のような状況は避けます。
- アプリは、1 つの FIFO を同時に共有する非ウェイクアップ歩数計（変化時モード）と非ウェイクアップ加速度計（連続モード）に登録されます。
- アプリは歩数計イベント
step_count=1000 stepsを受け取ります。 - AP は停止モードに入ります。
- ユーザーが 20 歩を歩くと、歩数計と加速度計のイベントがインターリーブされます。最後の歩数計イベントは
step_count = 1020 stepsになります。 - ユーザーが長時間移動しないと、加速度計のイベントが FIFO に蓄積され続け、最終的に共有 FIFO の各
step_countイベントが上書きされます。 - AP はウェイクアップし、FIFO 内のすべてのイベントをアプリに送信します。
- このアプリは加速度計イベントのみを受信し、ユーザーが歩かなかったとみなします。
最後の歩数計イベントを FIFO の外部に保存することで、他のすべての歩数計イベントが加速度イベントによって上書きされた場合でも、AP がウェイクアップしたときにこのイベントをレポートできます。このように、AP がウェイクアップしたときにアプリケーションは step_count = 1020 steps を受け取ります。
バッチ処理の実装
電力を節約するには、AP を使用せずにバッチ処理を実装する必要があります。バッチ処理中は、AP を停止モードにする必要があります。
センサーハブでバッチ処理を実行する場合は、センサーハブの消費電力を最小限に抑える必要があります。
最大レポート レイテンシは、特に指定されたセンサーが有効になっている場合はいつでも変更できます。この操作によってイベントが失われることはありません。
FIFO 割り当ての優先度
ハードウェア FIFO やセンサーハブのバッファサイズが限られているプラットフォームでは、システム設計者は各センサー用に予約する FIFO スペースの量を選択しなければならない場合があります。この選択を容易にするために、各センサーでバッチ処理を実装するときに役立つ可能性のあるアプリのリストを以下に示します。
高値: 低消費電力の歩行者の推測航法
目標バッチ処理時間: 1～10 分
バッチ処理対象のセンサー:
- ウェイクアップ歩行検出機能
- ウェイクアップ ゲーム回転ベクトル（5 Hz）
- ウェイクアップ気圧計（5 Hz）
- 未校正の磁力計（5 Hz）
このようなデータをバッチ処理すると、AP が停止モードに入ったときに歩行者の推測航法を実施できます。
高値: 中程度の電力消費を伴う断続的な動作 / ジェスチャー認識
目標バッチ処理時間: 3 秒
バッチ処理対象のセンサー: 非ウェイクアップ加速度計（50 Hz）
このようなデータのバッチ処理では、データの収集中に AP をウェイクアップ状態にすることなく、任意のアクティビティやジェスチャーを定期的に認識できます。
中値: 中程度の電力消費を伴う連続的な動作 / ジェスチャー認識
目標バッチ処理時間: 1～3 分
バッチ処理対象のセンサー: ウェイクアップ加速度計（50 Hz）
このようなデータのバッチ処理では、データの収集中に AP をウェイクアップ状態にすることなく、任意のアクティビティやジェスチャーを連続的に認識できます。
中高値: 割り込みロードの減少
目標バッチ処理時間: 1 秒未満
バッチ処理対象センサー: 高周波数センサー（通常はウェイクアップ状態）。
ジャイロスコープが 240 Hz に設定されている場合、10 個のジャイロスコープ イベントをバッチ処理するだけで、1 秒あたりの割り込み数を 240 から 24 に減らせます。
中値: 連続的な低周波数データ収集
目標バッチ処理時間: 1～10 分
バッチ処理対象のセンサー:
- ウェイクアップ気圧計（1 Hz）
- ウェイクアップ湿度センサー（1 Hz）
- 同様の周波数の他の低周波ウェイクアップ センサー
低消費電力の監視アプリを作成できます。
中低値: 継続的で完全なセンサー収集
目標バッチ処理時間: 1～10 分
バッチ処理対象のセンサー: すべてのウェイクアップ センサー（高周波で動作する）
AP を停止モードのままにして、センサーデータを完全に収集できます。この方法は、FIFO スペースが問題にならない場合にのみ検討してください。