Rants And Ramblings About Mobile Technology
Anders Borg writing about the fun and crazy world of mobile and Internet service technologies.
You can also read the blog via Twitter or your phone via wap.abiro.com. See the left menu for more news.
Comments on blog entries are moderated, but I'm rather liberal as long as it's not blatant advertising.
For general comments, advertising and contribution queries, please use the feedback form.
Monday, February 05, 2007
Jog your application memory
Memory Management in J2ME gives an introduction to how memory is managed in Java ME (or at least CLDC/MIDP). This is the most technical note for today. I promise.
Here's some advice of my own for mobile application developers, partly contradicting the note. Some are blatantly obvious:
Here's some advice of my own for mobile application developers, partly contradicting the note. Some are blatantly obvious:
- Don't use System.gc(), as you never know when/if it will kick in.
- Minimize the amount and size of objects you instantiate. Obviously!
- Re-use larger instantiated object, e.g. arrays. Objects can always be 'relinked' to other object variables, so setting up e.g. reusable round-robin buffers etc is simple and recommended.
- De-reference objects (set associated object variables to null) that you know you will never use again. Of course perform any closing etc before you de-reference, and watch out for possible threads that are still using those 'nulled' object variables, or you might be in for some nasty surprises.
- Objects are always allocated on the heap. Java has no notion of stack-allocated objects like in C/C++ (except for primitive types).
- Object variables are simply pointers to allocated objects. They are typed and managed, but they are still just pointers. That also makes handling of objects incredibly flexible, 'aesthetic' (for lack of a better word) and consistent.
- You can't explicitly de-allocate objects. That's done for you (in most cases gracefully) by the system.
