Sometimes while loading game onto your favorite Java device we gets an out-of-memory message. In those cases we need to optimize our code, and strip it down to make it fit. Optimization techniques are
Code optimization can be divided into five categories:
- Optimizations to reduce code size
- Optimizations to speed up the code execution
- Optimizations to decrease memory usage
- Optimizations to increase device availability
- Optimizations to increase network performance
Code Size Optimizations
When a game is installed onto a device via a synch cable or over the network, the JAR file is unpacked into the device’s storage memory. Every time the game is executed, the execution byte code (Java classes) are copied into the working memory (heap memory) and processed. The larger the classes are, the less heap memory is left for the game. The less heap memory, the slower things run and the greater the chances that the game will run out of memory completely. So, given all that, making game classes as small as possible is of the utmost importance.
Making Code Faster
According to specification, devices that run J2ME CLDC have 16- or 32-bit processors with low frequencies, in the range between a few megahertz (smart phones), to a few hundred (Windows CE-based devices). The higher the clock speed is, the more power-hungry devices are. Unfortunately, all small devices are limited by their batteries or accumulators—and most devices aim to have at least 24 hours of continuous battery usage. As such, device manufacturers have purposely installed low-powered chipsets. Making code run fast, then, is another key goal of micro game development.
Decreasing Memory
Devices have different ranges of available working memory. Smart phones only have between 128KB and 256KB of heap memory. Developers who write games in native assembly code, or a low-level languages such as C++, can easily compact their code to be as efficient as possible. Java developers, however, must deal with a lot of overhead, such as memory allocation (object construction) and deallocation (garbage collection). A chunk of memory is also eaten up by the Java Virtual Machine (KVM), which runs the byte code. As you begin to create Java games and test them on real devices, you’ll probably run across out-of-memory error messages.
Device Availability
Different actions, such as the background display light or vibrations, might consume extra power and force the device into off-line mode. With correct development, and by avoiding the overuse of various calls, your game can have a better impact on a device’s lifetime.
Network Performance
If your game is multiplayer-capable, then you’ll need to send and receive messages over the network. In most cases, this network is awfully slow, with high latency and limited bandwidth. As such, it is important to make sure that every packet your game deals with is as compressed as possible.
Code Size Reductions
Making the execution code or JAR file smaller has several positive impacts on devices and game players:
- The smaller a JAR file is, the less time it takes to download it over the Internet. With fewer bytes to transfer, gamers will be charged less by their mobile operators, and be online and playing much faster.
- The smaller execution code is, the less time it takes to install, verify, and execute a game. Users will not have to wait for delays between stages.
- The less space classes take, the more heap memory is left for the game. Games usually allocate large tables (for example, for level design, a list of enemies, and so on) might run out of memory if there’s not enough elbow room.
- Some devices have explicit limits on the size of a JAR file. For example, i-mode applications may not be larger than 10 kilobytes.
The code size optimizations are not always sufficient. Often times, game functionality must be stripped down or simplified.
There are three techniques used to perform code reduction:
- Shorten the names of variables and methods in the code.
- Avoid a pure object-oriented way of programming.
- Make the image sizes smaller.
- Obfuscators and Name-Shortening
Each letter in the name of the class adds an additional byte to the execution code.
Each letter in the name of the public method adds an additional byte to the execution code. Protected and private methods don’t have any impact on the class size.
Also, the name length of local variables and parameters don’t change the size of the class.
Every letter in the name of the constructor adds an additional byte to the class file.
So don’t worry for shortening names for that we use a special application called obfuscator.An obfuscator’s main job is to protect applications against illegal decompilation by making the code hard to read and difficult to unravel. The obfuscator is run only when the code is ready to be released. It takes normal Java files and outputs tight, special class files. Luckily for J2ME developers, most obfuscators will also drastically shorten class, variable, and method names. An obfuscator’s output code is typically 5 to 20 percent smaller than original class files. The size of the reduction is based on the number of classes, methods, and variables.
