Android AlarmManager以较小的间隔触发太不可预测。接近预期时间的最小合理间隔是多少？

Question

首先，我知道有关此的其他问题，例如： 在 Android 5.1 中每秒调度闹钟 或 如何使用安卓警报管理器，间隔小，如1分钟？

因此，它基本上说，由于系统优化，这种间隔小的行为符合预期。但什么是小的？它谈论的是每隔几秒钟设置一次闹钟。但是几分钟呢？同样的问题？什么间隔的开始行为更接近预期时间？小时？日？这些似乎在谈论使用setRepeating设置重复间隔。

这就是我正在努力解决的问题。我正在尝试每 5 分钟(300000 毫秒(设置一次警报，这仍然太小了吗？我正在尝试通过set甚至setExact或setWindow来做到这一点。在第一个警报触发后，我设置了 300000 毫秒的新警报。 这是我最初设置的方式：

//initially somewhere I call:
IntervalScheduler.createAlarm(context!!, 300000)
...
//which is this:
object IntervalScheduler
{
fun createAlarm(ctx: Context, milliseconds: Long)
{
val intent = Intent(ctx, AlarmReceiver::class.java)
val alarmManager = ctx.getSystemService(Context.ALARM_SERVICE) as AlarmManager
val pendingIntent = PendingIntent.getBroadcast(ctx, 0, intent, PendingIntent.FLAG_CANCEL_CURRENT)
if (Build.VERSION.SDK_INT >= KITKAT)
{
// doesn't help
//alarmManager.setExact(AlarmManager.RTC_WAKEUP, milliseconds, 60000, pendingIntent)
// this doesn't help as well - trying to give it a window of 1 minute
alarmManager.setWindow(AlarmManager.RTC_WAKEUP, milliseconds, 60000, pendingIntent) // doesn't help
}
else
{
alarmManager.set(AlarmManager.RTC_WAKEUP, milliseconds, pendingIntent)
}
}
}
// this gets called fine
class AlarmReceiver: BroadcastReceiver()
{
override fun onReceive(context: Context?, intent: Intent?)
{
Log.i("NOTE","Notifying")
// create next alarm
IntervalScheduler.createAlarm(context!!, 300000)
}
}

以下是结果日志：

09-21 22:21:53.846 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:22:54.812 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:23:55.023 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:24:00.655 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:24:06.085 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:24:11.616 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:24:17.193 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:24:22.674 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:24:28.164 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:24:33.852 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:25:34.815 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:26:57.604 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:28:14.842 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:29:14.968 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:30:15.275 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:31:15.459 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:32:15.644 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:33:15.834 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:34:15.941 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:35:16.143 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:36:17.804 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:37:17.969 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:37:23.686 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:37:29.131 26982-26982/com.sykes I/NOTE: Notifying
09-21 22:37:34.749 26982-26982/com.sykes I/NOTE: Notifying

不到5分钟。事实上，它很少超过一分钟。 就像最近 4 个电话在同一分钟内发生一样。系统有时将 5 分钟优化为 6-5 秒？

这还如预期的那样吗？如果设置为 3600000(1 小时(还是 86400000(24 小时(？

Answer 1

发现我做错了什么。我正在调用带有警报类型RTC_WAKEUP的set(和所有其他变体(并传递它 300000(5 分钟(。我没有意识到警报预计何时应该以毫秒为单位触发。我一直在想，从现在开始等待是毫秒数。 所以之前是：

alarmManager.set(AlarmManager.RTC_WAKEUP, milliseconds, pendingIntent)

修复是：

alarmManager.set(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + milliseconds, pendingIntent)

请注意。这并不意味着我让它在短时间内工作得很好。我让它一般工作 - 即使是长时间的间隔。

附言。我不知道这对于堆栈溢出是否有用。