Performance tips for Android

Revision as of 22:55, 24 June 2010 by Admin (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Performance tips for Android

These are general tips and true for all Android application, not just for jPCT-AE. It's a collection of things, that i found out to be most important during the development of AE. Remember that this is targeted to writing real time apps like games. If you are not doing this, your mileage may vary.

If you are used to the best pratices of the desktop Java world and praise OO and the mightly VM at least twice a day, the following tips can be very disturbing for you. You have been warned...

Avoid object creations

If possible, create your objects before starting the actual game. Or at least try to reuse old objects. Object creation is expensive on Android. Try to pool objects if possible. jPCT-AE offers some help for this. For example, there's a static create()-method in SimpleVector as an alternative to the constructor. Using this method allows jPCT to optimize SimpleVector usage to a small degree.

Avoid object destruction

If an object isn't referenced any longer, it is free to be garbage collected. This is actually a good thing as it frees some memory. However, on Android garbage collection is very slow. You can spend 100-200ms on one run and free 10bytes at the end. So if possible, reuse objects and use object pools to avoid too many objects being garbage collected in your game's main loop. You and your players will notice a 100ms lag! jPCT-AE is already optimized to create/destroy as few objects as possible for the most parts.

Watch the garbage collection

As said, it's dog slow. It might be a good idea to place some finalize()/gc() calls after doing your setup work and before starting the actual game. jPCT offer some help for this in the util-package in the form of the MemoryHelper.

Avoid getters and setters

If possible, make your attributes public or package public. Don't use getters or setters, i.e. instead of




Avoid interfaces

Write classes, not interfaces. This is an Android application, most likely a'll start from scratch anyway on your next project. You don't need this interface that allows to swap implementations if needed. You are not going to do this anyway, it just costs you performance.