Android AlarmManager setExact() 不准确

本文介绍了Android AlarmManager setExact() 不准确的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我需要每 10 分钟计划一次安排好的任务.

I need to plan sheduled task every 10 minutes.

由于在 Lollipop 和更高版本中 setRepeating() 不准确，我使用 setExact() 并且(在警报触发时)我在 10 分钟内设置了新的精确警报.

As in Lollipop and higher version setRepeating() is inexact, I use setExact() and (on alarm firing) I set new exact alarm in 10 minutes.

private void setAlarm(long triggerTime, PendingIntent pendingIntent) { int ALARM_TYPE = AlarmManager.ELAPSED_REALTIME_WAKEUP; if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { alarmManager.setExact(ALARM_TYPE, triggerTime, pendingIntent); } else { alarmManager.set(ALARM_TYPE, triggerTime, pendingIntent); } }

triggerTime 计算 SystemClock.elapsedRealtime() + 600_000;

当警报响起时，我首先计划新的，然后才运行我的计划任务.

When alarm fires, firstly I plan new one, only after that I run my sheduled task.

setAlarm(); mySheduledTask;

我的清单中确实有 WAKE_LOCK 权限.

I do have WAKE_LOCK permission in my manifest.

当我在 Android 4 上测试时 - 它运行良好(偏差可能为 12-15 毫秒).

When I test this on Android 4 - it works perfect (deviation might be 12-15 milliseconds).

但是当我在小米红米 Note 3 Pro (5.1.1) 上运行应用程序时 - 偏差可达 15 秒！

But when I run app on Xiaomi Redmi Note 3 Pro (5.1.1) - deviation can be up to 15 seconds!

例如，我在日志文件中看到:第一次运行是在 1467119934477(RTC 时间)，第二次是在 1467120541683.差异是 607_206 毫秒，而不是 600_000，正如计划的那样！

For example, I see in my log file: first run was at 1467119934477 (of RTC time), second - at 1467120541683. Difference is 607_206 milliseconds, not 600_000, as it was planned!

我错过了什么?有什么方法可以模拟系统警报的行为(这是可以描述我的策略的最接近用例)?

What am I missing? What is a way to simulate behaviour of system alarm (it's the most close usecase that can describe my tack)?

PS. 我将 IntentService 用于 PendingIntent = PendingIntent.getService(context, 0, myIntent, 0);

PS. I use IntentService for PendingIntent = PendingIntent.getService(context, 0, myIntent, 0);

推荐答案

操作系统会根据您指定的时间来选择警报的工作方式.正因为如此，当手机进入半睡眠"模式时，它不需要在您希望的时候使用资源.基本上，它会等待操作系统为其打开的窗口"，然后才会运行您想要运行的警报，这就是您遇到时间间隔的原因.

The OS chooses how the alarms will work, with consideration of the time you've specified. Because of that, when the phone gets into a 'semi-sleep' mode, it won't necessary use the resource at the time you wish it to. Basically, it waits for 'windows' that the OS opens for it, and only then the alarm you want to run will run, that's why you're experiencing time gaps.

这是在 Marshmallow OS 上引入的，并将在 Nougat OS 上继续使用，作为 Google 试图改善设备电池的一部分.

This was introduced on Marshmallow OS and will continue on Nougat OS as well, as part of Google trying to improve the device's battery.

事情就是这样，你有两个选择:

Here's the thing, you have 2 options:

接受时间延迟(但可以考虑使用JobScheduler 更值得推荐，可以节省电池电量).

使用 setExactAndAllowWhileIdle 这可能会导致你的电池问题(小心使用这个，太多的警报会对你的电池有害).此方法不会重复，因此您必须声明下一个作业要在 pendingIntent 打开的服务上运行.

如果您选择选项 2，则开始:

If you choose option 2, here's the start:

AlarmManager am = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE); int ALARM_TYPE = AlarmManager.RTC_WAKEUP; if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) am.setExactAndAllowWhileIdle(ALARM_TYPE, calendar.getTimeInMillis(), pendingIntent); else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) am.setExact(ALARM_TYPE, calendar.getTimeInMillis(), pendingIntent); else am.set(ALARM_TYPE, calendar.getTimeInMillis(), pendingIntent);