同一张精灵图片，放在场景中，没有任何处理，对比了一下1.9.2和2.0.2每帧的处理时间
这张是2.0.2
这张是1.9.2
对比后发下每帧渲染时间差了一倍
在到原生平台看看你就知道了，
官方只是说“渲染性能”，又不是说引擎整体性能，你没玩过文字游戏吧
渲染性能上升10 整体性能下降100
23333
,还是不能升级啊，用老版本了
终于被你发现了，为啥俺就不能早些发现勒。。目前2.0是小游戏专用引擎
先解释一下：
- 2.0 使用引擎渲染左下角 debug 信息，而 1.x 使用 dom 渲染 debug 信息，前者会计入引擎的时间，后者不会
- 2.0 的底层渲染器架构比 1.x 完整非常多，如果只是渲染极少数的 draw call 和节点，体现不出来优势，但是架构的提升带来的是各种真实游戏使用情况下的性能提升
我们的框架性能优化集中在几个方面
- 去除渲染树，不需要在两个节点树之间同步冗余的数据
- 优化渲染流程，无判断无分枝的渲染流程比 1.x 使用 dirty 机制，不停同步 dirty 的做法快很多
- 零垃圾设计，在引擎渲染过程中，几乎不产生任何垃圾，没有对象创建和销毁的开销，GC 友好
再说一下 native 的问题，2.0 的架构调整使得我们跨域了 Cocos2d-x 的传统架构，走向新的渲染架构，所以原生层没办法沿用之前的实现，目前是比较简单的原生层实现，很多逻辑在 JS 层。但是由于上述的框架进化，在大多数应用中 2.0 native 都是优于 1.x native 的性能的，但是我在其他帖子里面也提到过，如果重度使用 Spine / Dragonbones / Physics 这些计算量巨大的模块，会导致 2.0 的 JS 运算性能比 1.x 的 native 实现性能要低。并不是说我们放弃了原生，我们会在接下来的版本继续优化 2.0 native，将适合在 native 运行的模块迁移到 native 中。
性能评判是有各种条件和角度的，每次我都有提到这些，不希望再被断章取义。2.0 的最大意义在于给 Creator 后面两年的发展提供了很好的土壤和基础，如果我们抱着旧的框架不放，用户迟早也会抛弃我们，只希望在不断进化的过程中，大家可以更深入理解引擎发展的抉择和对开发者的影响，不要只看一些表面的东西。
最后，我们测试的数据是来自引擎各种使用纬度的测试场景，Web 平台，在各种场景下，2.0 的性能都优于 1.x，Web 和小游戏升级的开发者相信都可以感受得到。使用骨骼动画的 native 开发者也请耐心，我们会尽快优化 Spine / DB 等模块的性能
12赞
一直在使用ccc 2.0
加油
ヾ(◍°∇°◍)ﾉﾞ
感谢解答
加油 ，然后spine的shader有没有使用案例啊，都不知道怎么shader spine动画！！
没spine没骨骼动画之前那叫什么，超级玛丽是棋牌？
panda 大大 贴心的一匹 赞一个
你可以用手2.0.1版本写个超级玛丽demo看看在native是不是惨不忍睹。
刚把一个迁移到2.0.2，然后旧的还在，分别打包微信小游戏，放一个很破的手机上，前者30多帧，后者23+，刚好前者卡在流畅线上了，勉强能玩（手机真的很破，我2年前的米max都可以主要场景稳59）
前者是哪个？后者是哪个？
但是 Native各种渣啊，不是我喷 几年的cocos忠实用户，在Unity和cocos之前来回切换，只是想cocos愈来愈好，但是每一次都是让人失望到啊。。
想正儿八经做游戏就用unity，想搞棋牌（在我眼里这就是赌博的玩意）搞微信小游戏（在我眼里这根本不能算是游戏）就用creator。
哎,其实我想很多人跟我一样本着一套代码全平台制霸去做的,而且最核心的还是在原生平台 android/ios 但是不知道为什么原生平台跟web性能差距这么大.只是很普通的ui操作来着都没办法稳定60帧加载1-2个spine就各种卡顿