3

我有一个负责更新时钟并在不同时间执行特定任务（如播放歌曲）的 android 服务。我尝试使用 Timer.scheduleAtFixedRate(new MyTask(), 0, 1000L) 之类的东西，但我在 1 小时内延迟了 4 分钟以上。现在我决定：
1) 在 var long expectedtNextSystemMilli 中使用 System.currentTimeMillis() 记录开始时间
2) 将 1 秒 (1000 ms) 添加到此 var 以获取下一个日期/时间以再次执行任务
3) 在可运行文件中任务计算“实际系统时间”和来自 var 的预期时间之间的延迟，以安排任务的下一次执行。

经过几次测试，我注意到还有一个延迟问题，并在文档中阅读到不鼓励使用 System.currentTimeMillis() 来测量经过的时间，我们必须使用 SystemClock.elapsedRealtime()。我也做到了，下面是 MyTask 的代码

private class MyTask extends TimerTask {
@Override
public void run() {
    Log.i(TAG, "Timer doing work.");
    try {

        // compute the exact next expected system time when MyTask must be executed 
        expectedtNextSystemMilli += 1000L; 

        long delay = expectedtNextSystemMilli - SystemClock.elapsedRealtime() ;

        // countdown update
        counter = counter - 1;

        // !!! sometimes android system is slow and more than 1s is spend before this method is called
        // also we have to test and loop to catch up the delay
        while ( delay < 0){
            Log.e("TimerTick", "ERROR time spent by system in milli = " + delay + "> 1s ");
            expectedtNextSystemMilli += 1000L; 
            delay = expectedtNextSystemMilli - SystemClock.elapsedRealtime() ;
            counter = counter - 1;
        }

        // test if countdown is finished
        if ( counter <=0 ){

            mTimer.cancel();
            onFinish();

        }else{

            // send message to listeners
            onTick(counter);

            // update the delay with the new system time (in case the call to onTick has been long)
            delay = expectedtNextSystemMilli - SystemClock.elapsedRealtime() ;

            // schedule the next execution of this task
            mTimer.schedule(new MyTask(), delay);
            Log.d("TimerTick", "new delay in milli is " + delay+", elapsedRealtime = "+ SystemClock.elapsedRealtime() );
        }

    } catch (Throwable t) { //you should always ultimately catch all exceptions in timer tasks.
        Log.e("TimerTick", "Timer Tick Failed. Raison: "+ t.getMessage());            
    }
}       
}

跟踪这段代码，我惊讶地发现 SystemClock.elapsedRealtime() 返回了 28 秒的跳跃，如您所见

