Unfortunately, you do have to avoid garbage collection during play when writing real-time games on Android right now. The garbage collector usually stops the world for hundreds of milliseconds. For a smooth experience you need to get a frame out every 33 milliseconds, preferably every 16ms. Maybe someday Android will have an incremental and/or concurrent GC and someday the majority of the phones on the market will be upgraded to that Android version.
But the reality is, if you are writing a real-time game right now, you will see big jerks in the movement of your game until you avoid GC. Imagine Angry Birds where the birds just judder randomly in flight several times before they land instead of smooth arc. When you study what is ruining the smooth movement in your game, you'll learn you have to avoid GC - it doesn't matter if you are a C++ programmer or not. Re background GCs, they aren't as bad because they aren't in your process, and there is less you can do about them anyway. I find turning on airplane mode helps avoid them, however. Sometimes it is nice to avoid them when testing because that way you don't have to go check logcat to see which process ID the GC fired in when you see a judder. On Oct 20, 2:43 am, Peter Webb <[email protected]> wrote: > > The first thing I recommend watching is this google > > presentation:http://www.google.com/events/io/2009/sessions/WritingRealTimeGamesAnd... > > I think the advice given in this video is basically wrong. > > It is a presentation done by a C++ programmer who has just written his > first Java program. His idea of managing GC lag is to not instantiate > any classes at all in real-time sections of the code. He spends a > great deal of time explaining how difficult that is. > > This flies in the face of modern software design, which says build it > right then build it fast. He basically says throw away most of the > benefits of using auto-GC languages such as Java by writing your code > in a very artifical way which avoids allocating memory. > > It is a pity because he could have told us some things we (or at least > I) don't know, such as how the GC is triggered, whether it is device > dependent, whather there are calls to suspend repacking the heap, > practical stuff about how to best use a GC language for real-time > apps. Trying to avoid anything at all which might cause GC to happen > is throwing the baby out with the bathwater. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
