Size Does Matter: Optimizing J2ME Applications - Java 2 Micro Edition Application Development - page 194

Chapter 8. Size Does Matter: Optimizing J2ME
Applications
IN THIS CHAPTER
• Reducing Class File Sizes
• Freeing Unused Variables and Resources
• Loop Condition Checking
• Avoiding Recursion
• Using Arrays Instead of Vectors
• Using Record Stores Instead of Heap Memory
• Distributing Functionality over Several Small MIDlets
• Fragmentation Problems
• User Interface Issues
Because of several computing and memory restrictions of mobile devices, you need to pay
particular attention to the size and performance of J2ME applications.
The most important hint is probably to keep everything as simple as possible. If an application
will be ported from the desktop, you may want to consider a re-implementation instead of trying
to downsize the existing program until it fits into J2ME.
Although most optimization possibilities depend on the individual application, in this chapter we'll
show you some general approaches and hints for saving resources. Unfortunately, there is often a
tradeoff between execution speed and memory consumption. Thus, not all of our hints will make
sense in all application scenarios.
Usually, memory in J2ME devices is divided into three different categories: program storage
space, persistent memory, and heap memory. The heap memory is used at runtime only and holds
all volatile objects. Depending on the device, there may be different limits on each of the types,
making trade-off decisions even more complicated.
Reducing Class File Sizes
When importing libraries, the fully qualified name—including the class and package name of each
imported function—is stored in the class file. Thus, limiting the number of imports may reduce the
size of a class file significantly. One large class will probably consume less memory than a set of
smaller classes, and the import overhead of additional convenience methods will often weigh more
than the code actually saved.
Freeing Unused Variables and Resources
The Java garbage collection mechanism usually frees unused objects automatically. "Unused"
from the point of view of the garbage collector means that the objects are not referenced from
somewhere else. If objects are no longer needed in a program, but are still referenced by a variable
or indirectly by another object, the garbage collector can't determine that the object can be
removed, and the corresponding memory is not reclaimed. Thus, if an object is allocated and then
no longer needed, but the variable holding the object is still in the valid scope, it may make sense