Chaning coding style due to Android GC performance, how far is too far?
Posted
by Benju
on Stack Overflow
See other posts from Stack Overflow
or by Benju
Published on 2010-04-07T18:14:36Z
Indexed on
2010/04/07
18:43 UTC
Read the original article
Hit count: 290
I keep hearing that Android applications should try to limit the number of objects created in order to reduce the workload on the garbage collector. It makes sense that you may not want to created massive numbers of objects to track on a limited memory footprint, for example on a traditional server application created 100,000 objects within a few seconds would not be unheard of.
The problem is how far should I take this? I've seen tons of examples of Android applications relying on static state in order supposedly "speed things up". Does increasing the number of instances that need to be garbage collected from dozens to hundreds really make that big of a difference? I can imagine changing my coding style to now created hundreds of thousands of objects like you might have on a full-blown Java-EE server but relying on a bunch of static state to (supposedly) reduce the number of objects to be garbage collected seems odd.
How much is it really necessary to change your coding style in order to create performance Android apps?
© Stack Overflow or respective owner