Android unico gioco in OpenGL: prestazioni in C++ (NDK) vs Java (Dalvik)

Question

So che le questioni simili sono stati chiesto prima, ma ...

Vogliamo sviluppare (almeno spero) un gioco indie ma è ancora un gioco con una grafica di alta qualità con centinaia se non migliaia di oggetti in movimento sullo schermo, quindi ci aspettiamo un numero molto alto di poligoni e requisiti per i più cattivi e forse alcuni AI.

So che il problema di base con java è la garbage collection. Ma non è un problema, abbiamo in programma di allocare tutta la memoria necessaria prima dell'inizio del gioco e per gli oggetti transitori useremo il pooling (quindi nel ciclo di gioco la nuova parola chiave non verrà mai scritta). E progettiamo di utilizzare ogni possibile tecnica menzionata qui (Google I/O 2009 - Writing Real-Time Games for Android).

La ragione principale ci ostiniamo a Java è la distribuzione e abbiamo solo vogliono sviluppare per Android (almeno per ora)

Così può le stesse prestazioni in un gioco essere achived con Java (anche se questo significa brutto/codice non idiomatico) come se lo avessimo fatto con C++. In caso contrario, quali sono le specifiche? O forse se è possibile, ma molto, molto poco pratico, quali sono queste ragioni?

(Per esempio ho letto qualcosa su Tamponi Java e OpenGL non sono le migliori, ma l'associazione non ricordo le specifiche - magari un po 'di esperti)

Answer 1

si sta andando a pagare un costo aggiuntivo fisso per chiamata a usa OpenGL dal codice sorgente di Java. Android fornisce wrapper in linguaggio Java per le chiamate. Ad esempio, se chiami glDrawArrays, chiami un metodo nativo dichiarato in GLES20.java, che è definito in android_opengl_GLES20.cpp. Puoi vedere dal codice che sta semplicemente inoltrando la chiamata con un sovraccarico minimo.

Annusando nel file, è possibile vedere altre chiamate che eseguono ulteriori controlli e quindi sono leggermente più costosi.

La linea di fondo fino a inevitabile costa è che il prezzo di effettuare molte chiamate GLES è più alto con l'origine Java rispetto alla sorgente nativa. (Osservando le prestazioni di Android Breakout con systrace ho notato che c'era un sovraccarico della CPU nel driver perché stavo facendo un sacco di aggiornamenti di stato ridondanti.Il costo di farlo dal codice nativo sarebbe stato inferiore, ma il costo di fare zero lavoro è inferiore al costo di fare meno lavoro.)

La domanda più profonda ha a che fare con se è necessario scrivere il codice in modo diverso (ad esempio per evitare allocazioni) che semplicemente non è possibile ottenere lo stesso livello di prestazioni. Devi lavorare con oggetti diretti ByteBuffer piuttosto che semplici matrici, che potrebbero richiedere un po 'più di gestione da parte tua. Ma a parte le attuali differenze di velocità tra codice nativo e Java ad alta intensità di calcolo su Android, non sono a conoscenza di nulla che fondamentalmente impedisca buone prestazioni da implementazioni rigorosamente Java.