Android AlarmManager setExact()不精确 [英] Android AlarmManager setExact() is not exact

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

问题描述

我需要每10分钟计划一次任务。

I need to plan sheduled task every 10 minutes.

就像棒棒糖和更高版本中的 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).

但是当我在小米Redmi 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);

推荐答案

操作系统选择警报的工作方式,考虑你的时间e指定。因此,当手机进入半睡眠模式时,您无需在需要时使用该资源。基本上,它会等待操作系统为其打开的窗口,然后才运行您要运行的警报,这就是您遇到时间间隔的原因。

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.

在这里,您有2个选择:

Here's the thing, you have 2 options:


  1. 接受时间延迟(但可以考虑使用 JobScheduler ,我们建议您使用它,这样可以节省电池)。

  2. 使用 setExactAndAllowWhileIdle 可能会导致电池问题(请谨慎使用,过多的警报将对电池不利)。
    此方法不再重复,因此您必须声明下一个要在未完成的Intent打开的服务上运行的作业。

  1. Accept the time delays (but maybe consider using JobScheduler which is more recommended and will save you battery).
  2. Use setExactAndAllowWhileIdle which might cause you battery issues (use this carefully, too many alarms will be bad for your battery). This method isn't repeating, so you have to declare the next job to be run at the service which the pendingIntent opens.

如果选择选项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);

这篇关于Android AlarmManager setExact()不精确的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