的Android只在OpenGL遊戲：在C++（NDK）和Java（Dalvik的）

Question

我知道，類似的問題已經被問過表現，但...

我們要發展（至少希望）的獨立遊戲但仍然是一個高質量的圖形遊戲，如果不是在屏幕上移動物體的話，那麼我們就會期望非常高的多邊形數量和對碰撞測試的要求以及可能的AI。

我知道java的基本問題是垃圾收集。但這不是問題，我們打算在遊戲開始之前分配所有需要的內存，並且爲了臨時對象我們將使用池（所以在遊戲循環中新的關鍵字將永遠不會被寫入）。我們計劃使用這裏提到的所有可能的技術（Google I/O 2009 - Writing Real-Time Games for Android）。

我們堅持的Java的主要原因是部署，我們只希望開發Android（至少目前）

所以可以在一場比賽相同的性能與Java（被achived即使這意味着醜陋/不是慣用的代碼），就像我們用C++做的一樣。如果不是，具體是什麼？或者，如果可能，但非常不切實際，這些原因是什麼？

（比如我讀一些關於Java緩衝區和OpenGL是不是最好的配對，但不記得細節 - 或許有些專家）

Answer 1

你會得到回報每個呼叫到一個固定的額外費用使用來自Java源代碼的OpenGL。 Android爲這些調用提供了Java語言包裝器。例如，如果您致電glDrawArrays，那麼您正在調用GLES20.java中聲明的本地方法，該方法在android_opengl_GLES20.cpp中定義。你可以從代碼中看到，它只是以最小的開銷轉發呼叫。

在文件中徘徊，你可以看到其他調用執行額外的檢查，因此稍微昂貴。

至於不可避免的底線成本是因爲使用Java源代碼進行大量GLES調用的價格高於本地源代碼。 （雖然看Android Breakout與systrace的性能，我注意到在驅動程序中有很多的CPU開銷，因爲我做了大量的冗餘狀態更新。從本地代碼執行此操作的成本本來會較低，但成本做零工作的成本低於做更少工作的成本）。

更深層次的問題與你是否需要寫如此不同的代碼（例如爲了避免分配）有關，你根本無法得到相同的結果性能水平。你必須使用直接ByteBuffer對象而不是簡單的數組，這可能需要更多的管理。但是除了目前計算密集型本機和Android上的Java代碼之間的速度差異之外，我不知道任何從根本上阻止了嚴格Java實現的良好性能。