cocos2d-js做的，一个是网页h5的运行性能对比。另外一个是编译成apk包做的性能对比。说真的，性能这块的差距已经不是一点点大的。难道还要开发新功能而不去提升一下性能？？性能连别人一半都不到。在这我就不说另一个引擎是叫啥了，免得有宣传别人引擎的嫌疑，明白人一看就知道，这样的性能，如何让我们下个游戏再坚持使用cocos。话不多说，直接上图对比。PS：cocos用的是最新的3.15.1.。做为一个老牌的国内知名引擎，我由衷的希望cocos能改善下性能。让我们开发者对cocos更有信心！还有一点，cocos在帧数非常低的时候，fps会显示是60，导致截图难度很高。
16000个星星运行在中档android手机中。
h5网页对比
另一个引擎h5：
app对比。cocos的app渲染时间很短，但是运行起来很卡！！另一个引擎渲染时间长，但是流畅！
cocos apk截图：
另一个引擎apk截图
还有一点说明，因为cocos显示是60帧（实际非常卡，不可能60帧），导致h5和apk是在分别2台安卓机器上做的截图，希望cocos能关注一下性能问题！
为什么俩个的顶点不一样多？
需要问cocos大神，一样的代码做出来的，顶点不一样，也是他们的问题
6400那个感觉不对，一个Sprite最少也要4个顶点，16000个再怎么弄也不可能是几千个顶点。
会不会是那个引擎开启了脏矩形，或者在屏幕之外自动被剪切掉了。
你可以试试把星星集中画在屏幕中间试试。
当然屏幕外会剪切也是一个优化点：）
弱弱的问下，，另外一个引擎是啥引擎~
那个顶点，不是6400，是64000个，看看，有个0在外面
另一个引擎明显偷懒了。
好吧，64000是最正确的。96000这个就不合理了。
不知道该说啥了
我也想问下，另外一个引擎是啥··
引擎是啥我就不说了，cocos大神估计一看就知道了，我只是希望cocos大神要关注一下性能问题，毕竟游戏的流畅也是非常重要的一环，希望能学习下别的引擎的优点。
cocos现在app和h5在各方面没优势的话，牌子再大也没用。。
另一个很可能是白鹭引擎
cocos之前一只想搞一个大而全的引擎，什么都搞几下，瞎折腾，然后还各种内斗~~~
13年开始使用cocos，也算是第一代cocos引擎的使用者了，看着都替他们捉急。
其实没有你想的那么严重。我们用1.6版本在做重度的mmo，100个人的团战应该是可以支撑起来的。可以跑55帧左右
1.6确实有明显的提升的，等我们发布了，就能证明creator是可以做大型mmo的。
我知道引擎后面会有很大的计划，如果按他们的设想实现，这个引擎会牛逼的。
那是很多年前的事情了。后来的结果，以及现在的近况，你消息那么灵通，应该也是知道的 
谢谢楼主的测试，这个问题是这样的，你的用例跟实际游戏的适用场景差距很大，算是单纯的渲染测试吧，引擎中很多优化都是针对真实的游戏去做的，分两头说
1.Web
在 Web 平台上，你可以看到 Cocos 的 draw call 是 36，因为我们默认的全局 buffer 尺寸在你的这个用例下是完全不够的，所以分了 36 个批次才画完你的用例，这是 web 端比较卡的主要原因，我们用单个全局 buffer 是为了降低渲染过程中的重复绑定，同时为了降低 buffer 的内存占用，所以可容纳的顶点数比较低，但对于一般的游戏来说也绝对足够了，只是在这种极端的测试用例下会出现性能问题。这是为了游戏优化而不是为了测试优化。
另一方面，引擎中很多的优化，比如缓存渲染队列，在可能的情况下避免 visit，transform 的消耗，这也是对于游戏有实际意义的，不过我估计你的测试应该是星星都在动吧？这样的话有很多优化无法生效，但是优化本身带来的损耗就凸显了。
2.Native
在 native 平台我们的渲染的确没有做极限的优化，但是引擎底层的 C++ 逻辑是非常快的，但凡做一个相对真实的游戏案例，就能体会到引擎主要逻辑运行在 C++ 层的优势有多大，你的用例由于瓶颈都在渲染上，所以放大了问题。不过你可以看一下市面上的原生游戏，以及原生游戏的开发便利程度和稳定程度，一定是 Cocos 比另外的国产引擎领先，这点从游戏数量上就已经毫无疑问了，当然你也可以去问一些用了其他引擎做原生的厂商的看法。
接下来重要的是
说这些不是在避重就轻，只是说这样的测试对于真实游戏的可参考价值不大，如果各位要做新产品的技术预研的话，请一定要做得更加全面。
那么我们来说问题，Cocos 引擎的发展历程很长，且不说从 Cocos2d-iphone 到 Cocos2d-x 在引擎中留下的历史包袱（相信我还有很多），仅仅在 web 平台，Cocos2d-html5 是从 Cocos2d-x port 过来的，这是 2011 年的事情，当时由于 HTML5 技术的不成熟，团队经验不足，port 过程中并没有对 web 做更好的专门适配，所以很多性能问题，都是由于用了比较重的 native 框架来实现 web 引擎造成的。所以我们必须承认，在 Cocos 引擎中有不少历史包袱带来的性能问题，渲染的框架也比较陈旧。
我们也在思变，在 Cocos Creator 中，移除了大量引擎中不需要的模块，重构了很多 JS 层的实现，在 1.6 中又大大提升了 JSB 的执行效率。这点大家在周一的公众号中就可以看到测试结果，感谢 @colinsusie 提供他们游戏的测试数据，这是一个真实的 mmo rpg。但是依然有很重要的问题我们还没有解决，我也不避讳跟大家说，Cocos Creator 在搭建过程中，为了能够更快速和稳定地获得原生发布能力，我们其实是将 Entity Component 层搭建在了精简后的 Cocos2d-js 基础之上，在渲染树的基础上增加了 Entity Component 逻辑树，增加了很多事件驱动的更新机制，所以其实 Cocos Creator 的损耗比 Cocos2d-js 要高一些。这点劣势我们一直都很清楚，只是在 Creator 的工作流稳定之前，没办法抽身去解决，算是当年欠下的技术债。不过不用担心，从大概一年前我们就开始了 3d 路线的研究，这次的路线和方向都是经过深思熟虑的，我们优先搭建了很干净的底层 renderer，这个 renderer 的最重要目标就是高效。而我从今年上半年也开始研究重构 2d 的渲染层，将渲染树彻底去除，清除引擎中比较重的状态同步逻辑，使用高效的 3d renderer 来做底层的支撑，唯一的目标就是做出一个最精简高效的渲染层，Sprite 的测试结果在这个月初也出来了，新渲染器的性能比其他的国产引擎都好很多，是次世代的性能表现。剩下的工作还有很多，十月左右大家应该可以尝试这个版本的 web 引擎。
我的意思是，我们一直都很关注和重视性能，只是船大，需要的时间长一些。同时，我们不会简单得参考别人的实现，我们会参考最先进的渲染管线，用正确的方式提升性能，而且保障引擎底层的可扩展性，提升 2d 游戏的表现力，次世代的渲染管线的强大，只有用了才能体会，2d 游戏将不再只是简单的挪动贴图而已了，很多之前无法想象的特效都可以轻松实现。
以上大家看了可能觉得有吹牛的嫌疑，不过大家需要知道就是我们不会放着不管，也不是毫无方向和头绪，其他的，等我们做出来，自然就见分晓了。
牛逼 class 肺腑之言 。我从2012年 就开始用cocos2dx 到现在一直再用。虽然没有做过什么大型手游
感谢大神的回答！！我们拭目以待！！希望cocos越做越好！！
嗯…… 现状就是如此。而且在可见的将来，Cocos 在原生平台的领先程度只会越来越大
吊炸天啊
次世代的性能表现。。。
“十月左右大家应该可以尝试这个版本的 web 引擎”
只有web版本的么？
cocos2d-x会更新么，还是只是creator的
