我正在开发一款非常集中使用box2d物理的游戏，当屏幕上有很多物体时，我的beta测试人员报告了邋performance的性能。我几乎总是挂着应用程序的DEBUG版本，并且始终保持稳定的60 fps。在摆弄几乎所有构建设置后，我注意到在DEBUG构建模式中，标记ONLY_ACTIVE_ARCH为YES，而在RELEASE中则为NO。在为ARMv6构建RELEASE版本并将其安装在支持ARMv7的设备上之后，我们获得了稳定的60 fps。试图为ARMv7（Thumb）构建，再次给出了一个草率（30 - 50％更差）的性能。在非物理模拟环境中也可以看到轻微的性能损失。测试设备是iPod Touch 4，iPhone 4和iPhone 3GS。你能否分享一下你为何会这样做的意见？我不知道:)
答案 0 :(得分：2)
我注意到同样的问题。 经过一些测试后，我发现如果设置以下渲染模式，性能会好得多：
<renderMode>gpu</renderMode>
我在星系s2上测试了这个。到现在为止，我不知道对其他设备的影响是什么......
答案 1 :(得分：0)
首先：始终仅在发布版本中测量性能。调试版本包括断言，日志记录以及可能会影响性能结果的其他因素，通常情况更糟。
如果我说得对，你说ARMv6代码在所有设备上都运行顺畅（60 fps），而为启用了Thumb指令的ARMv7构建会给你带来“草率”的性能。我认为“30-50％更糟”意味着在所有3个提到的设备上ARMv7代码大约30-45 fps。这听起来似乎没有可比较的测试场景，即游戏以相同位置的相同数量的对象开始，以便能够准确地比较设备之间的性能。如果通过玩游戏手动重现“大量物体”场景，很难评估真实的性能差异。
由于您已经启用了ARMv7和拇指指令，因此您应该获得良好的性能，尤其是在第4代设备上。您可能想尝试禁用拇指并重新测试。您还应该检查发布版本的优化级别，它应该是：最快，最小。通常，检查仅影响ARMv6或ARMv7的任何条目的构建设置（此类条目标有箭头以展开它们）。
您还应该验证您的性能问题实际上与物理有关。 “很多对象”意味着屏幕上还有“很多精灵”。如果它们不是sprite-batch，那么性能可能会下降得更快。如果它们也是部分透明，旋转或缩放，那么没有spritebatching的性能会更糟。