AlarmMgr触发有时正确有时错误,为什么?
AlarmMgr triggered sometime correct and sometimes wrong, Why?
我这样设置 alarmMgr:
alarmMgr.setRepeating(AlarmManager.RTC, calendar.getTimeInMillis(),
1000 * 60 * 5L, alarmIntent)
和 BroadcastReceiver 输出
public class BroadcastReciever extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
System.out.println("Execute time:" + Calendar.getInstance().getTime());
}...}
我昨天得到了正确的日志,然后就出错了。看起来好像同时触发了很多次警报,我不知道 why.I 猜测可能是 android studio logcatch 有一些未知的机制。
2022-04-14 10:44:40.447 8663-8663/com.example.ss I/System.out: ...
2022-04-14 10:46:40.441 8663-8663/com.example.ss I/System.out: ...
2022-04-14 10:48:40.440 8663-8663/com.example.ss I/System.out: ...
2022-04-14 10:50:40.444 8663-8663/com.example.ss I/System.out: ...
2022-04-14 10:52:40.446 8663-8663/com.example.ss I/System.out: ...
赶了一晚上的日志,下面是部分日志。
系统日志显示在这里,
2022-04-15 07:33:39.945 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 07:33:39 GMT+09:00 2022
2022-04-15 07:33:39.951 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 07:33:39 GMT+09:00 2022
2022-04-15 07:33:39.954 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 07:33:39 GMT+09:00 2022
2022-04-15 07:33:39.960 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 07:33:39 GMT+09:00 2022
2022-04-15 07:33:39.963 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 07:33:39 GMT+09:00 2022
2022-04-15 07:33:39.966 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 07:33:39 GMT+09:00 2022
2022-04-15 07:33:39.969 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 07:33:39 GMT+09:00 2022
2022-04-15 07:35:40.066 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 07:35:40 GMT+09:00 2022
2022-04-15 08:40:40.096 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 08:40:40 GMT+09:00 2022
2022-04-15 08:40:40.103 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 08:40:40 GMT+09:00 2022
2022-04-15 08:40:40.106 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 08:40:40 GMT+09:00 2022
关于方法(inexact/actual次),官方页面说系统会同时触发一些警报以节省电池,警报统计显示,all.I没有关闭警报有时得到正确的输出。我也每隔 15 分钟测试一次方法,输出仍然是 wrong.I 不要认为原因是方法不准确。
Alarm Stats:
1000:android +6s300ms running, 353 wakeups:
+3s273ms 0 wakes 40 alarms, last -4m9s148ms:
alarm:com.android.server.action.NETWORK_STATS_POLL
+2s837ms 0 wakes 226 alarms, last -4m9s148ms:
alarm:TIME_TICK
+699ms 347 wakes 347 alarms, last -1h41m9s348ms:
walarm:job.delay
+102ms 0 wakes 1 alarms, last -4m9s148ms:
alarm:GraphicsStatsService
+60ms 2 wakes 2 alarms, last -2h14m49s133ms:
walarm:ScheduleConditionProvider.EVALUATE
+31ms 0 wakes 1 alarms, last -8h39m9s148ms:
alarm:android.intent.action.DATE_CHANGED
+9ms 1 wakes 1 alarms, last -13h27m11s167ms:
walarm:JS idleness
+8ms 1 wakes 1 alarms, last -19h41m4s292ms:
walarm:RETRY
+6ms 2 wakes 2 alarms, last -17h41m9s348ms:
walarm:job.deadline
u0a40:com.android.providers.calendar +364ms running, 4 wakeups:
+364ms 4 wakes 4 alarms, last -1h39m9s148ms:
walarm:com.android.providers.calendar.intent.CalendarProvider2
u0a89:com.android.systemui +470ms running, 27 wakeups:
+470ms 27 wakes 27 alarms, last -14h38m7s109ms:
walarm:com.android.internal.policy.impl.PhoneWindowManager.DELAYED_KEYGUARD
u0a113:com.example.ss +4s532ms running, 0 wakeups:
+4s532ms 0 wakes 185 alarms, last -4m9s148ms:
alarm:com.example.ss/.BroadcastReciever`
- 从 API 19 开始,所有重复的警报都不准确。如果您的应用程序需要精确的交付时间,那么它必须使用 one-time 精确的警报,每次重新安排如上所述。 targetSdkVersion 早于 API 19 的旧版应用程序将继续将所有警报(包括重复警报)视为精确警报。
- 因此,如果您想实现精确的重复警报,请使用 AlarmManager.setExact() 并重新安排
- 参考google
我这样设置 alarmMgr:
alarmMgr.setRepeating(AlarmManager.RTC, calendar.getTimeInMillis(),
1000 * 60 * 5L, alarmIntent)
和 BroadcastReceiver 输出
public class BroadcastReciever extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
System.out.println("Execute time:" + Calendar.getInstance().getTime());
}...}
我昨天得到了正确的日志,然后就出错了。看起来好像同时触发了很多次警报,我不知道 why.I 猜测可能是 android studio logcatch 有一些未知的机制。
2022-04-14 10:44:40.447 8663-8663/com.example.ss I/System.out: ...
2022-04-14 10:46:40.441 8663-8663/com.example.ss I/System.out: ...
2022-04-14 10:48:40.440 8663-8663/com.example.ss I/System.out: ...
2022-04-14 10:50:40.444 8663-8663/com.example.ss I/System.out: ...
2022-04-14 10:52:40.446 8663-8663/com.example.ss I/System.out: ...
赶了一晚上的日志,下面是部分日志。 系统日志显示在这里,
2022-04-15 07:33:39.945 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 07:33:39 GMT+09:00 2022
2022-04-15 07:33:39.951 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 07:33:39 GMT+09:00 2022
2022-04-15 07:33:39.954 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 07:33:39 GMT+09:00 2022
2022-04-15 07:33:39.960 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 07:33:39 GMT+09:00 2022
2022-04-15 07:33:39.963 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 07:33:39 GMT+09:00 2022
2022-04-15 07:33:39.966 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 07:33:39 GMT+09:00 2022
2022-04-15 07:33:39.969 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 07:33:39 GMT+09:00 2022
2022-04-15 07:35:40.066 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 07:35:40 GMT+09:00 2022
2022-04-15 08:40:40.096 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 08:40:40 GMT+09:00 2022
2022-04-15 08:40:40.103 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 08:40:40 GMT+09:00 2022
2022-04-15 08:40:40.106 13580-13580/com.example.ss I/System.out: Execute time:Fri Apr 15 08:40:40 GMT+09:00 2022
关于方法(inexact/actual次),官方页面说系统会同时触发一些警报以节省电池,警报统计显示,all.I没有关闭警报有时得到正确的输出。我也每隔 15 分钟测试一次方法,输出仍然是 wrong.I 不要认为原因是方法不准确。
Alarm Stats:
1000:android +6s300ms running, 353 wakeups:
+3s273ms 0 wakes 40 alarms, last -4m9s148ms:
alarm:com.android.server.action.NETWORK_STATS_POLL
+2s837ms 0 wakes 226 alarms, last -4m9s148ms:
alarm:TIME_TICK
+699ms 347 wakes 347 alarms, last -1h41m9s348ms:
walarm:job.delay
+102ms 0 wakes 1 alarms, last -4m9s148ms:
alarm:GraphicsStatsService
+60ms 2 wakes 2 alarms, last -2h14m49s133ms:
walarm:ScheduleConditionProvider.EVALUATE
+31ms 0 wakes 1 alarms, last -8h39m9s148ms:
alarm:android.intent.action.DATE_CHANGED
+9ms 1 wakes 1 alarms, last -13h27m11s167ms:
walarm:JS idleness
+8ms 1 wakes 1 alarms, last -19h41m4s292ms:
walarm:RETRY
+6ms 2 wakes 2 alarms, last -17h41m9s348ms:
walarm:job.deadline
u0a40:com.android.providers.calendar +364ms running, 4 wakeups:
+364ms 4 wakes 4 alarms, last -1h39m9s148ms:
walarm:com.android.providers.calendar.intent.CalendarProvider2
u0a89:com.android.systemui +470ms running, 27 wakeups:
+470ms 27 wakes 27 alarms, last -14h38m7s109ms:
walarm:com.android.internal.policy.impl.PhoneWindowManager.DELAYED_KEYGUARD
u0a113:com.example.ss +4s532ms running, 0 wakeups:
+4s532ms 0 wakes 185 alarms, last -4m9s148ms:
alarm:com.example.ss/.BroadcastReciever`
- 从 API 19 开始,所有重复的警报都不准确。如果您的应用程序需要精确的交付时间,那么它必须使用 one-time 精确的警报,每次重新安排如上所述。 targetSdkVersion 早于 API 19 的旧版应用程序将继续将所有警报(包括重复警报)视为精确警报。
- 因此,如果您想实现精确的重复警报,请使用 AlarmManager.setExact() 并重新安排
- 参考google