目前确认的内存泄露问题已查明并修复，我们会放到 2.4.7 并重新测试，希望不会因为这个修复引入其它问题导致又延期，阿门……
1赞
3.4的pr合并后，内存是有部分回收，比如100M 升到200M 之后回落150M,这样反复操作，内存一样会爆
打的是不是 release 版本？另外，可以用 Android Studio 自带的 Profiler 来测内存比较精准。
我们目前测过好几个项目，最大的影响仍然是 GC 的延迟性，包括 JS 的 GC 和 JAVA 的 GC，两者都会带来一定时间内的增长，但是内存是呈锯齿性的，在长的时间维度内是可以降低到稳定水平的。
在此前提交的 PR 实际上解决的不是泄露问题，因为那些内存都是被对象池持有的，我们的对象池策略是比较“懒”，在这个 PR 之前不会主动去缩减，因为我们估计一个项目的对象池峰值会不断被触达，所以尽量保持内存占用来避免对象创建。这个 PR 之后会在一定的时间进行检查和对象池缩减。所以严格来说 buffer 的使用上没有泄露，只是对象池策略可以优化。
除此之外，我们定位到一个 Label 使用 Bitmap cache mode 时的内存泄露，这个确实是泄露，因为一部分 GPU Texture 上传之后没有被释放，而 JS 的对象已经被销毁，确实是泄露，会在 3.4 修复
好的好的，期待3.4
Android 上 如果profile 上的gc按钮点击后会导致程序关闭，可以考虑通过将应用切后台10秒左右，会触发系统回收应用内存。这个时候去看的内存大小会比较真实
2赞
我测试单场景的时候压根没有这问题 只要你两个场景之间来回切 不管你有多少内存都会吃光
非常感谢。
Label Bitmap cache 的泄露问题已经修复
目前内存泄露最严重的是在场景切换的时候，而且场景自动释放时勾选上的。
把场景切换的接口屏蔽了 问题解决了
多场景的游戏···没法屏蔽···
看了不少论坛，当初决定用单场景框架
目前看还行
场景切换过程中大概率只是很多资源没有得到释放，并不是泄露，自动释放也只是一个粗略的比对和尝试释放，如果资源管理得不谨慎，大概率是释放不了的。
泄露指的是内存没有存在任何引用，但再也无法触发销毁机制，比如前面提到的 label 的 memory leak 指的就是 GPU 中的 Canvas 对应的显存没有被 CPU 端使用了，但是没有主动去释放，造成的泄露。
目前项目中遇到的大部分都是资源仍然被引用，需要更好的手动管理
目前我们的项目是从2.4.6升级上来的···之前也会有内存上的问题···但是很少，影响不大···目前升级到3.3.2后问题比较严重···基本上挂机两个小时，游戏就开始卡顿了···我怀疑这个可能和升级插件有关系···后续我们打算把所有界面都重新做一次···再看看效果···
我的项目影响很大，，，，要挂机超过10小时
3.x 内存使用是会比 2.x 更大一些，具体使用方面也会进行优化的。有一个点是，如果内存压力大，就一定要关闭 dynamicAtlas
为什么切换场景自动释放不了 但是单场景就没有问题呢
3.4 修复没有大佬们
该主题在最后一个回复创建后14天后自动关闭。不再允许新的回复。