Creator1.7剧透:性能提升有点超出期望了

同求 确实如此 期待自动缓存data功能

明白了,谢谢

第一次加载慢 本身不是个问题 只是比市面上的其他引擎慢很多

虽然很感谢你们对引擎的不断提升,不过就这个结论而言我不赞同的。至少在我的测试当中,没有发现多次加载会比1.6。1.5快的。在上面的测试中,我对一个界面至少尝试打开了10次以后,并没有快。如果要打开几十次以上才能快,那其实这个快就没有什么意义了。

我说上面这些的期望,是希望官方在下某些结论的时候,可以先验证一下,Demo什么的都提供了,如果验证下来确实是不快反而慢了,那么是否应该重视起来,去真正研究一下为什么会慢呢。

我前面说的动态生成方法的性能影响…… 指的是反序列化部分。
我看了一下你的数据,第二次确实变快了 10% 几,但是仍然和 1.6 有差距。那说明主要不是反序列化引起的,应该是 Prefab 实例化的性能没有提升。
这个估计是你 release 了 Prefab 引起的。
你如果单独测试重复 load 再 release(不 instantiate)
或者重复 instantiate (不 release),应该从第二次开始,1.7 的性能都会超越 1.6。

我加载Prefab的代码是这样的:

onClickPrefab: function() {
	var tick = Date.now();
	cc.loader.loadRes("Panel", cc.Prefab, function (err, prefab){
		var node = cc.instantiate(prefab);
		var panel  = node.getComponent("Panel");
		panel.init();
		node.parent = this.node;
		var log = "time = " + (Date.now() - tick)
		this.lbInfo.string = log;
	}.bind(this));
},

prefab关闭的时候,也没有release的,关闭prefab的代码是下面这么简单的:

close: function() {
	this.node.destroy();
},

在打开prefab的UI脚本的onLoad中,会去instantiate其他的子prefab:

init: function() {
	var x = -150;
	var y = 240;
	var sz = 100;
	for (var r = 0; r < 6; ++r) {
		for (var c = 0; c < 4; c++) {
			var node = cc.instantiate(this.pbItemBox);
			node.setPosition(x + c * sz, y - r * sz);
			node.parent = this.pnItem;
			var label = node.getChildByName("spCount").getComponent(cc.Label);
			label.string = "" + r*6+c;
		}
	}

	// init rank item
	for (var i = 0; i < 30; i++) {
		var node = cc.instantiate(this.pbRankItem);
		node.parent = this.svRank.content;
	}

	// init boss item
	x = 0;
	y = 240;
	for (var i = 0; i < 30; i++) {
		var node = cc.instantiate(this.pbBossItem);
		node.parent = this.svBoss.content;
		node.setPosition(x, y - i*node.height);
		var label = node.getChildByName("lbName").getComponent(cc.Label);
		label.string = '超级大BOSS'+i;
	}
},

此次的结果比1.6慢一点点,多次打开的结果也是这样的。

Prefab 的加载并渲染,本身要做的优化比其它引擎单纯的皮肤要复杂的多。虽然第一次慢了,但是重复 instantiate,性能会其它引擎快。如果你把 Prefab 用于大型场景的动态生成,或者 UI 元素的多次填充,性能优势就能显现出来。如果只是单个界面的一次性加载,确实慢,这个后续已经想好怎么优化了。

如果是没有 release 过的话,那都就避开了 js 层的性能陷阱了。应该性能问题是出在 C++ 层了。这个需要 @dumganhar 进一步确认了,很有可能是新 VM 的 JS 绑定层开销有所增大导致的,可能优化的空间不大。
呼叫 @dumganhar

我们的游戏,很多人反应发热和耗电严重,这个一般是什么原因了?有什么解决方案?

最好实时切换帧率,能降到 30 就 30

CPU运算过高,降帧,再优化一下update的代码,减少计算量。减少动画

我用cocos多少年了,一直是60帧,你现在让我自降逼格用30帧,那么问题来了,设置帧频的代码是什么,可以在游戏的过程中动态的修改吗?

做程序心平气和最重要

原来在这里,我在cc.director里找了好几遍,试了下,发现设置15帧貌似也能接受,自甘堕落了

你用cocos那么多年连这个都要问。牛

淡定淡定,我会用@colinsusie同学的demo验证的。有结果会同步在这里。