记录一下Cocos2dX中内存管理的理解和试验

记录一下Cocos2dX中内存管理的理解和试验 一直弄C的，还经常到底层晃荡滴，十分不习惯内存这么宝贵的资源不受自己控制的编程，就像大热天坐在电脑前打游戏，边上千把只蚊子飞来飞去一样难受。尤其是那个autorelease，大把的兄弟们分析了它的排队和删除机制了

记录一下Cocos2dX中内存管理的理解和试验

一直弄C++的，还经常到底层晃荡滴，十分不习惯内存这么宝贵的资源不受自己控制的编程，就像大热天坐在电脑前打游戏，边上千把只蚊子飞来飞去一样难受。尤其是那个autorelease，大把的兄弟们分析了它的排队和删除机制了，但私心里总想，自己造出来的东西，为毛不能我想让它滚蛋就滚蛋，总在内存里挂着作甚。虽然autorelease这种机制确实有它的优点，但也没必要到处都用吧……，手机内存现在也不便宜啊。

一、我们的目标

C++的方式一般是new、delete成对用，我们的目标也就是这个，告别静态方法，告别 CREATE_FUNC宏，告别autorelease retain release，重要的是，autorelease的队列中不要加入我们不想加入的东西。

二、一点点摘吧出来

首先装模作样的管理一下内存，一般来说，Cocos2dx如此打包的原因估计就是想让内存管理更加简单，于是推着大伙使用静态create方法，在这个方法中，实际使用new实例了对象，并且随后调用autorelease将其排队了。通常我们不用retain和release，因为一般大伙儿把这货造出来都是为了addchild的，在addchild里面实际做了一次retain，然后在使用结束的某个地方removechild的时候（没去找，可能是析构，又release了一下）。我们在这里试图让autorelease失去作用，于是构造时retain一下，析构时release一下，基本做到我想放的时候放，当然不一定掉了）

其次是避免使用静态create方法。

这里稍有些不严谨，本来应该构造和析构对应，但显然层对象在App构造的时候构造会@#￥#%@，没有去研究为什么，所以在applicationDidFinishLaunching构造吧，在析构函数中放掉。

GameScene是继承Layer的类，实际就写了上面代码中那三个函数，就创建了一个Sprite贴进去而已。其中Scene的创建被我们拿到了AppDelegate中，没有集成到GameScene（虽然还叫这个名字），仍然用autorelease管理（使用静态方法创建）。我们主要看GameScene，可以发现，我们使用new实例化对象m_pMainLayer（类成员），直接调用了对象的构造函数，跟一下，实际就是调用了Layer::Layer()，申请了内存，但是没有autorelease，没有init。

那么，显然现在我们要管理如何放掉它了。如某些同学的说法，可以讲new和release对起来用，一开始我就是这么用的（注释中的内容），但实际情况是，直接用delete好了。现在看起来很像C++了吧，哈哈。

三、Sprite为什么没有用new、delete？

可能有兄弟已经注意到，Sprite，这个最需要我们精细管理的对象这里并没有使用new、delete。确实，一开始我想用来着，先new一个Sprite，然后用initWithFile载入图片，就像静态方法Create一样。但是编译器不干，为什么呢？

看看CCSprite的源码就知道了，CC_CONSTRUCTOR_ACCESS其实就是protect换张皮，换句话说，cocos2dx将new、delete保护起来了，不让用，必须autorelease。可以想见，Layer必然也是，那上面的Layer为什么可以？对了，只要继承一下就行了，此时内存完全由我掌控。

四、是不是有点作？

可能真是有点作吧，俗话说no zuo no die，可能有一天碰上莫名其妙的问题就是如此作出来的，所以立文为证，提醒自己一下。毕竟还是用惯了new、delete和自己亲力亲为的管理，强迫症使然，一个不用自己管的内存扔在那里总觉得这玩意指定泄露了。决定以后如此new、delete的来了，会不会有虾米问题？有木有高手指点一下？

五、现实报来得快

这两天搬家整房子，手头停了一段。今天捡起来按照前面“作”的内容完整的写下来才发现，原来还不仅仅是new delete受protect限制的问题，还有函数initWithFile，没办法，继承类里面加个公开函数包一下吧，这样外面就可以调用了。如何，下面这个是不是看起来舒服多了？如果还觉得不爽，重载个构造函数吧init替了吧，不过这样就只能ASSERT initWithFile返回True了。

哈哈，首先解决个人习惯问题，后面爬起代码来才会爽。