我知道以前有人问过类似的问题，但是...
我们想要开发（至少希望）一款独立游戏，但仍然是一款具有高质量图形的游戏，屏幕上有数百个甚至数千个移动物体，因此我们期望非常多的多边形和对 hittest 的要求，也许还有一些 AI。
我知道java的基本问题是垃圾收集。但这不是问题，我们计划在游戏开始之前分配所有需要的内存，对于瞬态对象，我们将使用池化（因此在游戏循环中永远不会写入 new 关键字）。我们计划使用这里提到的所有可能的技术（Google I/O 2009 - 为 Android 编写实时游戏）。
我们坚持 Java 的主要原因是部署，我们只想为 Android 开发（至少现在）
因此，在游戏中是否可以使用 Java 实现相同的性能（即使这意味着丑陋/不惯用的代码），就像我们使用 c++ 一样。如果不是，具体情况如何？或者，如果可能但非常非常不切实际，这些原因是什么？
（例如，我读过一些关于 java Buffers 和 OpenGL 的文章不是最好的配对，但不记得具体细节——也许是一些专家）
从 Java 源代码中使用 OpenGL 每次调用都需要支付固定的额外费用。Android 围绕调用提供 Java 语言包装器。例如，如果您调用glDrawArrays，您正在调用GLES20.java中声明的本机方法，该方法在android_opengl_GLES20.cpp中定义。您可以从代码中看到它只是以最小的开销转发呼叫。
在文件中四处寻找，您可以看到执行额外检查的其他调用，因此成本略高。
就不可避免的成本而言，底线是使用 Java 源进行大量 GLES 调用的成本高于本地源。（在使用systrace查看Android Breakout的性能时，我注意到驱动程序中有很多 CPU 开销，因为我正在执行大量冗余状态更新。从本机代码执行此操作的成本会更低，但是做零工作的成本低于做更少工作的成本。）
更深层次的问题与您是否需要以如此不同的方式编写代码（例如，避免分配）以至于您根本无法获得相同水平的性能。您确实必须使用直接ByteBuffer对象而不是简单的数组，这可能需要您进行更多的管理。但除了当前在 Android 上计算密集型本机代码和 Java 代码之间的速度差异之外，我不知道有什么会从根本上阻止严格 Java 实现的良好性能。