批次處理

什麼是批次處理？

在透過 Sensors HAL 回報事件之前，將感應器事件緩衝在感應器中樞和/或硬體 FIFO 中，稱為「分批處理」。在本頁中，將感應器事件緩衝區 (感應器中樞和/或硬體 FIFO) 稱為「FIFO」。當感應器事件批次處理功能未啟用時，感應器事件會在可用時立即回報至 Sensors HAL。

當許多感應器事件準備好處理時，只喚醒執行 Android 的主要應用程式處理器 (AP)，而非為每個個別事件喚醒 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 回報的時間。

sampling_period_ns

sampling_period_ns 參數的含意取決於指定感應器的回報模式：

  • 持續：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

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 未進入暫停模式，就不會遺漏或遺失任何事件。如果內部 FIFO 在 max_report_latency 到期前已滿，系統會在該時刻回報事件，確保不會遺漏任何事件。

如果多個感應器共用同一個 FIFO，且其中一個感應器的 max_report_latency 已過期，系統會回報 FIFO 中的所有事件，即使其他感應器的 max_report_latency 尚未過期也一樣。這樣一來，系統就會減少回報事件批次的次數。當系統必須回報一項事件時，就會回報所有感應器的所有事件。

舉例來說，如果啟用了下列感應器：

  • max_report_latency = 20 秒的加速度計批次
  • 陀螺儀以 max_report_latency = 5 秒的間隔批次處理

即使加速計和陀螺儀不共用相同的 FIFO，加速計批次也會在陀螺儀批次回報的同時 (每 5 秒) 回報。

暫停模式中的行為

在背景中收集感應器資料時，不必讓 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 會先由喚醒事件喚醒。

批次喚醒感應器的注意事項

視裝置而定，AP 可能需要幾毫秒的時間才能完全退出暫停模式，並開始清除 FIFO。您必須在 FIFO 中分配足夠的空間，讓裝置可從暫停模式中退出，且不會導致喚醒 FIFO 溢位。不得遺漏任何事件，且必須遵守 max_report_latency。

批次處理非喚醒型感應器時的注意事項

當變更感應器所測量到的值發生變化時，才會產生事件。如果在 AP 處於暫停模式時，測量值發生變更，應用程式會預期在 AP 喚醒後立即收到事件。因此，如果感應器與其他感應器共用 FIFO，就必須謹慎執行非喚醒的變更感應器事件批次處理作業。每個變化感應器產生的最後事件，都必須儲存在共用 FIFO 之外，這樣才不會遭到其他事件覆寫。當 AP 喚醒時，在回報 FIFO 的所有事件後，必須回報最後一個感應器事件。

以下是應避免的情況：

  1. 應用程式會註冊非喚醒步數計數器 (變更時) 和非喚醒加速計 (持續)，兩者共用相同的 FIFO。
  2. 應用程式收到計步器事件 step_count=1000 stepscode>。
  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 空間不是問題時，才考慮使用此方法。