At minimum, an OpenGL Android game has a UI thread and a Renderer thread created by GLSurfaceView. Renderer.onDrawFrame() should be doing a minimum of work to get the higest FPS. The physics, AI, etc. don't need to run every frame, so we can put those in another thread. Now we have:

  1. Renderer thread - Update animations and draw polys
  2. Game thread - Logic & periodic physics, AI, etc. updates
  3. UI thread - Android UI interaction only

Since you don't ever want to block the UI thread, I run one more thread for the game logic. Maybe that's not necessary though? Is there ever a reason to run game logic in the renderer thread?


2 Answers 2


Google's Chris Pruett talks about this issue in his Replica Island blog. Because eglSwapBuffers() is a blocking call in the GLSurfaceView thread, having game logic code in another thread allows it to run while the swap buffers call is blocking. This is important if your game is complex and you want to achieve 60 frames per second.

You can download the source code for Replica Island and see how they did it. I've implemented something similar for my game (with the three threads you talked about) and it works great.


Android supports standard Java Threads . You can use standard Threads and the tools from the package java.util.concurrent to put actions into the background. The only limitation is that you cannot directly update the UI from the background process.

If you need to update the UI from a background task you need to use some Android specific classes. You can use the class android.os.Handler for this or the class AsyncTasks.

For more details please check out the following link....



You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .