因此，我正在玩我的第一个 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() 会给你一个非常准确的数字，但它是基于 Mach absolute time unit它实际上并没有映射到任何令人讨厌的人类想法(并且每个 CPU 都有不同的规模)。这就是为什么我们有 CACurrentMediaTime() 来让我们的生活更轻松。
好的，所以 NSTimer 不是实时的，CACurrentMediaTime() 也不是计时器。游戏程序员要做什么？
Grand Central Dispatch包括我们拥有的一些最好的“大约在此时运行”系统之一。这是一个调度源。我说“大约这个时候”是因为 GCD 仍然不是 RTOS 人员所说的真正“实时”。但它对游戏开发者来说已经足够实时了。在 Concurrency Programming Guide 中寻找创建计时器.另请查看 dispatch_after()，它非常适合一次性“延迟运行”。
请记住，在您的主线程(UI 线程，完成所有绘图的地方)上运行的任何内容都将与该线程上的其他所有内容共享时间。因此，当您在主线程上处理绘图和用户交互时，您经常需要在后台线程上进行计算。这就是 GCD dispatch_queues 旨在帮助您的事情。另一方面，请记住许多 iOS 设备是单核的。所以“后台线程”有点用词不当。 CPU 上一次只能真正运行一件事。这就是为什么将东西转移到 GPU 如此重要(见下文)。
您可能还想认真查看像 cocos2d 这样的系统，这是一个非常好的游戏引擎。它会为您处理很多此类细节，让您专注于游戏部分。
留在 Apple 框架中，您还应该看看 Core Animation。如果您使用计时器在屏幕上四处移动事物，则不应该这样做。核心动画是你如何在屏幕上移动东西。它会为您处理很多细节，比您自己处理速度更快，耗电量更少，而且它会将大量工作转移到 GPU(正如我上面提到的)。与游戏相比，它更多地是为 UI 元素设计的，但它绝对可以用于构建简单的游戏。
当然还有 GLKit，但那是完全不同的东西....
关于ios - NSTimer 与 CACurrentMediaTime()，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11660403/