android - 使用JNI，还是不使用JNI(Android性能)

Question

我刚刚向我正在开发的 Android 游戏添加了一些计算量大的代码。有问题的代码是碰撞检测例程的集合，这些例程经常被调用(游戏循环的每次迭代)并且正在进行大量计算。我觉得我的碰撞检测实现相当完善，而且速度相当快，我可以用 Java 实现。

我一直在使用 Traceview分析代码，这段新的碰撞检测代码毫不奇怪地使我的游戏逻辑的持续时间增加了一倍。这显然是一个问题，因为对于某些设备，这种性能下降可能会使我的游戏从可玩状态变为不可玩状态。

我一直在考虑优化此代码的不同方法，我想知道通过将代码移至 C++ 并使用 JNI 访问它是否会显着节省性能？

上述问题是我最关心的问题，也是我提出问题的原因。我确定以下两个原因是使用 JNI 的其他积极结果。但是，这并不足以说服我将我的代码移植到 C++。

• 这将使代码更清晰。由于大多数碰撞检测都是某种矢量数学，因此能够使用重载运算符比在 Java 中使用一些更冗长的矢量类要干净得多。

• 内存管理会更简单。你说简单点？好吧，这是一款不欢迎运行垃圾收集器的游戏，因为如果 GC 必须不断中断以进行清理，它最终可能会破坏游戏的性能。在 C 中，我不必担心垃圾收集器，因此我可以避免在 Java 中使用临时静态变量做的所有丑陋事情，而只依赖于 C++ 的良好旧堆栈内存

尽管这个问题可能很冗长，但我想我已经涵盖了所有要点。有了这些信息，是否值得将我的代码从 Java 移植到 C++ 并使用 JNI 访问它(出于提高性能的原因)？另外，有没有办法衡量或估计潜在的性能提升？

编辑:

所以我做到了。结果？从 TraceView 的角度来看，我的碰撞检测程序的速度提高了 6 倍。

虽然到达那里并不容易。除了必须进行 JNI 舞蹈之外，我还必须进行一些我没有预料到的优化。主要是使用直接分配的浮点缓冲区将数据从 Java 传递到 native 。我最初的尝试只是使用一个 float 组来保存有问题的数据，因为从 Java 到 C++ 的转换更自然，但那真的很慢。直接缓冲区完全回避了 java 和 native 之间数组复制的性能问题，给我留下了 6 倍的提升。

另外，我没有使用自己的向量类，而是使用了 Eigen 数学库。我不确定这对性能有多大影响，但至少，它节省了我开发自己的(效率较低的)向量类的时间。

另一个教训是，过多的日志记录不利于性能(不明显的 jic)。

Answer 1

不是真正直接回答您的问题，但以下链接可能对您有用:

• Android Developers, JNI Tips.
• Android Developers, Designing for Performance

第二个链接是这样写的:

Native code isn't necessarily more efficient than Java. For one thing, there's a cost associated with the Java-native transition, and the JIT can't optimize across these boundaries. If you're allocating native resources (memory on the native heap, file descriptors, or whatever), it can be significantly more difficult to arrange timely collection of these resources. You also need to compile your code for each architecture you wish to run on (rather than rely on it having a JIT). You may even have to compile multiple versions for what you consider the same architecture: native code compiled for the ARM processor in the G1 can't take full advantage of the ARM in the Nexus One, and code compiled for the ARM in the Nexus One won't run on the ARM in the G1.

Native code is primarily useful when you have an existing native codebase that you want to port to Android, not for "speeding up" parts of a Java app.