批次處理

什麼是批次處理？

批次處理是指在透過感測器 HAL報告事件之前在感測器集線器和/或硬體 FIFO 中緩衝感測器事件。緩衝感測器事件的位置（感測器集線器和/或硬體 FIFO）在此頁面上稱為「FIFO」。當感測器事件批次未啟動時，感測器事件會立即報告給感測器 HAL（如果可用）。

注意：批次和感測器 HAL 的batch()函數雖然相關，但是獨立的概念。批次處理是指緩衝感測器事件以節省電量。 batch()函數用於配置感測器的報告頻率以及事件產生和報告給感測器 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

注意：此合約僅在 HAL 層級有效，該等級始終只有一個客戶端。在 SDK 級別，由於框架中的複用，應用程式可能會獲得不同的速率。有關更多詳細信息，請參閱框架。

最大報告延遲時間

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 空間是否不是問題。