Archive for December, 2010

Performance in 2D Canvas App / Game on Android

December 4th, 2010 3 comments

While I was reviewing a lot of game-code and examples, I learned a lot by mistake. Before you are running in similar problems i have summed up some information that might be interesting.

Common Advices:

  • Strings are bad. Because as you might know Strings are immutable. So if you have Methods like setText(“foo”) in combination with a frame-drawing Method you might ask yourself why the Garbage Collector is Running all the Time and Cleaning up thousands of Objects.
  • String-Objects are not the only Objects that accidentally allocated at run-time. You should aim for a Zero-Garbage-Collection Approach. I know that you might have to break some rules that may be strange, but if you are aiming for a animated Game on a Canvas Surface, you won’t be happy with the GC running while animations taking place.
  • Stop Allocating stuff. ArrayLists, Hashmaps, are Bad. Enumerations are bad, Collections in general are bad. Mostly because they are implicitly allocation memory by making shadow copies of themselves, or other strange stuff you don’t want happening at run-time.
  • You will read a lot about multi-threading Games. This might be true for OpenGL Games, because while the GPU is flushing the graphics to the surface you can calculate your Game Objects in parallel. For a 2D Canvas Game this is not mandatory because Canvas is a CPU based drawing and you won’t see any significant benefit by Multi-threading.
  • Furthermore you can tune the Bitmaps you are Loading. In general you have to preload all your Bitmaps up in front. By default this is done in the ARGB-8888 Color Mode (32 bit). If you need a Alpha Channel you might be faster if you load the Bitmaps in 16 bit with Alpha (ARGB-4444), or the fastest way in RGB 565 (without Alpha). Your can do that with Options like this.
    private static BitmapFactory.Options sBitmapOptions    = new BitmapFactory.Options();
    sBitmapOptions.inPreferredConfig = Bitmap.Config.RGB_565;
  • Sounds: Preload everything and use the OGG Format with lowest possible settings. If you are having Files > 100kb you will run into OutOfHeadMemory Exceptions.
  • Math: If you are using Math.random() or Math.sqrt() frequently you should consider some other ways to calculate those equations. There are some other Implementations that are much faster than the standard Math tools provided by Java. (e.g google for “Fast Square Root Java”)
  • Because of the Garbage Collector you should re-implement your own Fixed-Sized-Array to avoid Collection Lists.
  • Generic Iterating is bad. Like the fancy for(int Moo: mooList) looks sexy, it creates a Iterator at Runtime that leads to : *tusch* Garbage Collection.
  • You should 100% be sure that you never ever create a Object at Runtime. This can be tricky . In my Case i want to serialize some of my Game Data and realized that Matrix() is not Serializable. Solution : Pass a static Matrix to the Method.
  • Method calls are more expensive than simply referencing the public value.
  • Method calls that Return Values should be avoided. Better provide the Method with a Reference that you want to work on. So Instead of
    public ReturnObject solveThis(123, 32);
    // better
    public void solveThis(123, 32, myObjectRef);
  • Ask yourself honestly how often you need to “update” something. Like a Score. You don’t have to update the Score 40 times / Second.
  • Filter Touch Events. If you have a Application that has to react to a push , maybe consider only to catch the UP Event. Flooding a Surface View Thread with hundreds of touch Events is not a good Idea. If you have to trace every move, you can Thread.sleep(xy) the Touch Method to prevent Flooding of Values.
  • It’s always hard to cover all possible Devices / Display Resolutions. In a Game you have to preload stuff, so you should initialize a Display Strategy first. Then load the appropriate images.

If you need more informations on certain points, or you have some good other ideads let me know.