问题
I am working on making a game with libGDX and I really want to thread the game so I am running a paint loop and a logic loop on separate threads much like you would making a simple java swing game with the paintcomponent loop and the runnable run loop.
I am experienced with threading in c but not so much in java.
The only way I was able to make a thread was by making a class that extends threads and then creating the run loop in there.
But the point of making the run loop was to allow each screen to compute logic freely, so I would end up needing some sort of abstractscreen class that has the custom thread class implemented.
I am asking if there is a simpler or more standard way of implementing threads for this situation.
回答1:
The libGDX library already runs a separate render thread for the OpenGL context updates. See http://code.google.com/p/libgdx/wiki/TheArchitecture#The_Graphics_Module
We already learned that the UI thread is not executed continuously but only scheduled to run by the operating system if an event needs to be dispatched (roughly :p). That's why we instantiate a second thread we usually refer to as the rendering thread. This thread is created by the Graphics module that itself gets instantiated by the Application at startup.
The ApplicationListener.render() method on your main game object will be invoked by this render thread once for every screen refresh (so it should be about 60hz), so just put the body of your render loop in your implementation of this method.
You can create an additional background thread (e.g., for game logic) in the create method of your ApplicationListener (be sure to clean it up in the dispose method). Other than the render thread, I don't think any of the pre-existing threads would be the right place for game logic.
For communication between the threads, you can use any of the existing Java synchronization approaches. I've used Java's ArrayBlockingQueue<> to send requests to a background thread. And I've used Gdx.app.postRunnable() to get my background threads to push data to the render thread (such Runnables are run on the next frame, before render() is invoked).
回答2:
Not sure what you mean, but it is standard that the drawing on the screen (reflect changes to the display) is done by a dedicated, single thread (e.g. see Swing framework). This is because it is quite difficult to let multiple threads draw on the screen without messing things up -- only few implementations do this. Hence, if you are planning to implement the GUI framework yourself, single threaded drawing approach would be recommendable.
As for your business logic, it depends on many things. A very simple approach could indeed to spawn a new thread for each activity. These threads can then post the result to the said GUI thread. The problem with this approach is that your efficiency can drop significantly if many activities are concurrently executed at the same time, because in Java, every thread maps to a native OS thread. You can use thread pools to avoid that. Java standard library provides thread pools as ThreadPoolExecutor or if you want a bit higher abstraction, ExecutorService.
来源：https://stackoverflow.com/questions/12671089/java-threads-in-libgdx