2
使用AlarmManager
設置鬧鐘時,除非您設置了確切的鬧鐘,否則可能會延遲鬧鐘在指定時間之後的某個時間觸發。這種延遲的範圍可能會有什麼保證嗎?我想成爲一名負責任的開發人員,如果延遲時間不超過一分鐘,就不要使用確切的時間。但是我找不到關於文檔延遲的任何規範。我將不勝感激資源,記錄如何延遲功能及其時間規格。當通過AlarmManager設置不精確的警報時,有多少延遲?
使用AlarmManager
設置鬧鐘時,除非您設置了確切的鬧鐘,否則可能會延遲鬧鐘在指定時間之後的某個時間觸發。這種延遲的範圍可能會有什麼保證嗎?我想成爲一名負責任的開發人員,如果延遲時間不超過一分鐘,就不要使用確切的時間。但是我找不到關於文檔延遲的任何規範。我將不勝感激資源,記錄如何延遲功能及其時間規格。當通過AlarmManager設置不精確的警報時,有多少延遲?
重複間隔[對於週期性警報]或從現在到所需交付時間的時間的75%,最小延遲/間隔爲10秒,我們不會推遲警報。
從Android源AlarmManagerService爲API19(現在仍然一樣API23的)
Requested Batch Window 1 Mins -> 1- 1¾ Mins 10 Mins -> 10-17½ Mins 30 Mins -> 30-52½ Mins 1 Hour -> 1- 1¾ Hours
另外值得一提的是,雖然AlarmManagerService守衛窗口長度,確保長度超過半天更大被視爲懷疑(並重寫爲1小時),但它不提供類似的觸發時間的完整性檢查。
因此,您可以輕鬆地提供基於經過時間模式(ELAPSED_REALTIME)的基於RTC的值(System.currentTimeMillis()),並以未來數千年的報警結束。
這是基於官方文檔嗎?那麼其他版本的android呢?我可以肯定,在所有Android版本中,我的重複鬧鐘不會超過其時間間隔的75%?它是爲setInexactRepeating()還是setRepeating()? –
這是基於Android的源代碼(見我的答案鏈接) - 這是最權威的文檔存在;) 正如上面提到的,這個功能是從API19至23不變,並快速檢查表明,同樣的功能不變通過爲[API 25](http://androidxref.com/7.1.1_r6/xref/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java#708) –
感謝你的快速回答。你沒有在你的回答中提到你正在談論setInexactRepeating()或setRepeating() –