android - 如何在Android服务上实现准确的(精确到秒)计时

Question

我正在制作一个按时间间隔执行的应用程序。更新之间我可以等待的绝对最长时间是30秒，介于0和0之间的任何值都是可以接受的，但是我希望15秒是一个很好的衡量标准。但是，它并不像听起来那样容易。我尝试了4种方法，由于种种原因，所有这些方法都 Not Acceptable 。

请记住，这些问题在Service中发生，当此代码在Activity中运行时，它运行良好。我还注意到，将手机插入计算机进行调试时，解决方案3可以正常运行，直到我将其插入为止。我检查了电池设置，没有省电模式或类似的其他内容，这可能是造成这种情况的原因。

1.会执行填充操作的IntentService，然后在15秒内重新安排自身的时间。不幸的是，当涉及到准确的警报时，AlarmManager.setExact()完全不可靠，正如我在此风滚草中所描述的:Android Alarm not triggering at exact time

2.具有Thread的前景服务。在那个线程中，我做我的事情，然后sleep() 15秒钟。事实证明，此方法比以前更糟，该线程在正确的时间之后最多5分钟被唤醒。

3.然后我尝试使用Timer(如geokavel建议)，并使用scheduleAtFixedRate和schedule安排工作，但工作进行得太晚了15-45秒，使间隔大约为1分钟而不是15秒。

4.我想到的最后一种方法是不要从上方进入前台服务的Thread。相反，我比较时间:

public void run(){
    nextTime = System.currentTimeMillis() + sleep;
    while (true){
        if (System.currentTimeMillis() >= nextTime) {
            nextTime = System.currentTimeMillis() + sleep;
            //do stuff
        }
    }
}

除了主要缺点之外，此方法的工作原理很吸引人-它始终使用20-25％的CPU。

所以我的问题是，有没有办法使上述解决方案能够正常工作(没有不利的缺点)？如果没有，有没有我错过的更好的方法？如有需要，请随时询问更多详细信息。

编辑:请求的run()代码:

public void run(){
    try {
        if (Thread.currentThread().isInterrupted()){
            throw new InterruptedException();
        }
        NetworkInfo info = cm.getActiveNetworkInfo();
        if (info == null) {
            throw new UnknownHostException();
        }
        if (info.getType() == ConnectivityManager.TYPE_MOBILE) {
            Log.i(TAG, "Won't use mobile connection");
            throw new UnknownHostException();
        } else {
            internetRestored();
            st.updateData();
        }
    } catch (MalformedURLException | UnknownHostException e) {
        internetFailed();
        Log.e(TAG, "No internet connection, cant log");
    } catch (IOException e) {
        e.printStackTrace();
    } catch (InterruptedException e) {
        Log.i(TAG, "Thread iterrupted");
    }
}

Answer 1

您将目标/编译为哪个API？

编辑: checkout 处理程序:

https://developer.android.com/reference/android/os/Handler.html

There are two main uses for a Handler: (1) to schedule messages and runnables to be executed as some point in the future; and (2) to enqueue an action to be performed on a different thread than your own. ... When posting or sending to a Handler, you can either allow the item to be processed as soon as the message queue is ready to do so, or specify a delay before it gets processed or absolute time for it to be processed. The latter two allow you to implement timeouts, ticks, and other timing-based behavior.

我在这里看不到任何有关特定时间的警告，因此可能是一个不错的选择。

一些有趣的文档:

https://developer.android.com/reference/android/app/AlarmManager.html

Otherwise, the alarm will be set as though the application had called setRepeating(int, long, long, PendingIntent). As of API 19, all repeating alarms will be inexact and subject to batching with other alarms regardless of their stated repeat interval.

来自警报管理器的更多信息:

Note: Beginning with API 19 (KITKAT) alarm delivery is inexact: the OS will shift alarms in order to minimize wakeups and battery use. There are new APIs to support applications which need strict delivery guarantees; see setWindow(int, long, long, PendingIntent) and setExact(int, long, PendingIntent). Applications whose targetSdkVersion is earlier than API 19 will continue to see the previous behavior in which all alarms are delivered exactly when requested.

https://developer.android.com/reference/java/lang/Thread.html

Causes the thread which sent this message to sleep for the given interval of time (given in milliseconds and nanoseconds). The precision is not guaranteed - the Thread may sleep more or less than requested.

计时器:

This class does not offer guarantees about the real-time nature of task scheduling.

ScheduledThreadPoolExecutor

Delayed tasks execute no sooner than they are enabled, but without any real-time guarantees about when, after they are enabled, they will commence. Tasks scheduled for exactly the same execution time are enabled in first-in-first-out (FIFO) order of submission.

一些想法:

根据我所见，最好的选择是降低targetAPI <19并使用Alarm Manager。

如果那不起作用，我的下一个最佳选择是thread.sleep()，同时使用Thread.setPriority()将线程的执行优先级设置为尽可能高。

未能通过研究来减少您的实时需求的方法-现实情况是android处理处理器时间的方式很复杂，并且并非真正打算成为实时系统。

如果您确实需要非常精确的时序，则可以探索C并尝试在AudioFastPath中执行代码，以使您在处理器时间上的可能规律性最大化。多数民众赞成在杀害那是wayyyyy。