cocos2d-x and iOS memory Management analysis ( reduces memory pressure in the game)
Monkey original, welcome reprint. Reprint Please specify: reproduced from cocos2d Development Network--cocos2dev.com, thank you! Years
Original address : http://www.cocos2dev.com/?p=281
Note: I have previously written about how cocos2d-x optimizes memory usage and how to deal with games when memory is low. Today in micro-blog saw a friend introduced the next memory, quite detailed. I don't know who wrote it, I recorded it.
One,IOS and picture memory
On IOS , the image is automatically scaled to 2 of the N -th square size. For example, a picture of 1024*1025 , the memory occupied by a picture of a 1024*2048 is consistent. The equation for the calculation of the memory size of the picture is the length * width. The memory occupied by such a 512*512 is 512*512*4 = 1M. Other dimensions and so on. (The maximum size supported onps:ios is 2048*2048).
Two,cocos2d-x 's picture cache
Cocos2d-x when you construct an elf, you use spritewithfile or spritewithspriteframename , either way,cocos2d-x Will load this image into the cache. If this is the first time the image is loaded, it will be loaded into the cache and then read from the cache. If the cache already exists, it is extracted directly from the cache, excluding the loading process.
The cache of pictures is mainly handled by the following two classes:ccspriteframecache, cctexturecache
Ccspriteframecache Loaded is a large piece of stitching, each small image is only a large map of an area, these areas of information are saved in the plist file. It can be loaded into this area only by the name of the small map.
Cctexturecache is the normal picture cache, all of our directly loaded images will be put into this cache by default to improve the efficiency of the call.
As a result, the entire picture is loaded into memory each time a picture is loaded, or when a mosaic image is loaded via plist . If you don't release it, it will always be occupied.
third, render the memory.
Do not assume that when calculating memory, only the memory loaded into the cache can be computed. Take a picture of 1024*1024 as an example.
Ccsprite *psprite = Ccsprite::spritewithfile ("A.png");
After calling the upper line of code, you can see in the LEAKS tool that it adds approximately 4M of memory. and then call
AddChild (Psprite);
At this point, the memory is increased by 4M. That is, a picture, if it needs to be rendered, the memory it occupies will be X2.
Take a look at the pictures loaded by plist , such as the large image size of 2048*2048. Want to load a small picture of one of the 32*32
Ccspriteframecache::sharedspriteframecache ()->addspriteframeswithfile ("B.plist");
Memory increase at this time 16M(sweat)
Ccsprite *pspriteframe = Ccsprite::spritewithspriteframename ("B1.png");
B.png size is 32*32, thinking that is to add a little memory, but the reality is to increase the 16M of memory. That is, if you render a portion of it, the entire picture is loaded together.
But the situation is not so bad, these already rendered pictures, if loaded again, memory will not continue to rise, such as adding another area of the b.plist , image memory or a total increase 16+16 = 32M , and will not continue to rise.
four, Cache release
If the game has many scenes, the memory of the previous scene can be completely freed when switching scenes, preventing the total memory from being too high .
Cctexturecache::sharedtexturecache ()->removealltextures (); release all pictures loaded so far
Cctexturecache::sharedtexturecache ()->removeunusedtextures (); Release the Cctexturecache::sharedtexturecache ()->removetexture () from the picture with the reference count of 1 ; Release a picture individually
Ccspriteframecache similar to the method of Cctexturecache release.
It is important to note that the time to release, generally when switching scenes to release resources, if you switch from A scene to the B scene, call the function order of b::init ()---->a::exit ()---->b::o Nenter ().
If you use a switch effect, such as a function such as ctransitionjumpzoom::transitionwithduration , the call order of the function changes to b::init ()---->b::o Nenter ()---->a::exit () .
And the second way there will be a moment to stack two of scenes of resources together, if not to take excessive, it is likely to crash due to memory crunch.
Sometimes forcing the release of all resources causes an animation that is being executed to lose its reference and eject the exception, which can be called Ccactionmanager::sharedmanager ()->removeallactions (); To solve.
Five, Memory optimized
Optimization of the experience is to try to splice pictures, so that the picture side length as long as possible to maintain 2 of the N -side and loaded very full. Note, however, that a logically related picture is packaged in a larger picture, and the other is that the distribution of layers is considered when packing. Because Ccspritebatchnode may be used in order to render efficiency ; The images in the same Batchnode are at one level, so they have to be packaged into different plist based on the hierarchical relationships of each image. Sometimes memory and efficiency can not be combined, only as far as possible to balance.
Six, other
The last one is attached to each generationIOSMemory limitations of the device
Equipment Recommended memory Maximum Memory
Ipad2/iphone4s/iphone4 170-180MB 512MB
Ipad/ipod touch3,4/iphone3gs 40-80MB 256MB
IPod touch1,2/iphone3g/iphone1 25MB 128MB
The above recommended memory is only some people's own test results, the available RAM is not more than half of the maximum memory, if the program exceeds the maximum memory of half, it may be hung off.
In addition, in the LEAKS to see the simulator and the total memory of the real machine, there will be a large discrepancy. The results in the simulator are closer to the actual ones.
Cocos2d-x and iOS memory management analysis (reduces memory pressure in the game)