私は libGDX を使用してゲームの作成に取り組んでおり、実際にゲームをスレッド化したいので、ペイント ループとロジック ループを別々のスレッドで実行しています。これは、ペイント コンポーネント ループと実行可能な実行ループを使用して単純な Java スイング ゲームを作成する場合と同じです。 .
私はCでのスレッド化の経験がありますが、Javaではあまり経験がありません.
スレッドを作成できる唯一の方法は、スレッドを拡張するクラスを作成し、そこに実行ループを作成することでした。
しかし、実行ループを作成するポイントは、各画面でロジックを自由に計算できるようにすることでした。そのため、カスタム スレッド クラスが実装された何らかの抽象画面クラスが必要になります。
この状況でスレッドを実装するためのより簡単な、またはより標準的な方法があるかどうかを尋ねています。
libGDXライブラリは、OpenGLコンテキストの更新用に別のレンダリングスレッドをすでに実行しています。http://code.google.com/p/libgdx/wiki/TheArchitecture#The_Graphics_Moduleを参照してください
UIスレッドは継続的に実行されるのではなく、イベントをディスパッチする必要がある場合にのみオペレーティングシステムによって実行されるようにスケジュールされていることをすでに学びました（おおよそ：p）。そのため、通常はレンダリングスレッドと呼ばれる2番目のスレッドをインスタンス化します。このスレッドは、起動時にアプリケーションによってインスタンス化されるグラフィックモジュールによって作成されます。
メインゲームオブジェクトのApplicationListener.render()メソッドは、画面が更新されるたびにこのレンダリングスレッドによって呼び出されるため（約60Hzである必要があります）、このメソッドの実装にレンダリングループの本体を配置するだけです。
のメソッドで追加のバックグラウンドスレッド（ゲームロジックなど）を作成できcreateますApplicationListener（必ずメソッドでクリーンアップしてくださいdispose）。スレッドを除いて、render既存のスレッドはどれもゲームロジックに適した場所ではないと思います。
スレッド間の通信には、既存のJava同期アプローチのいずれかを使用できます。私はJavaを使用ArrayBlockingQueue<>して、バックグラウンドスレッドにリクエストを送信しました。またGdx.app.postRunnable()、バックグラウンドスレッドでデータをレンダリングスレッドにプッシュするために使用しました（このようなRunnableは、render()呼び出される前に次のフレームで実行されます）。
何を言っているのか分かりませんが、画面への描画 (ディスプレイへの変更の反映) は専用のシングルスレッドで行われるのが標準です (例: Swing フレームワークを参照)。これは、複数のスレッドを混乱させずに画面に描画させるのが非常に難しいためです。これを行う実装はほとんどありません。したがって、GUI フレームワークを自分で実装することを計画している場合は、シングル スレッドの描画アプローチをお勧めします。
ビジネスロジックに関しては、多くのことに依存しています。非常に単純な方法で、各アクティビティに対して新しいスレッドを生成することができます。これらのスレッドは、結果を前述の GUI スレッドにポストできます。このアプローチの問題点は、多くのアクティビティが同時に実行されると、効率が大幅に低下する可能性があることです。これは、Java ではすべてのスレッドがネイティブ OS スレッドにマップされるためです。これを回避するには、スレッド プールを使用します。Java 標準ライブラリは、スレッド プールを提供しThreadPoolExecutorますExecutorService。