What about cocos2d-x performance optimization, cocos2d-x Performance Optimization

What about cocos2d-x performance optimization, cocos2d-x Performance Optimization

I was doing performance optimization on my project a few years ago. Although the performance problem is always concerned during development, it still needs to be optimized for some time in the future, I have encountered many pitfalls. I would like to share with you and take notes. In addition, you are welcome to share your experiences in this area.

The main highlights of performance optimization are memory optimization and operating efficiency optimization.

1. Memory Optimization

When talking about memory optimization, first you need to know what will occupy the program's memory. There are two main optimizations: data and resources. First, let's talk about data, A short connection game client can process data in two ways: a silly client and a cache client, which can achieve almost zero data, because each interface is only responsible for display, of course, the data required for this interface will exist on the client side, but his memory occupation can be ignored, basically cannot be optimized, unless you have memory leakage. The client is responsible for some logic. It not only caches user data, but also configuration data (game data planned and configured ), the data size sometimes exceeds your imagination (not much smaller than the figure). Besides, resources are mainly graphs and sounds, to optimize these two types of resources, you only need to master the following principles (also applicable to data)

(1) do not ignore the memory release

In the j2s era, programmers often consciously release useless resources for interface switching because there is no universal engine or framework. However, in the era of smart machines, this "Good Habit" is often ignored because of the "power" of the system; I have seen programs in more than one project do not consider resource release when using cocos2d-x, because of the automatic recovery mechanism of the system, this is not even considered by some online projects. What you need to know about this is that the system's memory recovery mechanism is like this, and it will have a security "critical value ", note that this value is smaller than the limit of the system. Whenever the critical value is reached, the system will help you clean up the memory that you have not leaked. However, please do not trust this method too much. Although the critical value is less than the maximum value, assume that the critical value is 180 m, and the maximum value is 200 m. If you enter a scenario, the initial value is 175, but the critical value is not reached, but 30 m is loaded on this interface, before recycling, the memory has exceeded the maximum limit of MB, and will crash. Therefore, it is a good habit to actively delete useless resources. This principle includes data and resources.

(2) On-Demand Loading vs Cache

Since useless resources need to be deleted at any time, do we need no cache? It seems that these two methods are opposite. Some people may say that loading with use is a waste of efficiency. That's right. If you want to handle program performance well, these two methods cannot be seen in opposition, it should be used in combination. For image resources, I do this. I will put the public images used on each interface in an image board (or several images ), these images will be "resident" in the memory. This board will include frequently used buttons, backgrounds, and small icons. These images are cached. For other images, make sure that all images except public images used on this interface are put together. In this way, when you enter this interface, you only need to load these images. When you leave the interface, they need to be deleted. These are loaded with use. This principle is also used in data to read common data (loading time will be relatively long) into the memory, other data is loaded as needed. Note that data needs to be deleted when it is not used. I have seen some projects and data is never clear. Therefore, they do not have the concept of maximum memory, the memory will be like a snowball, and the larger the roll, until all the data is in the memory, this approach is similar to reading all the data.

(3) large images vs. small broken images? Memory limit

In fact, what cannot be solved by the memory size is "large images or small broken images", which involves the cooperation of art and programs, the sense of responsibility of the program, and so on, the interface of the program is easy to work with and can improve the program running efficiency, but the small image will save the memory. Of course, this also has a problem, which involves the memory ceiling, according to the current device, it is relatively safe to control the memory to about 120. It is also important to determine the actual memory ceiling for execution.

In addition to these principles, you have to wait until the cocos2d-x has some "pitfalls" about memory processing"

(1) After plist is deleted, is your image deleted?

In CCSpriteFrameCache, if the plist name is input in the removeSpriteFramesFromFile function, the data file of the image will be deleted. Specifically, the dictionary generated when the plist file is read is removed, however, to delete a specific image, you must call the removeUnusedTextures function of CCTextureCache. Note that you must call the previous function before calling it, using ccb will help you call removeSpriteFramesFromFile. In addition, if the plist name passed by removeSpriteFramesFromFile does not exist, problems may occur. The best way is to change removeSpriteFramesFromFile to Fault Tolerance, in addition, it is best to call removeSpriteFramesFromFile in the previous frame, and call removeUnusedTextures and dumpCachedTextureInfo in the next frame. This will take effect only when the referenced images are deleted.

(2) lua Memory leakage

Sometimes you need to log on again in the game. The common solution is to delete the part pointed to by the CCLuaEngine: defaultEngine () pointer. However, this crude method may cause some memory leaks. You need to add the following code before

pEngine->getLuaStack()->clean();lua_State *tolua_s = pEngine->getLuaStack()->getLuaState();lua_close(tolua_s);tolua_s = NULL;

That is to say, we need to delete the data in the stack first.

(3) Possible table Memory leakage in lua

Generally, you can directly "table = nil" to release the memory after the Garbage Collector recycles the memory (lua is similar to java). However, in some special cases, the garbage collector cannot accurately determine whether to clear the current object. In this way, many junk objects may not be released. This is cross-reference.

local table1 = {}local table2 = {}table2[1] = 1table1[table2[1]] = 1

In this case, table1 [table2 [1] will not be released before table2 [1] is released.

2. Optimization of Operation Efficiency
The optimization of running efficiency is more closely related to the game logic. There are different optimization points based on different logics. Here we also record the following principles:

(1) Reduce the number of elements drawn on the screen

Many screen painting elements are the main cause of low operating efficiency, cocos2d-x 3.0 enhanced the rendering efficiency optimization, added automatic cropping and automatic batch processing, however, we still need to take the initiative to reduce the way to draw elements on the screen. We also need to balance it with the large image or small image we mentioned before. In addition, we need to note that, sometimes there are too many elements to draw, because we forget to release useless screen painting elements, they may no longer be displayed (BLOCKED), but not deleted.

(2) lua automatic memory recovery

Collectgarbage is the interface for lua to automatically Recycle

collectgarbage("setpause", 100)collectgarbage("setstepmul", 5000）

Lua implements an incremental tag clearing collector. It uses two numbers to control the garbage collection cycle: garbage-collector pause and garbage-collector step multiplier. Garbage-collector pause controls how long the collector will wait before a new collection cycle begins. As the number increases, the collector becomes less active. A value smaller than 1 means that the collector does not wait at the beginning of the new cycle. When the value is 2, it means that the new cycle will be enabled when the total memory usage reaches twice the original number. Step multiplier controls the relative memory allocation speed of the collector. A larger number will make the collector more active and increase the size of each step. A value smaller than 1 slows down the operation of the collector, which may cause the collector to never end the current cycle. The default value is 2, which means the collector will run at twice the speed of the memory distributor.

If this parameter is set, you do not need to manually call this function to reclaim the memory. Manual calling will reduce the program efficiency.

(3) pagination of the scrolling list

Scrolling lists are frequently used in games, but some of them need attention. If there is too much data, paging is required. Otherwise, there will be too many list items in the list, the method used in tableview is to limit the number of cells and reuse previously used cells. However, you must clear the data in the original cell.

(4) print

Printing is very efficient. It is best to use variable control during packaging to block all printing.

(5) step-by-step Loading

Sometimes there are too many things to be processed on an interface. In this case, the page needs to be displayed step by step. First, a part is displayed, which will improve the effect.

This is what we can think of, and we will add it here. Welcome to discuss it.