游戏中有频繁创建金币掉落并收集的动画,使用了对象池,最多创建12个金币node,每次都让它runAction播放动画。但是在微信游戏里测试除了略微卡顿外,金币收集了一定数量(也就是说播放了一定数量的action之后)会卡住闪退。这是频繁创建action导致的吗
应该不是。
会不会和创建了很多计时器有关?我通过schedule创建计时器,执行了指定逻辑之后销毁计时器,立刻又重新创建了计时器,运行之后微信里是直接一直涨内存,然后卡住不动了
不管创建的啥,都要确定是否真的销毁
你真的有必要这样设计么
兄弟这不是设计不设计。需求摆在那里。而且逻辑是没问题的。我已经找到内存飙升的原因了。富文本组件是罪魁祸首。
销毁了。我找到了原因,是频繁设置 RichText 的string导致内存泄漏。这个估计是引擎bug?
内存泄漏,可以给的demo吗?
你用的是那个版本的Cocos creator啊?
应该是和设置比较长字符串的富文本控件会卡顿一小段时间一个道理
创建文本:
var text = new cc.Node();
this.label = text.addComponent(cc.RichText);
更新文本:
this.label.string = "<b>"+this.earnNumber+"</b>";
当更新频繁的时候,发现微信里内存是只涨不降,最后会卡住动不了然后闪退,把更新文本的代码注释掉就不会了。所以我换成了
this.label = text.addComponent(cc.Label);
那问题就只能是cc.RichText了
运行在哪个平台的?我验证一下。
微信小游戏里
看到这里吓死我了,赶快掏出手机测试验证一下。
验证的结果就是:建议楼主仔细检查一下自己的代码,是否在其他业务逻辑的地方存在内存泄漏的情况。
富文本更新频繁时不存在内存泄漏
测试手机:小米6
Creator版本:2.0.2
微信调试基础库:2.3.0
微信版本:6.7.3
使用微信的真机调试
一开始我弄了一个富文本Text,然后写了个脚本在Update当中更换string,从今早9点半多一点,跑到11点,没有出现所描述的卡住,闪退。用heap snapshot看了一下内存,没有什么泄露的迹象。
抱着严谨的态度,我又创建了15个富文本Text,想加剧一下问题出现的速度,同样用微信真机调试,再使用heap snapshot去抓下内存看一下。从11点多跑到现在,差不多半个小时多一点。

这就是测试验证的界面。
运行第1分钟:

运行3分钟左右:

运行8分钟左右:

运行30分钟左右

后来我有考虑一下,30分钟是System Objects 是1272,刚开始是1243,多出来的这29k是啥东西,要是泄露了可不好,比对一下heap snapshot,发现一部分是微信的logmanager,一部分是render。重点看下render是什么,看完以后发现大意了,妈蛋,我的富文本从个位数运行到7位数,需要render的object自然多了…………
根据验证,目前来讲没有发现富文本在更新频繁时有内存泄漏的情况。
下面是测试代码,超级简单:
cc.Class({
extends: cc.Component,
properties: {
mIndex : 0,
mLabel : [cc.RichText]
},
update (dt) {
for (let index = 0; index < this.mLabel.length; index++) {
const element = this.mLabel[index];
var str = "<b>Text" + index + ":</b><color=#00ff00>" + this.mIndex + "</c>";
element.string = str;
this.mIndex++;
}
},
});
非常感谢你的细心测试,如果是我的疏忽那真是不好意思。不过我确实遇到的情况是富文本更新,因为我排查了半天,注释来注释去都没有定位到问题,内存一直飙升,直到我把富文本更新的代码注释掉之后,内存奇迹般地稳住了。所以我只能把问题抛向富文本。
或许是我这边的综合因素导致的,我这边的条件如下:
手机:华为p10Plus
creator版本:1.9.1
更新操作为超大数值(例如:10000000000000000000000000000、经过一个封装的函数转化为以k、M、T、G…等为单位的短字符串)。:this.label.string = "<b>" + utils.money2String(this.earning ) + "</b>";//earning为一个比较巨大的数值,money2String将数值进行改为以k,m,t,g等为单位的数值
可以排除 utils.money2String这个方法,因为我后面改成cc.Label后用同样的方法更新也没有出现问题了。
如果是我的疏忽,那十分抱歉并感谢大家的细心回复。
用开发者工具调试一下,看下是哪个地方的运行占用最高
你可以先给富文本赋值一些简单数据,对比看看,还可以把"" + utils.money2String(this.earning ) + ""这个串先赋值给一个变量打印出来,再赋值给this.label.string对比看看。
如果有空,麻烦给一个demo吧。不然环境不一致,很多时候真正的问题点就没办法找到。