J2ME memory footprint and optimization method

I want to do j2me people, especially like me to do mobile phone games, will certainly outofmemoryerror this unusual abhorrence, especially in the old 40 such a perverted model, even to this anomaly has generated fear. I'm glad I'm not doing this now, but I feel sorry for the comrades who are still playing for this model transplant. In order to be able to alleviate their pain slightly, but also for the vast number of J2ME practitioners and enthusiasts to minimize the number of meetings with the unusual, Cocomo will share their experience.

First of all to understand the analysis of memory footprint, there are generally two kinds: the simulator with tools and runtime class methods.

Simulator with tool: WTK looks like a memory Monitor, and a lot of academics talk about how he uses it, but I don't know how many people are using it. As far as I know about him, running your program first will slow the mess up, which is simply unbearable for the game developer. But I still kept him running for half an hour for research purposes, and he didn't realize that he couldn't show the correct memory footprint. I loaded a large picture of his memory line seems to have only a slight fluctuation and stay in place, ah, it seems to have come out of the show. I usually use the 7210 simulator with the memory monitor, the simulation is very accurate, but the only drawback is that there is too little memory, only 200K. I also see some people using 3220 of the simulator to monitor memory, as if the memory slightly larger, I have not had time to try to write a program for the old 40, fortunately.

Runtime class method: I often use this statement System.out.println (Runtime.getruntime (). Freememory ()), and then integrated into my engine, he was able to display the current remaining memory. I don't remember how many times I used it in old 40 to look for peak memory consumption.

Learn how to analyze memory to see the culprit for memory footprint: programs and resources.

Program: Classes are compiled into class bytecode files that are loaded into memory with the MIDlet boot, and are all added at once. That is to say, the more the number of classes in the MIDlet, the longer a single class program, the more string constants and data within the class, the larger the compiled class file, and the more memory it takes up after loading. I often use the runtime method in the constructor of the MIDlet class to view the amount of memory consumed by the entire program after MIDlet started.

Optimization method:

1. Some comrades have written the MIDlet program into two classes to reduce memory footprint, but at the expense of the Java OOP feature. This disadvantage is particularly apparent when the procedure is large. And Cocomo once encountered a single class too large, loading time is too long to violate the visionary about 6 seconds time limit of the case. So my current program with the engine is typically 6-7 classes.

2. Try to write elegant code, reduce the number of functions, in the release of the program to remove try catch, minimize the number of program lines, which is generally in the old 40 no way, now Cocomo has not relied on this to save memory.

3. Write the data and string into the file, load the memory in time, and set to NULL when not.

4.I/O Operation GetClass (). getResourceAsStream (file), database manipulation Recordstore.openrecordstore (name, true); Sound creation Manager.createplayer (); Image creation Image.createimage (file), which consumes a large amount of memory over a short period of time and is released later, if the MIDlet program has insufficient memory left, a memory overflow occurs when these functions are frequently invoked, Generating the so-called peak memory, especially in the old 40 is more common. When you meet the nasty OutOfMemoryError again, use runtime to find out where the peak memory occurs and try to separate these statements, and flexibly use System.GC () to recover in time.

Resources:

Photo: Is the memory of the large, especially mobile game pictures of many resources. The calculation of the footprint of the image resource in memory becomes the regular work of J2ME game developers, Cocomo to explain how to calculate the footprint of a picture in memory:

Memory Footprint = width * High * pixel bytes, where the number of pixel bytes varies depending on the model.

For example, the memory footprint of a 64*64 picture on 7210 is =64*64*1.5=6144 (byte) =6k, the amount of memory consumed on S60 =64*64*2=8192 (bytes) =8k. The number of pixel bytes varies depending on the model, for example, 7210 is a 4096 color model, that is, 12 bits to represent a pixel, so multiply 1.5, and S60 is a 65536-color model, with 16 bits to represent a pixel, so multiply by 2.

Optimization method:

Some people think that compressing pictures can save memory, this idea is wrong. According to the above interpretation of the picture loading memory only with the width of the relationship, and the size of the picture data has no relationship, compressed pictures can only reduce the size of the jar and can not reduce memory consumption.

1. Static method: Reduce the size of the picture, the result of course small. According to this idea appeared the animation editor and such tools, such as Gameloft Prince of Persia, the characters are divided so that the body's parts can be reused, each part of the compact placement is for less picture size, make full use of the picture in every inch of space.

2. Dynamic method: Reduce the number of pictures loaded in memory at the same time. Cocomo once encountered this situation in the Fire Shadow Warrior Project, when there are 6 kinds of monsters, if at the same time in the presence of the old 40 must have exploded, but each turn only two to three kinds of monsters, so each off only need to load the appearance of the monster picture can be. Now think of it at that time to do this project in the old 40 overflow frequency out, really kill me.

Voice: Sound is also a resource that consumes memory, and the byte of the voice track will be converted into a stream of bytes to be loaded into memory. This reduces the amount of memory consumed by reducing the byte of the track. The current Gameloft is to convert mid to Ott and then bytearrayinputstream to create a player using the sound conversion tool.