配料

什麼是批處理？

批處理是指在通過傳感器 HAL報告事件之前，在傳感器集線器和/或硬件 FIFO 中緩衝傳感器事件。緩存傳感器事件的位置（傳感器集線器和/或硬件 FIFO）在本頁中稱為“FIFO”。當傳感器事件批處理未激活時，傳感器事件會在可用時立即報告給 Sensors 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 報告非喚醒事件。

配料參數

控制批處理行為的兩個參數是sampling_period_ns和max_report_latency_ns 。 sampling_period_ns確定生成新傳感器事件的頻率， max_report_latency_ns確定必須將事件報告給 Sensors HAL 的時間。

採樣週期_ns

sampling_period_ns參數的含義取決於指定傳感器的報告模式：

• 連續： sampling_period_ns是採樣率，表示事件產生的速率。
• On-change： 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 。

物理傳感器有時會限制它們的運行速率和時鐘的準確性。考慮到這一點，實際採樣頻率可以與請求的頻率不同，只要它滿足下表中的要求即可。

max_report_latency_ns

max_report_latency_ns設置以納秒為單位的最長時間，通過該時間可以延遲事件並將其存儲在硬件 FIFO 中，然後在 AP 喚醒時通過 HAL 進行報告。

零值表示必須在測量事件後立即報告事件，要么完全跳過 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 提交事件的行為；來自不同傳感器的事件可以交錯，來自同一傳​​感器的所有事件都是按時間排序的。

喚醒和非喚醒事件

來自喚醒傳感器的傳感器事件必須存儲在一個或多個喚醒 FIFO 中。一種常見的設計是有一個單一的、大的、共享的喚醒 FIFO，來自所有喚醒傳感器的事件在其中交錯。或者，您可以為每個傳感器設置一個喚醒 FIFO，或者為特定喚醒傳感器設置專用 FIFO，為其餘喚醒傳感器設置共享 FIFO。

同樣，來自非喚醒傳感器的傳感器事件必須存儲在一個或多個非喚醒 FIFO 中。

在所有情況下，喚醒傳感器事件和非喚醒傳感器事件都不能在同一個 FIFO 中交錯。喚醒事件必須存儲在喚醒 FIFO 中，非喚醒事件必須存儲在非喚醒 FIFO 中。

對於喚醒 FIFO，單個、大型、共享的 FIFO 設計提供了最佳的功耗優勢。對於非喚醒 FIFO，單個大型共享 FIFO 和幾個小型預留 FIFO 設計具有相似的功率特性。有關如何配置每個 FIFO 的更多建議，請參閱FIFO 分配優先級。

掛起模式之外的行為

當 AP 處於喚醒狀態（未處於掛起模式）時，只要事件的延遲時間不超過max_report_latency ，它們就會臨時存儲在 FIFO 中。

只要 AP 不進入掛起模式，就不會丟棄或丟失任何事件。如果在max_report_latency過去之前內部 FIFO 已滿，則在該點報告事件以確保不會丟失任何事件。

如果多個傳感器共享同一個 FIFO 並且其中一個傳感器的max_report_latency已過，則報告 FIFO 中的所有事件，即使其他傳感器的max_report_latency尚未過期。這減少了報告事件批次的次數。當必須報告一個事件時，將報告來自所有傳感器的所有事件。

例如，如果以下傳感器被激活：

• 加速度計批處理max_report_latency = 20s
• 使用max_report_latency = 5s 批處理的陀螺儀

加速度計批次在報告陀螺儀批次的同時報告（每 5 秒），即使加速度計和陀螺儀不共享同一個 FIFO。

掛起模式下的行為

批處理對於在後台收集傳感器數據而不保持 AP 喚醒特別有益。因為傳感器驅動程序和 HAL 實現不允許持有喚醒鎖*，所以即使正在收集傳感器數據，AP 也可以進入掛起模式。

AP 掛起時傳感器的行為取決於傳感器是否為喚醒傳感器。有關更多詳細信息，請參閱喚醒傳感器。

當非喚醒 FIFO 填滿時，它必須環繞並表現得像一個循環緩衝區，用新事件替換舊事件覆蓋舊事件。 max_report_latency在掛起模式下對非喚醒 FIFO 沒有影響。

當喚醒 FIFO 填滿，或者當喚醒傳感器之一的max_report_latency時，硬件必須喚醒 AP 並報告數據。

在這兩種情況下（喚醒和非喚醒），只要 AP 退出掛起模式，就會生成包含所有 FIFO 內容的批次，即使某些傳感器的max_report_latency尚未過去。這最大限度地降低了 AP 在返回掛起模式後必須再次喚醒的風險，因此最大限度地降低了功耗。

* 不允許驅動程序持有喚醒鎖的一個值得注意的例外是，當max_report_latency < 1 秒激活具有連續報告模式的喚醒傳感器時。在這種情況下，驅動程序可以保持喚醒鎖定，因為 AP 沒有時間進入掛起模式，因為它會在達到掛起模式之前被喚醒事件喚醒。

批量喚醒傳感器時的注意事項

根據設備的不同，AP 可能需要幾毫秒才能完全退出掛起模式並開始刷新 FIFO。必須在 FIFO 中分配足夠的空間以允許設備退出掛起模式而不會溢出喚醒 FIFO。不得丟失任何事件，並且必須遵守max_report_latency 。

對非喚醒變化傳感器進行批處理時的注意事項

變化傳感器僅在它們測量的值發生變化時才生成事件。如果在 AP 處於掛起模式時測量值發生變化，則應用程序希望在 AP 喚醒後立即收到事件。因此，如果傳感器與其他傳感器共享其 FIFO，則必須仔細執行非喚醒變化傳感器事件的批處理。每個 on-change 傳感器生成的最後一個事件必須始終保存在共享 FIFO 之外，因此它永遠不會被其他事件覆蓋。當 AP 喚醒時，在報告了 FIFO 中的所有事件之後，必須報告最後一個 on-change 傳感器事件。

這是要避免的情況：

1. 應用程序註冊到非喚醒計步器（on-change）和非喚醒加速度計（連續），兩者共享相同的 FIFO。
2. 應用程序接收到計步器事件step_count=1000 steps碼>。
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 和/或傳感器集線器緩衝區大小有限的平台上，系統設計人員可能必須選擇為每個傳感器保留多少 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 空間是否不是問題。