CCObject的分析：release retain基于2.2.3 增加3.2ref对比

结果：

After new: 1
After init: 1
After retain: 2
After release: 1
After autorelease: 1
“HelloCpp.exe”(Win32): 已加载“C:WINDOWSSysWOW64SogouTSF.ime”。无法查找或打开 PDB 文件。

 

如下：默认初始化reference为1，

 

 

看看autorelease的源码就知道实现了+1和-1的操作：

 

 

 

每个实现单例的类都应该提供清除操作：如下所示，以purge开头。

 

在2.2系列中，每个CCAutoreleasePool实际上就是一个CCArray，存储了一系列CCObject*，通过m_uAutoReleaseCount来计数。

 

回顾一下CCDiretor的初始化源码段：

 

通告层NotificationNode使用说明

 

下面有个NotificationNode，实际上和Scene属于UI种类，因为是后绘制，会遮盖当前scene，用途在于loading或者提示这种弹窗，记得触摸屏蔽的相关设置

原以为会是在drawscene内调用，谁知不是。这是个题外话，无关紧要的。

 

回归正题：

在经过CCDisplayLinkDirector继承CCDirector，在mainLoop中调用poolManager，这个才是真正的cocos程序循环，程序入口的是win32或者ios的主程序循环：

简化版：

 

 

 

 

实际上终于回到了我们要密切关注的CCObject内存回收机制了：

每次pop()都去调用当前CCAutoreleasePool的clear操作，因为原理在于Director将游戏世界切片为每一帧，并为每一帧设定绘制时间长度，当GPU和CPU在设备上完成上一帧的制作，会计算一个时间长度，长度不够时会占用当前帧的可用时长，当前帧绘制的必要时长于剩余帧时长时跳过当前帧的CPU执行和GPU绘制，这就是为什么掉帧和碰撞穿透的原因，而在clear操作中，代码如下：

 

将当前帧的数据清理掉，m_uAutoReleaseCount变成0，但是仍未真正释放内存。这时候内存管理机制就依靠m_uReference来辨别是否需要清理。所有只使用addChild而不retain的都会随着父节点被清理掉。一方面我们可以自己pushPool，另一方面可以使用挂载在m_pobScenesStack中当前scene下。poolManager并不管理m_pobScenesStack主线的节点，只管理掉落在当前pool中通过autorelease增加至pool的CCObject。

 

3.2 ref对比待续

ref 内部变化：变得清爽多了，除了增加了 CC_USE_MEM_LEAK_DETECTION 预编译模式下的内存跟踪：（这两个不是ref内部函数）

static void trackRef(Ref* ref);
static void untrackRef(Ref* ref);

外，减少了原先CCObject中的各种引用，只剩下：_referenceCount，无论lua还是js、c++，公用一个引用计数，C++分支真的往库或者大型3D多线程发展啦。只要坚持了过渡期，学好python、Linux的相关编译，手游纯3D的可行性很高。

下面才是新增的内存追踪显示函数：

 

新的AutoreleasePool已经使用：std::vector<Ref*> _managedObjectArray; 标准C++作为容器，通过ref.autorelease()调用的代码中不在进行+-1啦，

 

 

同时在mainLopp中变成了直接调用Autorelease的clear()操作：

 

 

 

3.2中

通过调用setNextScene();来在每次绘制之前增加scene的引用计数，这样子在drawscene之后调用clear就能清楚了无用的内存ref对象：

 

 

同时看一下Node::addChild的操作,能解决我们的疑惑，使用了addChild和Autorelease两种内存管理的区别：

 

 

这里要注意了，addChild中用到的vector不是std的vector，是CCVector，cocos2d重写的，

 

 

所以实际上我们看似使用AddChild交给cocos2d的渲染树帮助我们管理内存和启用AutoreleasePool形式管理内存是不相干，实际就相当于在以pool为载体的区域内建立了一批对象，根据需要去retian，或者挂载了渲染树上（每棵渲染树就是以scene为起点，addChild执行一次retian），每次渲染结束后都会清理一次内存池。所有在new之后，不调用Autorelease就要我们手动采取C++标准方式去管理内存；如果启用Autorelease的机制，因为调用Autorelease实在drawscene（cpu游戏主线和GPU渲染）之后，没有了之前存在可能申请了马上被清理的可能，所以不需要+-1，只需要在clear的时候判断是否为0。AddChild的区别在于挂载在渲染树上的节点_referenceCount初始为2，在执行一次clear之后就不在属于PoolManager的当中的AutoReleasePool，而是只属于渲染树啦。

 

渲染树的清理：

 

调用的是Node的cleanup，递归形式完成渲染树的清理。

 

提示： //利用静态函数实现每个pool创建自动添加至Manager，用的真妙！！C++只会越用越熟啊。

 

所以每次执行完clear，Manager中除了渲染树和_referenceCount>1都会被清理掉；可是pool被清理之后_referenceCount>=1的内存就如渲染树般泄露了，这个时候就需要我用自己release（delete）了。为什么会出现这样子的情况呢，实际上源于早前兼容ObjectC的代码继承过来的管理机制，可能之后Pool和Autorelease的机制会被清理调用，只保存渲染树和手动retian、release。这和之后启用C++11 shared_ptr<typename>有关。因为3.2的pool实际上可有可无啦，完全可以让程序去实现了内存管理。

 

至于ref继承了clone接口，这个人尽皆知，就不分析啦。可惜目前我仍然无法搭建git环境，我最怕搭建环境了，比如花了4天去配置cocos2dx 2.x 和quick的win安卓环境，后来放弃了之后发现3.x完全是方便至极。虚拟机mac环境早搞定了，只剩sdk下载。

下面是源码推荐的用法：

 

FROM: http://www.it165.net/pro/html/201410/23249.html