NSTimer是否受到处理器速度，不同代的iPhone等的影响

Question

我正在我的游戏中实施倒计时方法，这将使用15秒的倒计时。我一直在寻找不同的方法来实现这一点，并相信NSTimer是可行的方法。

然而，有人告诉我，它可能会受到处理器速度等的影响。我的问题是，如果这是真的，如果是这样，我该如何反击呢？

我已经看到了这一点：NSTimer但是并不完全理解这种影响。

还有其他方法可以保证15秒的停机时间和所有设备吗？

Answer 1

我不明白你的最后一句......

然而，我相信你的朋友是正确的，它与实际秒倒计时相比略微偏离，但我向你保证，差异是如此之小，以至于它并不明显，特别是对于游戏而言。

之所以出现差异，是因为您将NSTimer设置为在一秒钟内执行，执行时会更新屏幕上的倒计时然后重复。我的猜测是，NSTimer在完成执行方法之后才开始重复，因此每个NSTimer秒的纳秒分数比真正的秒长。

Apple可能比我领先一步，并在执行前调用重复，但是，我不确定。

无论哪种方式，就像我说的那样，除非你做的不仅仅是每秒更新一次屏幕，否则你的用户根本不应该注意到差异。

Answer 2

对于大多数用途，NSTimer应该没问题。它并不准确 - 时间会比你设定的时间略长，但在良好的条件下只有很小的数量 - 想想毫秒。但是，NSTimer通过runloop触发，因此它的准确性取决于runloop不忙。您可以通过在自己的线程上使用专用的runloop来最小化问题，但如果系统繁忙，您仍会看到计时器的周期略有扩展。

因此，虽然CPU速度与其他此类因素之间没有先天关系，但由于不经常忙碌，更快的硬件将能够保持更好的状态。

另请注意，重复的NSTimer不会发生相移 - 它会像15s一样精确设置为1s的间隔。唯一需要注意的是，如果你的处理程序在下一次火灾发生时仍然在运行，那火就不会发生。例如如果你花1.1秒，射击之间的差距会跳到2秒。

runloops＆amp; amp;的替代方案NSTimers是dispatch_after。但它不太可能更准确，并且它的滑动仍然取决于目标队列（可能是其中一个默认并发队列）在它发生时不忙。

Answer 3

理论：NSTimer不受处理器速度的直接影响。在Gen 2设备上运行1分钟的计时器也应该在更新的设备上表示1分钟。

现在这就是理论:)，但实际上，处理器速度不仅会影响您的计时器，还会影响您应用的总体速度（例如，您的观看次数变化的速度，以及您按下音乐后音乐的开始时间一个按钮等）。唯一（或最佳测试）是针对您要定位的设备类型重复测试您的应用。早期测试，经常测试：）

您不能（根据我的经验）确保在任何设备上确切地保留时间T。但是，您可以获得平均接近预期时间T的时间。