【更新 030613】Cocos Creator v3.4.2 社区公测版本

是3.4.0吗

额,我回复的是前面那位兄台的哈

是。你也可以用3.4.2公测版本试一下?

好的 我测试一下

多占一点点内存是多么正常合理的一件事啊,多买一根内存条就啥问题都解决了

你要是我的客户就好了。。。多爽,。。8g内存算是标配吧?面向大众的产品,16g也不是人人都可以这样的,而且一旦是内存泄漏,16g沾光也是几个小时的事情,你对内存泄漏可能有偏见,其实这不是增加一条内存条就 能解决的事情,这个可是内存泄漏。。。如果重启程序能解决也就罢了,但是你要知道,这个是要重启 机子或者用360清理内存,,重启程序都无法解决的

我们需要查一下哪里内存占用太大。PS:360那个降内存有点假,可以看这个链接:Windows 内存释放软件的原理是什么? - 知乎

很多软件都内存吃的离谱,作为一个开发人员,自然不能把自己当作普通电脑用户了,8g不够的话就再加一根8g的,不就啥软件都宽松了么
才吃1点多G内存有个啥,chrome,ps,vs,pycharm这种软件,吃过8G也是常有的事情,去哪里说理去

其实我不用看其他链接的,你我自己就亲身经历,不用360清理内存的话,是很卡顿的,我不是用360看的内存占用,注意我是用系统自带的任务管理器看的内存,你可以问下今早远程我的兄弟,@ VisualSJ

可以尝试把这个prefab拖到场景,然后再拖回资源覆盖

1赞

额。。。你对内存泄漏有误解,你百度下程序内存泄漏的具体含义,即使我加到16g甚至32g,也仅仅是延迟重启机子的时间罢了。。。

哈,你说也是哈

疑问4:
如果项目的文件无权限访问的话,编辑器打开开发人员工具会出现这个无权限访问xx.log等等报错,但是编辑器不会有任何提示,同时运行后浏览器长时间黑屏,建议在读取文件时候检测下是否读取成功,如果没读取成功,还请直接将错误打印到编辑器去,让开发人员知道。

每个人都有自己的关注点,我只是希望它越来越好用,而不是当一条咸鱼,如果每个人都关注自己的点,然后再不同的点给官方测出bug,给他们建议,我相信年尾就能改出一个非常不错的版本了

做为一个曾经的Windows内核开发人员,我对重启程序都不能释放内存表示严重怀疑。这只能出现在两种情况: 一,是应用层触发了内核模块的内存泄露,二,是通过进程外COM或是别的什么ipc机制触发了别的进程内存泄露(所以重启当前进程无效)。

只要内存是程序自己分配的,没有可能os的内存管理器跟踪不到,导致进程退出都无法释放的。

要知道早期golang的runtime还比较渣的时候,一个有点偏门的最佳实践就是直接把os的内存管理器当成gc用,关闭runtime的gc从而解决stw延迟问题,就是一边跑业务一边泄露内存并监控程序的内存占比,直到达到某个阈值的时候退出进程让内存管理器一次性收回进程内存,再由另一个进程代替继续处理业务。百度的bfe早期就是这么干的

1赞

我这边也是后端的,所以是比较在意内存的问题,至于什么原因,我也不知道,但是 可以肯定的是,要么重启机子,要么就用360等等清除内存的软件进行清理,这会我都没眼看了,

只能开下360了

有没有尝试把360卸载干净再试试呢

360只是暂时把内存交换到磁盘了,编辑器用一阵子内存该用多少还是会回去的。


差不多2小时了 ,并没弹回去