Cocos2d-x performance optimization of those things

Author intro

Years ago in my project to do performance optimization, although in the development, performance issues are always concerned about, but this thing still need to do a period of time in the optimization, also encountered a lot of pits, here to share, also note as notes, but also welcome you have this aspect of the problem experience here to discuss.

Body

The main highlight of performance optimization is the optimization of memory and operational efficiency.

1. Optimization of memory

Said memory optimization, first of all to know what will occupy the memory of the program, can be optimized mainly two parts: data and resources, first of all, to say the data, do short-connected game client has two ways of processing data: One is a fool client, the other is a cache client, the Fool client can almost do 0 of data, Because it is only responsible for the display of each interface, of course, the interface needs to be the data will exist on the client, but his memory of the Occupy is negligible, and basic is not optimized, unless you have a memory leak. The other is that the client will be responsible for some logic, which not only has cached user data, but also configuration data (planned game data), the size of the data is sometimes even beyond your imagination (not much less than the figure); Besides, resources, mostly graphs and sounds, The optimization of these two resources can be used as long as the following principles are mastered (also applicable to data).

(1) Do not ignore the release of memory

In the J2ME era, because there is no common engine and framework, programmers to implement interface switching will often consciously do the release of useless resources, but in the era of intelligent machines, this "good habit" due to the system's "strong" is often overlooked ; I've seen more than one project. Programs that use cocos2d-x do not take into account the release of resources, because the system's automatic recycling mechanism, which even some of the online projects are not considered; what you need to know about this is that the system's memory recycling mechanism is like this, and he has a security "threshold", Note that this value will be less than the limit of the system, each time to the critical value of the system will help you clean up your non-leaking memory, but do not believe this way, although the threshold is less than the maximum value, assuming that the threshold is 180m, the maximum is 200m, if you enter a scene before the scene is 175, not to the threshold, But this interface loaded 30m of things, has not yet been recycled to work, memory has exceeded the maximum 200m limit, it will certainly crash, so it is a good habit to keep actively doing the removal of useless resources. This principle includes data and resources

(2) Random load vs Cache

Since you want to remove useless resources at any time, then we don't have any caches? It seems that these two ways is opposite, also some people will say, with the load is wasted efficiency, yes, if you want to deal with the performance of the program, these two ways really can not be opposite view, but to combine with; for picture resources, I do, Common images for each interface I will put in a picture puzzle (or a few), these images will be "resident" memory, this puzzle will include, commonly used buttons, backgrounds, small icons and so on, these pictures are cached, for other pictures, it is important to use this interface in addition to the common picture of the picture to play together, Thus, when entering this interface, only need to load these can, when leaving the interface, you need to delete them, these are loaded with the load, this principle is also used in the data, the commonly used data (load time will be longer) read into memory, other data with the load, attention to delete when not used, I've also seen some projects where the data is never clear, so they don't have the concept of maximum memory, and the memory will be like a snowball, and the bigger the roll, the more it's going to be, until all the data is in memory, and that's the same thing as reading all the data.

(3) Big picture vs small broken map? Memory limit

In fact, the size of the memory, the most can not be a surprise to solve is "big picture or small broken map", which involves the art and program of the cooperation, the responsibility of the program and so on, with the big picture, the process of the interface will be more convenient, but also improve the efficiency of the program, but the small picture will save memory, of This involves the memory limit problem, according to the current device, generally memory control to about 120 is more secure, it is more important to determine the actual memory limit can be executed.

In addition to these principles, you still have to cocos2d-x some "pits" about memory processing

(1) plist deleted, is your picture really deleted?

Ccspriteframecache in the Removespriteframesfromfile function in the plist name will delete the image of the data file, in particular, read into the plist file generated dictionary, it just lifted the image of the reference, However, to delete the specific picture, you need to call Cctexturecache's removeunusedtextures, notice that the previous function is called before calling this function will work, it should be noted that The use of CCB will help you call Removespriteframesfromfile, and the other Removespriteframesfromfile pass the plist name if it does not exist, there will be problems, The best way is to change the removespriteframesfromfile, do a fault tolerance, and preferably a previous frame called Removespriteframesfromfile, The next frame calls Removeunusedtextures and dumpcachedtextureinfo, so it works because the reference is deleted before the pictures they reference are deleted

(2) memory leaks in Lua

Sometimes in the game need to re-login, it is more commonly used to deal with Ccluaengine::d efaultengine () pointer to the part of the deletion, but this rude way may cause some memory leaks, need to add the following code:

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

This means that the data in the stack should be deleted first.

(3) Possible memory leaks from table in Lua

In general, the direct "table = nil", in the garbage collector's recycled memory (Lua this is similar to Java), can free up memory, but in some special cases, the GC is not accurate to determine whether the current object should be cleaned. This will most likely result in a lot of garbage objects not being released. This situation is cross-referencing

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

In this case before Table2[1] is released Table1[table2[1]] will not be released.

2. Optimization of operational efficiency

Operational efficiency optimization is more closely related to the game logic, according to different logic has different optimization points, here is also a few principles recorded:

(1) Reduce the elements drawn on the screen

Many of the elements on screen painting are the main reason for inefficient operation, the COCOS2D-X 3.0 version enhances the optimization of drawing efficiency, increases automatic cropping and automatic batching, but we still have to proactively reduce the way we draw elements on the screen, as well as the question of large or small graphs that have been mentioned before. This needs to be balanced, and it is also important to note that sometimes too many elements are drawn because we forget to release the useless screen drawing elements that they may no longer display (obscured), but are not deleted.

(2) Lua automatic memory recovery

CollectGarbage is the interface that LUA automatically recycles

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

Lua implements a collector for incremental tag cleanup. 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 waits before starting a new collection cycle. As the number increases, the collector's work is less active. A value less than 1 means that the collector no longer waits at the beginning of a new cycle. A value of 2 means that a new cycle is opened when the total amount of memory used is twice times the original. Step multiplier controls the speed of the collector's relative memory allocations. Larger numbers will cause the collector to work more aggressively at the same time, and also to increase the size of each step collected. A value less than 1 causes the collector to work very slowly, which may cause the collector to never end the current cycle. The default value is 2, which means that the collector will run at twice times the memory allocator.

As long as this is set, you do not need to manually call this function to reclaim memory, manual call will cause the program to reduce efficiency.

(3) Pagination Processing of scrolling list

Scrolling list is used in the game more frequently, but there are some need to note, if the data too much, need to use paging, otherwise list list items will be too much, affect the efficiency of the program, in addition, the method used in TableView is to limit the number of cells, you can reuse the previously used cell, Note, however, that the data in the original cell needs to be purged.

(4) Printing

Printing is a very cost-effective thing, it is best to use variable control when packaging, shielding all printing.

(5) Step loading

Sometimes an interface to deal with too many things, then this page display is required to process, first show part, the effect will be better.

This is what you can think of, and you'll find it in addition to this, and welcome to the discussion.

Source URL: http://blog.csdn.net/bill_man/article/details/43884095

Cocos2d-x performance optimization of those things