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

Question

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

我使用处理程序编写它，然后以另一种方式使用线程编写它。 两种方式的问题都是相同的：当我按下硬件主页按钮时，或者只是当我按下按钮打开 ListView 时，节拍器会严重减慢一段时间。

这个问题（不是那么严重，但仍然存在）也表现为不执行任何操作并将应用程序留在前台。

有什么想法吗？

代码如下：

public class Metronome Implements 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);
   }

};

Answer 1

您是否使用某种暂停语句在节拍之间等待？您可以尝试将计时基于系统时钟值的倍数。这样，您可能仍然会得到较晚出现（或根本不出现）的节拍，但不会减慢速度。希望这有某种意义。

这更像是一条评论，但我还没有足够的代表来发表评论。

Answer 2

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

Answer 3

当这个播放声音被调用时，

mSoundManager.playSound(1);

Android会等到该调用完成，然后您再调用，

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

但是，如果您反转这些调用，您可能会发现计时更准确。

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

您不能指望您的声音会花费完全相同的时间来播放，因此告诉处理程序先发布会更好一些。然而，仍然不理想。

另一个考虑因素是您要重新计算正常运行时间并添加更多时间（在本例中为 200）。为什么不在正常运行时间上使用模数运算符，以确保更精确地安排下一个请求的发布时间？

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);