07-13 22:15:00.041：V/TimerManagerService（19377）：onTick 延迟 = 361 结束，跟踪 = 539
07-13 22:15:00.041：D/TimerTick（19377）：以毫秒为单位的新延迟为 999，elapsedRealtime = 84800078
07-13 22:15:01.041: I/TimerManagerService(19377): 定时器工作。
07-13 22:15:01.041: E/TimerTick(19377): 系统花费的错误时间毫秒 = -28585> 1s
07-13 22:15:01.041: E/TimerTick(19377): 系统花费的错误时间毫 = -27585> 1s
07-13 22:15:01.041：E/TimerTick(19377)：系统花费的错误时间，单位为毫 = -26586> 1s
07-13 22:15:01.041：E/TimerTick(19377)：系统花费的错误时间（以毫秒为单位）= -25586> 1s
07-13 22:15:01.041：E/TimerTick（19377）：系统花费的错误时间（以毫秒为单位）= -23587> 1s
07-13 22:15:01.041: E/TimerTick(19377): 系统花费的错误时间毫秒 = -22587> 1s
07-13 22:15:01.041: E/TimerTick(19377): 系统花费的错误时间毫 = -21588> 1s
07-13 22:15:01.041：E/TimerTick(19377)：系统在毫中花费的错误时间 = -20588> 1s
07-13 22:15:01.041：E/TimerTick(19377)：系统花费的错误时间（以毫秒为单位）= -19589> 1s
07-13 22:15:01.041：E/TimerTick（19377）：系统花费的错误时间（以毫秒为单位）= -18589> 1s
07-13 22:15:01.041：E /TimerTick(19377)：系统花费的错误时间（以毫秒为单位）= -17589> 1s
07-13 22:15:01.041: E/TimerTick(19377): 系统花费的错误时间毫秒 = -16590> 1s 07-13 22:15:01.041: E/TimerTick(19377): 系统花费的错误时间毫 = -15590> 1s 07-13 22:15:01.041: E/TimerTick(19377): 系统花费的错误时间毫秒 = -14591> 1s 07-13 22:15:01.041: E/TimerTick(19377):系统花费的错误时间（以毫秒为单位）= -13591> 1s 07-13 22:15:01.041：E/TimerTick（19377）：系统花费的错误时间（以毫秒为单位）= -12591> 1s 07-13 22:15:01.041：E /TimerTick（19377）：系统花费的错误时间（以毫秒为单位）= -11592> 1s 07-13 22:15:01.041：E/TimerTick（19377）：系统花费的错误时间（以毫秒为单位）= -10592> 1s 07-13 22 ：15：01.041：E / TimerTick（19377）：系统花费的错误时间（以milli = -9592> 1s 07-13 22：15：01.041：E / TimerTick（19377）：系统花费的错误时间（以milli = -8593） > 1s 07-13 22:15:01.041：E/TimerTick（19377）：系统花费的错误时间（以毫秒为单位）= -7594> 1s 07-13 22:15:01.041：E/TimerTick（19377）：系统花费的错误时间（以毫秒为单位）= -6594> 1s 07 -13 22：15：01.041：E/TimerTick（19377）：系统花费的错误时间（以毫秒为单位）= -5595> 1s 07-13 22：15：01.041：E/TimerTick（19377）：系统花费的错误时间（以毫秒为单位） = -4596> 1s 07-13 22:15:01.041：E/TimerTick(19377)：系统花费的错误时间，以毫秒为单位 = -3596> 1s 07-13 22:15:01.041：E/TimerTick(19377)：错误系统花费的时间（以毫秒为单位）= -24586> 1s 07-13 22:15:01.051：E/TimerTick（19377）：系统花费的错误时间（以毫秒为单位）= -2597> 1s 07-13 22:15:01.051：E/ TimerTick（19377）：系统花费的错误时间（以毫秒为单位）= -1598> 1s 07-13 22:15:01.051：E/TimerTick（19377）：系统花费的错误时间（以毫秒为单位）= -598> 1s 07-13 22： 15:01.051:V/TimerManagerService(19377)：onTick 延迟 = 331 结束，跟踪 = 540
07-13 22:15:01.051：D/TimerTick(19377)：以毫秒为单位的新延迟为 400，elapsedRealtime = 84830677
07-13 22:15:01.450：I/TimerManagerService(19377)：定时器正在工作。

( _ _ _
_ ）， 延迟）;

2）调度调用相同的run（），但似乎花费超过28秒来完成它07-13 22：15：01.041：E / TimerTick（19377）：系统花费的错误时间以milli = -28585（ms）> 1s
尽管日食报告只有一秒 => 22:15:00.041 两次通话之间 22:15:01.041

另外我想我必须用什么来在android上获得准确的经过时间？

4

2 回答 2

2

经过深入调查:) 似乎没有真正的“好”解决方案，但有几个“最佳”解决方案取决于目标。
在我的情况下，我需要显示链接倒计时（秒精度）并在每个任务结束时执行任务作为播放歌曲。当我使用SystemClock.elapsedRealtime()时发生的事情是 1 小时后经常有几分钟的延迟。
示例：
在 6:00:0.0 开始倒计时 1 小时（在智能手机上查看日期）在 7:04:11.0 而不是 7:00:00.0 倒计时结束我还必须使用 Calendar .getTimeInMillis() 这返回 android OS 完成的“官方”日期/时间。
我猜这个日期/时间经常使用不同的技术重新同步，因此在我的情况下更准确。

于 2015-07-17T13:58:20.453 回答
0

修复它的最佳方法是将 AlarmManager 与 BroadCastReceiver 一起使用，而不是 Timer。

于 2015-07-14T08:04:19.360 回答