Standard we have the main thread which handles the UI and user input and if using OpenGLES we have the GLSurfaceView with it's renderer which resides in another thread.
I was wonderin how people are managing their logic, do you use the renderer thread for logic and drawing or do you create another thread on android for the logic?
And if you have 3 threads how do you keep logic and drawing synchronized?
Wilds
Posts: 78Member
Comments
-=Hicsy=-
PM me Facebook
Doing it this way, the UI will remain responsive if the graphics or game logic get stuck on something. The framerate is controlled by the OpenGL thread, so fps should be fairly constant, even if your game logic starts struggling to keep up.
I can't comment on performance, but your game will definitely remain responsive if you use a 3 thread structure.
However, there is also how easy it is to program. Android UI elements will throw errors if you call methods on them (like TextView.setText(framesPerSecond); from say the GLThread)
Confusingly, there are 4 ways to communicate between the UI thread and other threads in android:
1. AsyncTask thread: This is a special thread (in the form of an interface) that has a couple of methods that you implement to be run in the UI thread. I have used this in the past, but it is a pain to wrap your head around, and restrictive in letting you call methods outside of the AsyncTask (possibly anonymous) class. There are some hacks to get around this, but they are nasty
2. Handler class. This is a class that requires a Handler.Callback interface in its constructor, with methods inside that interface being called in the UI thread on its next pass. It lets you pass objects packaged inside a 'message' plus an int flag system to let you know where the message came from
3. Post method on either context or a specific view. This lets you post a runnable to be run on that view/context's next pass of the UI thread. However, you need either to pass around views or the context object, both of which can, if not correctly handled, cause memory leaks when the app is sent into the background or if you're doing something with a service or interacting with bits of android outside the immediate lifecycle of your app/activity.
4. Shared variables. You can just change the same variable / object from multiple threads. You have to have an AtomicInteger lock or something similar plus the synchronized keyword all over the place or you can end up in trouble. Plus you might end up locking the UI or GLThread when your game logic thread gets caught in an infinite loop or something, thus making the whole thing unresponsive and defeating the point of threading anyway
I have a combination approach. The UI thread writes to shared objects that other threads then read. Then I have my own event class that UI widgets (textViews etc) can use to have methods called on them (basically update methods) when a variable in the target object changes due to the GLThread or game logic doing something, with that update method being called in the UI thread using the post technique.
Now there are some frameworks that basically do the same thing as I talked about above (though I forget the name of the one I had in mind), so you don't need to go all crazy trying to debug threading stuff, but unless you're writing your own engine, this stuff is probably already figured out for you and you just need to find how the engine makers have solved these problems and work with that
Website