所以我在我的第一个 iOS 游戏中，正在努力寻找如何以最佳方式集成对象运动。
游戏严重依赖快速移动的物体和持续快速的用户输入变化。因此，我试图让对象集成和约束求解器尽可能快速准确地运行（以最大限度地减少连续游戏循环调用之间的用户输入变化）。
更具体地说，我不确定 NSTimer 类和 CACurrentMediaTime() 函数的功能。很难凭经验进行测试，因为我不确定哪个误差更大。例如，使用重复间隔为 0.008（~2 更新/屏幕刷新）的 NSTimer 并在连续调用中调用 CACurrentMediaTime()，我发现调用之间的时间间隔在 0.0075 - 0.009 之间变化。很难说哪个是（小）不一致的原因。因此，为了确定时间步长，我应该是：
假设 NSTimer 足够准确，可以使用 NSTimer 时间间隔作为游戏循环时间步长
使用 CACurrentMediaTime() 确定连续游戏循环调用之间的时间间隔。
学生和所有这一切的新手 - 请善待:) 非常感谢任何建议。谢谢你的时间。
NSTimer不是实时计时器。它甚至不接近，也不意味着要接近。如果您查看任何东西的速度超过半秒左右，NSTimer那就是错误的工具。我什至不会在一秒钟内推荐它。对于多秒的事情，尤其是多分钟的事情，当你并不真正关心它何时触发时，这很棒。我用它所有的时间。
CACurrentMediaTime()不是计时器。它是系统中最准确时间函数的封装：mach_absolute_time(). 因此，如果您真的关心现在是什么时间，并且希望以人类可以理解的数字显示，CACurrentMediaTime()这就是您的功能。mach_absolute_time()会给你一个非常准确的数字，但它基于马赫绝对时间单位，它实际上并没有映射到任何讨厌的人类认为的东西（每个 CPU 都有不同的比例）。这就是为什么我们必须CACurrentMediaTime()让我们的生活更轻松。
好的，所以NSTimer不是实时的，CACurrentMediaTime()也不是计时器。游戏程序员要做什么？
Grand Central Dispatch包括我们拥有的一些最好的“大约在这个时候运行”系统。这是一个调度源。我说“大约这个时候”是因为 GCD 仍然不是 RTOS 人所说的真正的“实时”。但这对游戏开发者来说已经足够实时了。在并发编程指南中查找创建计时器。另请查看dispatch_after()，这对于一次性“延迟运行”很有用。
请记住，在您的主线程（UI 线程，所有绘图完成的地方）上运行的任何东西都将与该线程上的所有其他东西共享时间。因此，当您在主线程上处理绘图和用户交互时，您经常需要在后台线程上进行计算。这就是 GCD dispatch_queues 旨在帮助您的事情。另一方面，请记住许多 iOS 设备是单核的。所以“后台线程”有点用词不当。一次只能在 CPU 上真正运行一件事。这就是为什么将事物转移到 GPU 如此重要（见下文）。
您可能还想认真研究cocos2d 之类的系统，这是一个非常好的游戏引擎。它会为您处理很多此类细节，并让您专注于游戏部分。
留在 Apple 框架中，您还应该看看 Core Animation。如果你用计时器在屏幕上移动东西，你不应该那样做。核心动画是您在屏幕上移动事物的方式。它会为你处理很多细节，比你自己做的更快，使用更少的电池，并且它将很多工作转移到 GPU 上（正如我上面提到的）。比起游戏，它更多地是为 UI 元素设计的，但它绝对可以用来构建简单的游戏。
当然还有 GLKit，但那是完全不同的事情......
根据NSTimer 文档 the effective resolution of the time interval for a timer is limited to on the order of 50-100 milliseconds.，这可能就是您看到时间间隔变化的原因。
我建议您将更新间隔更改为 0.016 秒，因为没有理由让您的游戏状态更新频率超过屏幕可以绘制的频率。然后您可以使用CADisplayLink来处理时间。这应该非常准确，因为它使用显示刷新率。