用到了计时器、action
demo是根据我的游戏做的，目前游戏运行中内存持续上升，20分钟左右上升100M，画面严重不流畅
demo中：
方案1平均每10分钟内存上升10M
方案2平均每2分钟内存上升10M
做成对象池试试，你这样每次都cc.instantiate -> destory ->instantiate 很消耗，而且还加了action，都是消耗的地方
方案1是数组存储的，和对象池差不多
js内存回收不会那么及时，只要都清除了引用，一定时间后内存会降的，如果是一开始画面就不流畅，那与gc无关，如果运行久了不流畅，可能的
原因一，频繁gc导致卡顿，这种情况的卡顿会呈现间断性，比如5秒左右卡一下，能明显感觉是在gc。
原因二，对象根本没清除，不管是场景中还是内存池中的造成了大量的运算开销，个人觉得这种情况的可能性更大，会造成持续的不流畅。
再来看看撸主的代码，
如果要尽量避免内存波动，那么sequence callfunc function 甚至point都可以加入对象池。
从性能上讲，数组应尽量避免使用shift unshift，当数组越长的时候shift会越来越非常卡。
再有回调function内能直接访问this关键字我表示很神奇。
看了原生平台，你在 callFunc 回调函数的末尾添加手动 GC cc.sys.garbageCollect() 可以让两种方案的内存使用都稳定下来
1赞
感谢大神简答，这个方法在demo中确实有效，但在游戏中导致画面一开始就卡顿，
感谢大神简答，内存并非没有清楚及时，因为10分钟，20分钟，30分钟这几个时间段都是持续上涨的
采用panda的方法，频繁gc，确如所说，有节奏的卡顿
游戏前十分钟运行正常，但内存在持续上升，20分钟左右内存达到200左右，开始卡顿，
全部加入对象池，这…我再考虑考虑，
this是传入cc.callFunc的，所以能用
加入手动 GC 是为了证明内存没有泄漏，但是一定要控制 GC 的频度
非常感谢！我的是棋牌游戏，我改为在每局开始前（这个时间点没有动画效果）调用这个方法，非常完美，内存会有不同程度回落，已经控制住了。非常感谢！！！
这个方法也是治标不治本啊，5分钟后每次gc就不能将刚涨上去的内存清理出来了…
是我的代码写的有问题么？
你的引擎版本是？
刚这周升级的1.6.0，之前是1.4.2
刚这周升级的1.6.0，之前是1.4.2。gc确实效过很明显，但是并不是每次都可以完全清理干净，随着时间的推移，还会一点一点上涨
一点一点的上涨，按照我的经验，是正常的。上涨速度会慢下来，最终稳定在一个峰值，这个过程一般要比较久。
在 1.6.2 中我们会增强 GC 的敏感度，参考
这个修改可以自己添加，JSGC_MAX_MALLOC_BYTES 的值也可以自己调整
在 1.7 中，JSC 和 V8 引擎对于 GC 的表现都比 Spidermonkey 要好很多，基本不会有这种静置状态下的增长
好的，我研究一下
哎…我已经无能为力。修改后， 场景一开始效果明显，但是…四十分钟后内存上涨了70M。没有要稳定下来的意思