Memory usage and Optimization Methods

Memory usage and Optimization Methods Author: Jiang Tao Source: blog Responsible editor: Fangzhou  

I want to be a person who wants to be a j2-based player, especially a mobile game like mine, will definitely hate the exception of outofmemoryerror, especially on Abnormal models like the old 40, even fear of this exception. Fortunately, I am not using this model now. I feel sorry for the comrades who are still porting the game to this model. Cocomo will share his experience to help ease their pain a little, and to minimize the number of times they can meet with the exception for the majority of practitioners and fans of the agent.

First, let's take a look at the methods used to analyze memory usage. There are generally two methods: the simulator tool and the runtime method.

The built-in simulator tool: wtk seems to have a memory monitor, and many scholars also boast about its usage, but I don't know how many people actually use it. As far as I know him, first run his yoursProgramIt will be slow and messy, which is simply intolerable for game developers. But for research purposes, I still let him run for half an hour and found that he could not display the correct memory usage, after I loaded a large image, his memory line seemed to have only slight fluctuations and remained in the original position. I usually use the memory monitor that comes with the 7210 simulator. The simulation is very accurate, but the only drawback is that the memory is too small to be 200 kb. I have also seen some people use 3220 simulators to monitor the memory. It seems that the memory is a little bigger. Before I can try it, I don't have to write programs for the old 40. Fortunately.
Runtime class method: I often use this statement system. out. println (runtime. getruntime (). freememory (); later integrated into my engine, he can display the current remaining memory. I don't remember how many times I used it to find the peak memory usage in the old 40.

I learned how to analyze the memory to find out the culprit in memory usage: programs and resources.

Program: the class will be compiled into the class bytecode file and loaded into the memory at the startup of the MIDlet, and all files will be added at one time. That is to say, the more classes in the MIDlet, the longer a single class program, the more string constants and data in the class, the larger the compiled class file and the more memory occupied after loading. I often use the runtime method in the constructor of the MIDlet class to check the memory usage of the entire program after the MIDlet starts.

Optimization Method:

1. Some comrades write the MIDlet program into two classes to reduce memory usage, but at the cost of Java's OOP features. This disadvantage is especially apparent when the program is large. In addition, cocomo has encountered a situation where a single class is too large and the loading time is too long, which violates the logo 6 s time limit related to the treasure chest. Therefore, my current program and belt engine are generally 6-7 classes.

2. Try to write elegantCodeTo reduce the number of functions, remove try catch when the program is released, and minimize the number of program lines. This is generally not a solution on the old 40, now cocomo does not rely on this to save memory.

3. Write Data and strings into the file. When using the file, load the data into the memory. If not, set it to null.

4.I/O operation getclass (). getresourceasstream (File);, database operations for recordstore. openrecordstore (name, true);, sound creation manager. createplayer ();, image creation image. createimage (File); occupies a large amount of memory in a short period of time and is released later. If the memory surplus of the MIDlet program is insufficient, memory overflow occurs when these functions are frequently called, resulting in so-called memory peaks, especially in the old 40. When you meet the annoying outofmemoryerror again, use runtime to find the location where the memory peak occurs and try to call these statements separately, and use system. GC () to recycle them in a timely manner.

Resource:

Image: Large Memory users, especially mobile game image resources. Computing the usage of image resources in memory has become a frequent task for developers of j2s games. cocomo explains how to calculate the usage of images in memory:

Memory usage = width * height * Number of pixel bytes, in which the number of pixel bytes varies by model.

For example, the memory usage of a 64*64 image on 7210 = 64*64*1.5 = 6144 (bytes) = 6 K. memory usage on s60 = 64*64*2 = 8192 (bytes) = 8 K. The number of pixel bytes varies by model. For example, 7210 is a 4096-color model, that is, 12-bit is used to represent a pixel. Therefore, 1.5 is multiplied, while s60 is a 65536-color model, 16 bits are used to represent a pixel, So we multiply by 2.

Optimization Method:

Some people think that compressing images can save memory, which is wrong. According to the above explanation, after the image is loaded into the memory, it only has a relationship with the width and height, and has nothing to do with the size of the image data. The compressed image can only reduce the jar size, but cannot reduce the memory usage.

1. static mode: reduce the image size. The result is smaller than the width or height. According to this idea, tools such as the animation editor emerged. For example, the parts of the human body can be reused after the characters are separated by the Persian prince gameloft, make full use of every inch of space in the image.

2. Dynamic Method: Reduce the number of images loaded into memory at the same time. Cocomo once encountered this situation in the huoying samurai project. At that time, there were 6 types of monsters. If there were at the same time loaded in the old 40, it would have exploded, however, there are only two or three monsters at each level, so each level only needs to load the monster pictures at the level. Now, I think that this project was frequently used up on the old 40, and it really killed me.

Sound: Sound is also a resource that consumes a lot of memory. The Byte occupied by sound tracks will be converted into word throttling and loaded into memory. Therefore, reducing the byte occupied by audio tracks can reduce memory consumption. Currently, gameloft uses a sound conversion tool to convert mid to Ott and then bytearrayinputstream to create a player.