s40 machine has better memory for games, popular science.

There are two main types of memory usage, namely programs and resources. ·The program class will be compiled into a class bytecode file and loaded into the memory when the MIDlet is started, and it will be added all at once. That is to say, the more classes there are in MIDlet, the longer a single class program, and the more string constants and data within the class, the larger the compiled class file will be and the more memory it will occupy after loading. I often use the Runtime method in the constructor of the MIDlet class to check the amount of memory occupied by the entire program after the MIDlet is started. //Optimization method: 1. The MIDlet program is written into two classes to reduce memory usage, but at the expense of Java's OOP features. This disadvantage will be particularly obvious when the program is relatively large. Moreover, CoCoMo once encountered a situation where a single class was too large and the loading time was too long, which violated the 6-second limit on the logo of the treasure chest. //2. Try to write elegant code, reduce the number of functions, remove try catch when the program is released, and minimize the number of program lines. This is generally not possible on the old 40, but now CoCoMo no longer relies on this to save memory. //3. Write data and strings into files, load them into memory when in use, and set them to null when not in use. 4. I/O operation getClass(). getResourceAsStream(file);, database operation RecordStore. openRecordStore(name, true);, Sound Creation Manager. createPlayer();, image creation Image. createImage(file); will occupy a large amount of memory in a short period of time and release it later. If the remaining memory of the MIDlet program is insufficient, memory overflow will occur when these functions are called frequently, resulting in a so-called memory peak, which is especially common on the old 40. When encountering OutOfMemoryError again, use Runtime to find the location where the memory peak occurs and try to call these statements separately, and make flexible use of System. gc() to collect in time. //·Resources Pictures: They occupy a large amount of memory, especially mobile games with many picture resources. Calculating the memory usage of image resources has become a regular task for J2ME game developers. CoCoMo will explain how to calculate the memory usage of images: //Memory usage = width * height * number of pixel bytes, where the number of pixel bytes varies depending on the model. //For example, the memory usage of a 64*64 picture on the 7210 = 64*64*1.5 = 614 4 (bytes) = 6K, memory usage on S60 = 64*64*2 = 8192 (bytes) = 8K. The number of pixel bytes varies by model. For example, the 7210 is a 4096-color model, which means that 12 bits are used to represent a pixel, so multiply by 1.5, while the S60 is a 65536-color model, and 16 bits are used to represent a pixel, so multiply by 2. //Optimization method//It is wrong to think that compressing images can save memory. According to the above explanation, after the image is loaded into the memory, it is only related to the width and height, and has nothing to do with the size of the image data. Compressing the image can only reduce the jar size but not the memory usage. //1. Static method: Reduce the size of the picture. If the width and height are smaller, the result will be smaller. Based on this idea, tools such as animation editors have appeared, such as Gameloft's Prince of Persia. After the characters are divided, the parts of the human body can be reused. The compact placement of each part is to reduce the size of the picture and make full use of every inch of space in the picture. //2. Dynamic method: Reduce the number of pictures loaded into memory at the same time. CoCoMo once encountered this situation in the Naruto Samurai project. There were 6 types of monsters at that time. If they were loaded into the memory at the same time, it would definitely explode on the old 40. However, only two to three types of monsters appeared in each level, so each level only needed to load the pictures of the monsters that appeared in that level. Now that I think about this project, overflows occurred frequently on the old 40. //Sound//Sound is also a relatively memory-consuming resource. The bytes occupied by the audio track in the sound will be converted into a byte stream and loaded into the memory. Therefore, reducing the bytes occupied by the audio track can reduce memory consumption. Gameloft's current approach is to use a sound conversion tool to convert mid to ott, and then change it into a ByteArrayInputStream byte stream to create a Player.