性能和包体是 Creator 发展的根基，等我们收拾完 3.0，就会持续跟进下去，请大家放心。
1赞
是的呀，跟编辑器有锤子关系呢，，，
一部分原因是计算迁移道理js，导致native频繁交换，然后ios不能jit，性能降低了几个档次
跟渲染没啥关系
小白吃瓜…
所以大佬3.0大概什么时候会出来呀
h5的底层也是对2dx的封装么？
不就是处理渲染的逻辑么。。最理想的情况就是h5是h5 native是js接口绑C++ 逻辑至少应该大部分在C++ 然后再去保证两端之间的表现一致，这样才是最完美的。至少性能和2dx lua版本平起平坐，但是目前来看 维护成本太高，官方也不会有这个打算。
还有即使android 能jit转为字节码，消耗也很大，它只是提升了js 的运算能力，并没有减少js和native之间的频繁交互。这是硬伤，解决问题的根本是减少传递数据带来的消耗。
还有就是如果原生也能将工程文件导出为flatbuffer 这样在初始化加载 速度应该也会快很多吧，大概意思就是发布工程的时候可以给个选项，是否将工程文件导出为flatbuffer,供开发者可以选择。这点我觉得可以向cocos studio 借鉴一下。
所以creatorH5版本的底层还是拖着个2dx么？ 我以为是直接上的js + webgl,
说实话，我个人觉得，引擎非但不应该去做合并工作，而是彻底分开3d项目，更方便开发者阵地游戏定位来选择引擎，强行合并必然带来一堆的api调整，也容易引发性能上的额外浪费。
这个时候，我就来说句公道话了，不是cocos渲染不行，是update跑的逻辑太多了，就如jare大佬之前说过的，渲染肯定是没问题的，就是实现的方式有问题
这张图，就是单纯的把2000个精灵放在一个父节点下，每帧对父节点进行遍历改变坐标模拟楼主的精灵运动。其中开销大头都是渲染，直接看出没有啥操作能抢到渲染所需要的运行内存
这一张就是楼主采用
node.runAction(cc.repeatForever(cc.sequence(cc.moveBy(Math.random() * 10, cc.v2(toX, toY)), cc.moveBy(Math.random() * 10, cc.v2(-toX, -toY)))))
方式移动的，可以看出update直接把render干翻了，所以当然会卡啊。
顺便再放两张性能开销图
从触发自动gc的频率就知道，上面那个操作有多吃内存。
总结就是动画系统拖累了cocos的渲染
3赞
你觉得个人感觉能和unity已经走过的路相比？那如果我想要在3d中用一些2d才有的功能呢，那如果我想在2d中加一些3d展示呢？
如果人力充足，肯定的。但是目前我们遇到的现实问题是，两个产品自己跟自己抢人力，也自己跟自己抢用户。
说句公道话
我非常喜欢CocosCreator
我学过一段时间Cocos2dx，好难，入门好难，建个项目好难
我在学校的时候，用CocosCreator做了一款休闲游戏上线了，虽然，没赚到钱，但真的好简单
我在实习时用过Cocos2dx-lua 工具链，studio都很难用
现在工作了，用Laya开发，很多时候，尝尝发愁。
问问题，社区的一些问题都是老早的了，也少有回复的。
要做一些特殊渲染效果，没得自定义
编译发布什么的，可能需要自己去实现更好的工具。
想做个插件扩展 什么的，没有。
其实Laya应该也有人手不够，资金不够的问题，去年说的编辑器，或者无代码编辑器这些大饼一个都没实现
UI库也是老旧的了。没去更新。
组件化嘛，实现了个蹩脚的不智能的组件化。
最后还不如用fairygui香。
发布native呢，一些特殊的渲染和定制问题，还木得源码看。没法修复和定制呢。调试也是木得（native层调试）
当然如果有自己的一套成熟体系，比如一些大公司项目组之类的。当然自己的用起来方便啦。
这是一个技术选型问题。作为一个主程（项目开发者），肯定会去评估测试，做取舍的。
比如我
在公司，因为前老大就是用Laya做的项目，虽然走了，但其他小弟都只会laya，以及前项目在Laya3d方面有所积累，虽然我会CocosCreator，但当时C3d还没出来，所以只能用Laya3d继续开发项目。
后来转岗了，转到的那个项目组，只做了战斗，UI还没铺开。这个时候C3d也相对成熟，但我还是没用。考虑的是这个项目组的主程没用过Cocos，对Laya熟。所以我做的选型是，Laya+fairygui。也架构了基于此的框架。以及写了基于webpack的快速编译工具，fairygui的配套工具，达到快速开发的目的。
在业余时间，或者自我成长、技术积累。我选择了CocosCreator
为什么？？
比较Open
做起效果很方便
论坛的氛围舒服
套用那句话
这里的人又好看
这里的人说话又好听
我超喜欢这里的。
11赞
就是，会说话就多说点 ccc的论坛环境是国内最好的。
c++ 和js的交换影响了效率，渲染能影响啥效率啊，gpu计算，影响的cpu
说那么多，其实就是任务多，人不够
还不快去加入引擎组
吐槽的时候也不见得自己贡献了什么
测了下 把runAction注释了 好了点 但还是低 还是有问题吧