目前确认的内存泄露问题已查明并修复,我们会放到 2.4.7 并重新测试,希望不会因为这个修复引入其它问题导致又延期,阿门……
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秒左右,会触发系统回收应用内存。这个时候去看的内存大小会比较真实
我测试单场景的时候压根没有这问题 只要你两个场景之间来回切 不管你有多少内存都会吃光
非常感谢。
Label Bitmap cache 的泄露问题已经修复
目前内存泄露最严重的是在场景切换的时候,而且场景自动释放时勾选上的。
把场景切换的接口屏蔽了 问题解决了
多场景的游戏···没法屏蔽···
看了不少论坛,当初决定用单场景框架
目前看还行
场景切换过程中大概率只是很多资源没有得到释放,并不是泄露,自动释放也只是一个粗略的比对和尝试释放,如果资源管理得不谨慎,大概率是释放不了的。
泄露指的是内存没有存在任何引用,但再也无法触发销毁机制,比如前面提到的 label 的 memory leak 指的就是 GPU 中的 Canvas 对应的显存没有被 CPU 端使用了,但是没有主动去释放,造成的泄露。
目前项目中遇到的大部分都是资源仍然被引用,需要更好的手动管理
目前我们的项目是从2.4.6升级上来的···之前也会有内存上的问题···但是很少,影响不大···目前升级到3.3.2后问题比较严重···基本上挂机两个小时,游戏就开始卡顿了···我怀疑这个可能和升级插件有关系···后续我们打算把所有界面都重新做一次···再看看效果···
我的项目影响很大,,,,要挂机超过10小时
3.x 内存使用是会比 2.x 更大一些,具体使用方面也会进行优化的。有一个点是,如果内存压力大,就一定要关闭 dynamicAtlas
为什么切换场景自动释放不了 但是单场景就没有问题呢
3.4 修复没有大佬们
该主题在最后一个回复创建后14天后自动关闭。不再允许新的回复。