Cocos2d-x and ios memory management analysis (reduces memory pressure in the game)

I. IOS and image memory
On IOS, the image is automatically scaled to the Npower of 2. For example, a 1024*1025 image occupies the same memory as a 1024*2048 image. The formula for calculating the memory used by the image is: length * width * 4. In this case, the memory occupied by 512*512 is 512*512*4 = 1 M. Other dimensions, and so on. (Ps: the maximum size supported on IOS is 2048*2048 ).
 
 
2. cocos2d-x image Cache
The Cocos2d-x uses spriteWithFile or spriteWithSpriteFrameName when constructing an Sprite. Either way, the cocos2d-x loads the image into the cache. If the image is loaded for the first time, the image will be first loaded to the cache and then read from the cache. If the cache already exists, it is extracted directly from the cache, eliminating the need for loading.
 
The image cache is mainly processed by the following two classes: CCSpriteFrameCache and CCTextureCache.
 
CCSpriteFrameCache loads a spliced big image. Each small image is only a region in the big image. The region information is saved in the plist file. You can load the image to this region based on the name of the thumbnail.
 
CCTextureCache is a normal image cache. By default, all images directly loaded are stored in this cache to improve call efficiency.
Therefore, each time an image is loaded or a spliced image is loaded using plist, the entire image is loaded into the memory. If you do not release it, it will remain in use.
 
 
3. Rendering Memory.
Do not think that during memory computing, only the memory loaded into the cache can be computed. Take a 1024*1024 image as an example.
CCSprite * pSprite = CCSprite: spriteWithFile ("a.png ");
 
After calling the code above, you can see in the LEAKS tool that the memory is increased by about 4 MB. Then call
AddChild (pSprite );
 
At this time, the memory is increased by 4 MB. That is, if an image needs to be rendered, the memory occupied by it will be X2.
 
Let's take a look at the image loaded through plist. For example, the size of this large image is 2048*2048. To load a 32*32 small image
CCSpriteFrameCache: sharedSpriteFrameCache ()-> addSpriteFramesWithFile ("B. plist ");
At this time, the memory is increased by 16 MB (perspiration)
CCSprite * pSpriteFrame = CCSprite: spriteWithSpriteFrameName ("b1.png ");
B .png is 32*32 in size. If you want to increase the memory by a little bit, you can increase the memory by 16 Mb. That is, as long as a part of the rendering is completed, the entire image will be loaded together.
 
However, the situation is not so bad. If the rendered images are loaded again, the memory will not continue to increase. For example, an increase of 100 B. in another area of plist, the image memory is increased by 16 + 16 = 32 M, rather than increasing.
 
 
4. Release the cache
If the game has many scenarios, you can release all the memory in the previous scenario when switching the scenario to prevent the total memory from being too high.
CCTextureCache: sharedTextureCache ()-> removeAllTextures (); release all loaded images so far
CCTextureCache: sharedTextureCache ()-> removeUnusedTextures (); releases the CCTextureCache: sharedTextureCache ()-> removeTexture (); separately releases an image
The CCSpriteFrameCache and CCTextureCache release methods are similar.
It is worth noting that the release time is usually used to release resources during scenario switching. If you switch from scenario A to scenario B, the call sequence is B: init () ---->:: exit () ----> B: onEnter ().
If the switching effect is used, such as CTransitionJumpZoom: transitionWithDuration, the call sequence of the function is changed to B: init () ----> B: onEnter () ---->:: exit ().
In addition, the second method overwrites the resources of the two scenarios at an instant. If you do not overwrite the resources, the system may crash due to memory shortage.
Sometimes, when all resources are forcibly released, an exception occurs when an animation being executed is out of reference. You can call CCActionManager: sharedManager ()-> removeAllActions (); to solve this problem.
 
 
5. Memory Optimization
The optimization is to try to splice the image, so that the side length of the image is as long as possible to maintain the Npower of 2 and the installation is very full. However, it should be noted that images with logical relationships should be packaged in a large image as much as possible, and the distribution of layers should be considered during packaging. For rendering efficiency, CCSpriteBatchNode may be used. Images in the same BatchNode are all at the same level. Therefore, they must be packaged into different plist Layers Based on the hierarchical relationship of each image. Sometimes the memory and efficiency cannot be both at the same time. You can only try to balance it as much as possible.
 
 
Vi. Others
The memory limit of each generation of IOS devices is appended to www.2cto.com.
Recommended maximum memory size for devices
IPad2/iPhone4s/iphone4 170-180 mb 512 mb
IPad/iPod touch3, 4/iphone3gs 40-80 mb 256 mb
IPod touch1, 2/iPhone3g/iPhone1 25 mb 128 mb
The recommended memory is only the result of some tests. The available RAM is not more than half of the maximum memory. If the program exceeds half of the maximum memory, it may fail.
In addition, you can view the total memory of the simulator and the real machine in LEAKS. The result in the simulator is closer to the actual one.
Author: yanghuiliu