Summary of memory-related management after the project uses cocosBuilder, and the project cocosbuilder

Summary of memory-related management after the project uses cocosBuilder, and the project cocosbuilder
I checked the Project Memory leakage issues in recent days and found some problems that I did not expect before, mainly caused by cocosBuilder after reference.

First, let's talk about some basic memory management principles in cocos2dx.

1. When each CCObject object is created (eg: new CCObject (), its reference count is 1,
2. It is autorelisted (in most cases) and will be dropped by autorelease at the end of the frame.
3. The destructor of the CCNode object recursively calls the release of all its children and their children, corresponding to the retain () They are called at addChild ()

4. All objects that manually call retain () (for example, to keep a CCObject object, and it does not need to be added to the scenario) must display corresponding calls to release ()

Normally, as long as you pay attention to the above points, there will be no memory problems in the project, but some unexpected things will occur after cocosBuilder is referenced.
First CCB_MEMBERVARIABLEASSIGNER_GLUE (...).

#define CCB_MEMBERVARIABLEASSIGNER_GLUE(TARGET, MEMBERVARIABLENAME, MEMBERVARIABLETYPE, MEMBERVARIABLE) \    if (pTarget == TARGET && 0 == strcmp(pMemberVariableName, (MEMBERVARIABLENAME))) { \        MEMBERVARIABLETYPE pOldVar = MEMBERVARIABLE; \        MEMBERVARIABLE = dynamic_cast<MEMBERVARIABLETYPE>(pNode); \        CC_ASSERT(MEMBERVARIABLE); \        if (pOldVar != MEMBERVARIABLE) { \            CC_SAFE_RELEASE(pOldVar); \            MEMBERVARIABLE->retain(); \        } \        return true; \    }

When it is used to bind the ccb object to a logical object, this macro will execute the retain () to bind the object (). it does not have the corresponding release (). If you do not manually process it here, you will find a large number of objects in CCB. When the scenario is removed, it is not deconstruct.
Solution 1. In the mclass destructor of ccb resources, execute release () eg: CC_SAFE_RELEASE_NULL (m_object) for the objects to be bound ).

    LoginShow_CCB()    :CCLayer()        ,m_menu(0)        ,m_menuItem_exchangeUser(0)        ,m_menuItem_exchangeServer(0)        ,m_menuItem_enterGame(0)        ,m_menuItem_binding(0)        ,m_menuItem_reLogin(0)        ,m_labelUserEmail(0)        ,m_labelTip_email(0)        ,m_labelServerName(0)        ,m_labelTip_server(0)        ,m_labelBundleVersion(0){}virtual ~ LoginShow_CCB(){//CC_SAFE_RELEASE_NULL(m_menu);//CC_SAFE_RELEASE_NULL(m_menuItem_exchangeUser);//CC_SAFE_RELEASE_NULL(m_menuItem_exchangeServer);//CC_SAFE_RELEASE_NULL(m_menuItem_enterGame);//CC_SAFE_RELEASE_NULL(m_menuItem_binding);//CC_SAFE_RELEASE_NULL(m_menuItem_reLogin);//CC_SAFE_RELEASE_NULL(m_labelUserEmail);//CC_SAFE_RELEASE_NULL(m_labelTip_email);//CC_SAFE_RELEASE_NULL(m_labelServerName);//CC_SAFE_RELEASE_NULL(m_labelTip_server);//CC_SAFE_RELEASE_NULL(m_labelBundleVersion);}

It is applicable that all bound objects do not have a parent_child relationship. if so, it is in conflict with the 3rd mentioned above. some nodes will repeat release (), resulting in crash. leakage in C ++ and crash are only one step away


Solution 2: directly remove the MEMBERVARIABLE-> retain () in the macro. In this way, no problems are found.

Another point: CCBAnimationManager: setAnimationCompletedCallback
If you need to call back a custom method when a ccb action is completed, the above sentence will be used. Here there is also a pitfall,

void CCBAnimationManager::setAnimationCompletedCallback(CCObject *target, SEL_CallFunc callbackFunc) {    if (target)    {        target->retain();    }    if (mTarget)    {        mTarget->release();    }    mTarget = target;    mAnimationCompleteCallbackFunc = callbackFunc;}

This method will also give CustomClass to retain (). If you do not pay attention to it, there will be leakage.
Solution 1. in the custom callBackFunc method, call setAnimationCompletedCallback (NULL, NULL). In this way, you must remember to write this sentence for each callbackFunc (the last callback is useful, but you don't know which final tune, and all of them are the safest)
Solution 2. in customClass override onExit (), write this setAnimationCompletedCallback (NULL, NULL) in the method. Do not forget to write the onExit Method to the Parent class onExit eg: Parent: onExit. Otherwise, if Touch is registered, leak again


In addition, there are CCBReader objects that Mei found before. Due to problems with customClass and circular dependency, manually release them.


Regarding CCBAnimationManager, there are still other pitfalls (it may not matter). If you have time to study it again, Chun Ge asked me to summarize it for convenience.