Лучший способ отделить логику игры от рендеринга динамичной игры для Android с OpenGL ?

Я учился и делал небольшие игры какое-то время, и недавно я решил, что попробую разрабатывать игры для Android.

Для меня переход с нативного кода C ++ на Android Jav a было не так уж сложно, но у меня голова болит, когда я думаю о том, как сохранить логику отдельно от рендеринга.

Я читал здесь и на других сайтах, что:

Лучше не создавать для этого еще одну ветку только потому, что У Android точно не будет проблем с обработкой.

Это означает, что код будет примерно таким:

public void onDrawFrame(GL10 gl) {
    doLogicCalculations();
    clearScreen();
    drawSprites();
}

Но я не уверен, что это лучший подход. Так как я не думаю, что мне нравится, как это будет выглядеть, если я помещу свою логику в метод GLRenderer :: onDrawFrame . Насколько мне известно, этот метод предназначен только для рисования, и я могу замедлить кадры, если добавлю туда логику. Не говоря уже о том, что это вредит концепции POO в моем понимании.

Я думаю, что использование потоков может быть подходящим способом, вот как я планировал:

Основное действие:

public void onCreate(Bundle savedInstanceState) {
    //set fullscreen, etc

    GLSurfaceView view = new GLSurfaceView(this);
    //Configure view

    GameManager game = new GameManager();
    game.start(context, view);

    setContentView(view);
}

GameManager:

OpenGLRenderer renderer;
Boolean running;
public void start(Context context, GLSurfaceView view) {
    this.renderer = new OpenGLRenderer(context);
    view.setRenderer(this.renderer);

    //create Texturelib, create sound system...

    running = true;
    //create a thread to run GameManager::update()
}

public void update(){
    while(running){
        //update game logic here
        //put, edit and remove sprites from renderer list
        //set running to false to quit game
    }
}

и, наконец, OpenGLRenderer:

ListOrMap toDraw;
public void onDrawFrame(GL10 gl) {
    for(sprite i : toDraw)
    {
        i.draw();
    }
}

Это приблизительная идея, не полностью полный. В этом шаблоне все будет разделено и будет выглядеть немного лучше, но лучше ли он для производительности?

Пока я исследовал, в большинстве примеров многопоточных игр используется холст или просмотр поверхности, они не подходят для моего случая, потому что Я использую OpenGLES.

Итак, вот мои вопросы:

Как лучше всего разделить мои игровая логика от рендеринга при использовании OpenGLES? Поток мой заявление? Поместите логику в отдельный метод и просто вызовите ее из метод рисования?