“奇怪”；“口吃”；在不同android设备上的box2D中 我正在开发一个引擎和一个游戏同时在C++中，我用Box 2D来做物理后端。我在不同的android设备上进行测试，在三分之二的设备上，游戏运行良好，物理性能也很好。然而，在我的galaxy标签10.1上，我偶尔会有一种“口吃”。以下是一段youtube视频，演示：

游戏运行的第一台设备是Xperia Play。。。第二个设备是Galaxy Tab 10.1。不用说Galaxy tab的硬件比Xperia Play好得多，但是Box2D在随机时间段内以随机间隔滞后。两台机器的代码完全相同。另外，引擎/游戏的其他部分实际上并不落后。整个过程中，它以每秒60帧的速度稳定运行。因此，这种“口吃”似乎是从box2D实际读取值时的某种延迟或故障

看到移动的精灵会检查它们在渲染时是否具有附着的物理实体，并根据物理实体的世界位置设置其位置值。因此，在这个特定的过程中，box2D似乎与应用程序的其余部分不同步。很奇怪。我意识到这是一个远大的希望，但我想我无论如何都会把它贴在这里，看看是否有人有想法。。。因为我完全被难倒了。感谢您提前提供的任何信息

---

哦，顺便说一句，我使用固定的时间步长，因为这似乎是最常见的解决方案。当我在桌面上开发时，我移动到了一个固定的时间步，我遇到了一个更严重的类似问题，固定的步骤就是解决方案。就像我说的，游戏以每秒60帧的速度稳定运行，这是由一个低延迟计时器控制的，所以我怀疑简单的延迟是个问题。再次感谢

我对游戏开发非常陌生，你似乎更有经验，问这个问题可能很愚蠢，但你是否在使用

delta-time

来更新你的世界？尽管你说你的帧速率恒定为60 fps，但也许你的帧计数器计算出了一些错误，你应该使用

delta time

在fps较低时跳过一些帧，或者你的世界似乎“落后”。我很确定您对此很熟悉，但我认为这里有一个很好的例子：尽管它是一个C实现。如果你需要，我可以从我的Android项目中粘贴一些关于如何使用delta time的代码，这是我根据本书开发的：。

正如我在这里的评论中提到的，这归结为计时器解决问题。我使用了一个timer类，它应该访问最高分辨率的系统计时器，跨平台。一切都很好，除了安卓系统，有些版本有效，有些版本无效。galaxy tab 10.1就是这样一个例子

最后，我重新编写了

getSystemTime（）

方法，以使用C++11中新添加的名为

std:：chrono:：high_resolution_clock

。这也很有效（除了Android以外的所有地方）。。。除了它还没有在任何android的NDK中实现。它应该在crystax NDK R7的第5版中实现，在本文发布时，该版本已经完成了80%

我对访问系统时间的各种方法做了一些研究，通过这些方法，我可以在NDK端建立一个可靠的计时器，但归根结底，并非所有平台都支持这些不同的方法。我经历了从零开始编写自己的引擎的痛苦过程，这样我就可以支持所有版本的android，所以押注于实现不一致的方法是毫无意义的

在我看来，对于任何面临这个问题的人来说，唯一明智的解决方案就是放弃在NDK端实现此类代码的想法。我将在Java端执行此操作，因为到目前为止，在我所有的测试中，这在我测试过的所有设备上都是足够可靠的。更多信息请参见：

更新
现在，我已经实现了我提出的解决方案，在java端进行计时，它已经成功了。我还发现，在NDK端处理任何相对较大的数字，无论数据类型如何（比如调用单调时钟的纳秒数），也会导致某些版本的android严重滞后。因此，我通过传递一个指向系统时间的指针，尽可能地优化了这一点，以确保我们不是通过复制来传递的

还有最后一件事，我认为从NDK端调用单调时钟是不可靠的，但这似乎是错误的。从安卓码头开始

…和System.nanoTime（）。这个钟肯定是单调的， 是通用间隔计时的推荐依据 用户界面事件、性能度量和其他任何内容 在设备睡眠期间不需要测量经过的时间

---

因此，如果这是可信的，那么调用时钟似乎是可靠的，但正如前面提到的，还有其他问题会出现，比如处理分配和转储大量的数字，仅此一项就几乎将我在Android 3.2的Galaxy Tab 10.1上的帧速率减半最终结论：平等地支持所有android设备几乎是不可能的，使用本机代码似乎会让情况变得更糟。

您是否尝试过输出物理步骤之间的时间，可能是代码中的某个错误导致它们不规则？请确定，您只为Box2D的Step（）函数提供了一个文字浮点值，例如1/60.0作为时间步长？你确定每秒调用60次吗？@iforce2d是的，在初始化时，我将浮点设置为1/60，并将最大全局FPS限制为60，这就是我传递给step（）方法的全部内容。@tm1rbrt我会这样做，然后再给你。。。我没有费心，因为我假设它肯定是物理代码，不管怎样，所以跟踪