Android 节拍器计时器减速（通过处理程序或线程）

我有一个简单、经典的说法，每200毫秒播放一次声音（节拍器）

我使用处理程序编写它，然后以另一种方式使用线程。 问题在两个方面都是一样的：当我按下hardware home（硬件主页）按钮时，或者仅仅当我按下按钮打开ListView时，节拍器会突然减速一段时间

这个问题（不是很严重，但是存在）也表现为无所事事，将应用程序置于前台

有什么想法吗

代码如下：

公共类Metronome实现Runnable{

private Handler mHandler = new Handler();
public static long mStartTime;

Main mainContext; 

public Metronomo(Main context) {
    mainContext = context;
}


public void play() {
    mStartTime = System.currentTimeMillis();
    mHandler.postDelayed(this, 100);
}

public final void stop(){
    mHandler.removeCallbacks(this);
}

public void run(){
        //play the ogg file in position 1
        mSoundManager.playSound(1);

        //reschedule the next playing after 200ms
        mHandler.postAtTime(this, SystemClock.uptimeMillis() + 200);
   }

---

})

您是否使用某种暂停语句在节拍之间等待？您可以尝试将计时改为基于系统时钟值的倍数。这样的话，你可能仍然会有延迟的节拍（或者根本没有），但你不会慢下来。希望这有点道理

---

这更多的是一个评论，但我还没有足够的代表留下评论。

我的手机似乎能够播放midi文件，这是一种非常紧凑的声音表示方式，也许你可以动态创建一个并将其用于节拍器？我假设合成是在一个较低的层次上处理的，而不是通常你可以访问的，这样时间安排会更好，但我不知道这是事实

当调用此播放声音时

mSoundManager.playSound(1);

Android会一直等到呼叫结束，然后你再呼叫

mHandler.postAtTime(this, SystemClock.uptimeMillis() + 200);

然而，如果你逆转这些呼叫，你可能会发现时间更准确

mHandler.postAtTime(this, SystemClock.uptimeMillis() + 200);
mSoundManager.playSound(1);

你不能指望你的声音会花同样多的时间播放，所以告诉处理程序先发布会更好一些。但仍然不理想

另一个需要考虑的问题是，您正在计算正常运行时间，并在此基础上增加一些时间（本例中为200）。为什么不在您的正常运行时间上使用模数运算符，以确保下一次请求的post时间安排得更精确

long divisions = SystemClock.uptimeMillis() % 200; // precisely scheduled event timings since system boot.
long nextDivision = divisions + 1; // the next desired event timing
mHandler.postAtTime(this, nextDivision * 200); // scaled back up to number of milli seconds
// now do more heavy lifting that would otherwise have affected uptimeMillis call
mSoundManager.playSound(1);

---

这就是在这样的设备上精确计时的问题。根本不确定有没有解决办法，更不用说一个简单的类似想法了：生成一个音流，让节拍器的声音紧跟着寂静，而不是播放声音然后停下来。只要你的线程有足够的CPU时间来保持声音缓冲区满，你的节拍器就会准时运行，即使系统中的其他东西处于活动状态。