Quantas threads um jogo Android deve usar?

No mínimo, um jogo Android do OpenGL tem um thread da interface do usuário e um renderizador criado por GLSurfaceView. Renderer.onDrawFrame()deve fazer um trabalho mínimo para obter o maior FPS. A física, a IA etc. não precisam executar todos os quadros, para que possamos colocá-los em outro segmento. Agora temos:

1. Thread do renderizador - Atualize animações e desenhe polys
2. Tópico do jogo - atualizações de lógica e física periódica, IA, etc.
3. Thread da interface do usuário - somente interação com a interface do Android

Como você nunca deseja bloquear o thread da interface do usuário, eu corro mais um thread para a lógica do jogo. Talvez isso não seja necessário? Existe alguma razão para executar a lógica do jogo no thread do renderizador?

Chris Pruett, do Google, fala sobre esse problema em seu blog Replica Island . Como eglSwapBuffers () é uma chamada de bloqueio no encadeamento GLSurfaceView, ter código de lógica de jogo em outro encadeamento permite que ele seja executado enquanto a chamada de buffers de troca está bloqueando. Isso é importante se o seu jogo for complexo e você desejar atingir 60 quadros por segundo.

Você pode fazer o download do código fonte da Ilha Replica e ver como eles o fizeram. Eu implementei algo semelhante para o meu jogo (com os três tópicos que você falou) e funciona muito bem.

O Android suporta threads Java padrão. Você pode usar Threads padrão e as ferramentas do pacote java.util.concurrent para colocar ações em segundo plano. A única limitação é que você não pode atualizar diretamente a interface do usuário a partir do processo em segundo plano.

Se você precisar atualizar a interface do usuário a partir de uma tarefa em segundo plano, precisará usar algumas classes específicas do Android. Você pode usar a classe android.os.Handler para esta ou a classe AsyncTasks.

Para mais detalhes, consulte o seguinte link ....

http://mindstick.com/Articles/7a9205de-bae7-48ba-81b5-2b2ec161d672/?Thread%20in%20Android