Brief Introduction to cocos2d-x Memory Management

Cocos2dx memory management is transplanted from Objective-C, which is quite confusing for C ++ developers who have never touched OC. I cannot write a good C ++ program without a deep understanding of memory management. I have been using OC and cocos2dx for some time. Here I will summarize, I hope it will be helpful for anyone who wants to use cocos2dx to develop a game.
In C ++ dynamic memory management, we generally recommend that you follow the principle of who applies for release, that is, who creates an object through the new operator, and who is responsible for releasing the object through delete. If the lifecycle of an object is within a function, it is easy to do so. delete the object before the function returns. But generally, the lifecycle of the new object in the function will exceed the function body (for example, as the return value of the function). Otherwise, we can create an object directly on the stack, no need to use dynamic memory, but also saves the trouble of Memory Management (of course, large objects are not suitable for stack allocation ). If the lifecycle of an object exceeds the function of creating an object, it is difficult for us to follow the principle of who applies for release. We must release the object somewhere outside the function, if this object is referenced by multiple objects at the same time, the problem will be very complicated. It must be ensured that all references of this object no longer need it to be released, this is hard to guarantee in actual use. As a result, various Memory Management Technologies emerged: Garbage Collector, smart pointer, reference counting ...... cocos2dx is transplanted to Objective-C, so the original reference count method is used to manage memory like OC.
Cocos2dx implements memory management through CCObject and CCPoolManager. All classes that use the cocos2dx reference counting mechanism must be derived from CCObject. CCObject has a counter member variable m_uReference. When CCObject is constructed, m_uReference = 1, indicating that the object is referenced once. The retain method of CCObject can add 1 to the counter, and the release method can reduce the counter by 1. When the counter is reduced to 0, the release method destroys itself through delete this.
Manual Memory ManagementWith retain and release, we can manually manage the memory and release it with the new object.
[Cpp]

1. CCObject * obj = new CCObject ();...
2. Obj-> release ();

   CCObject *obj=new CCObject();... obj->release();

   Like newdelete, new elasticsearch must be paired to ensure that the memory is released. Does it make sense to replace delete with release? Note that this release is not equivalent to delete. release only indicates that the reference count is reduced by 1, and does not actually destroy the memory occupied by obj. The memory is destroyed only when the reference count of obj is 0. The following code shows the differences between release and delete:[Cpp]
   1. CCArray * array = CCArray: array (); CCObject * obj = new CCObject (); // m_uReference = 1
   2. Array-> addObject (obj); // The addObject method of CCArray automatically calls the retain method of obj to add 1 to the reference count, indicating that obj is owned, m_uReference = 2 obj-> release (); // The release and new pairs here. The obj references the Count minus 1, but the obj is not released. In this case, m_uReference = 1;
   3. Obj-> doSomething (); // after release, we can still use obj normally. It is not released array-> removeObject (obj ); // when obj is removed from CCArray, CCArray automatically calls the obj release. m_uReference = 0 and obj is destroyed.
   4. Obj-> doSomething (); // error. obj has been destroyed.

      CCArray * array = CCArray: array (); CCObject * obj = new CCObject (); // m_uReference = 1array-> addObject (obj ); // The addObject method of CCArray automatically calls the retain method of obj to add 1 to the reference count, indicating that obj is owned. m_uReference = 2obj-> release (); // The release and new pairs here. obj references the Count minus 1, but obj is not released. m_uReference = 1; obj-> doSomething (); // after release, we can still use obj normally. It is not released array-> removeObject (obj); // when we remove obj from CCArray, CCArray automatically calls the release of obj. m_uReference = 0 and obj is destroyed. obj-> doSomething (); // the object has been destroyed.

      For manual memory management, we need to follow the principles of pairing new/release, retain/release, who is new, who is release, who is retain, and who is release. If the new object is to be added to the cocos2dx collection, do not forget the release after it is added. The collection class has retained the object for you. You still need to pair the release for your new one time, otherwise, the object will not be correctly destroyed when it is removed from the set.
      Automatic Memory ManagementManual memory management seems to be more troublesome than new/delete, and it does not solve the problem that the lifecycle of the objects created in the function that we mentioned at the beginning exceeds the function. New and release need to be used in pairs, so we need to call release once before the objects created in the function are returned. If we didn't add the objects to any set before, the object is destroyed, which is the same as using new/delete. Automatic Memory Management can solve this problem. CCObject has an autorelease method. If an object is called after it is created with the new Keyword, we do not have to worry about its release. CCPoolManager Automatically releases the autorelease objects after each frame of the game ends. In fact, CCPoolManager still manages the object lifecycle through reference counting. There is a CCAutoreleasePool in it. We call the CCObject autorelease to add ourselves to the object array of CCAutoreleasePool. When each frame ends, CCPoolManager removes the object from the array. If the reference count of the object is 0, the object is released. If the autorelease object is called after being created with the new Keyword, you do not need to release it again.
      Most objects in cocos2dx can be created using the static factory method to automatically release the objects. This is a rule of cocos2dx. We recommend that you follow this rule for our own classes, to avoid misunderstanding by other developers. If an object is created through a static method of the class instead of a new one, we do not need to release it.
      In fact, the automation here is not as good as we think. for hosting languages like C # and Java, the virtual machine manages all the memory for you, programmers are completely freed from memory allocation and release. The autorelease of cocos2dx only Automatically releases an object after each frame ends. If you want to create an object in the next frame, we need to explicitly repeat this object or add the object to the Set (the Set will repeat once ). Now that we have retain, we can't forget to release it in a proper place. A common usage is to create an autorelease object as a class member variable. After we get the instance pointer through the static method, in addition to assigning the value to the class member, we need to retain it once, then, release once in the class destructor. If there is no retain, memory access errors will occur due to the destruction of the object when this member is used in the future. This is a trap that beginners can easily encounter.