Cocos Creator可以用来开发大型MMO吗？

本文主要是介绍Cocos Creator可以用来开发大型MMO吗？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

作为 Cocos Creator v1.6 中最大的升级点，Spidermonkey v52 版本给安卓版本游戏带来了重要的性能提升。那么这种提升是怎么做到的呢？不同平台有什么区别？稳定性方面会受到影响吗？未来原生还有什么优化计划呢？今天我们将为大家一一详细解答。

背景

熟悉 Cocos Creator 原生解决方案的同学一定知道我们特有的 JSB 绑定技术。我们通过将 JS API 桥接到 C++ 实现上来达成简单易用的 JS API + 高效的底层运行效率。这项技术依赖 Mozilla 的 Spidermonkey JS 引擎，由于历史原因，我们在 Cocos Creator 中使用的 Spidermonkey 引擎一直停留在 v33 这个较早的版本，而在 v1.6 中，我们将其升级到了 v52。不出意外地，由于 JS 引擎中 JIT（Just-In-Time Compiler）技术的飞速进步，我们在安卓平台上获得了巨大的性能提升，先看一下测试数据吧：

第一张图是纯 JS 代码执行的效率测试，使用了五种第三方测试代码得出的结果。可以看到纯 JS 的效率提升几乎达到了 20 倍，也不弱于同机型上任何最新浏览器的表现，说明 Spidermonkey v52 的 JS 执行效率真的比 v33 要高很多。

第二张图是渲染的压力测试，JS 的代码比重不大，也可以看到新版本引擎的性能有不小的提升。

真实游戏案例

上面两张图的测试都不能完全代表用户游戏中所能收获的提升，毕竟跟真实游戏的使用场景还是差别非常大，所以我厚着脸皮去找 Creator 的热心用户 Colin 要来了他们游戏的性能测试数据，Colin 正在用 Cocos Creator 开发一款原生平台上的大型MMO游戏。我们看下Colin的数据：

相信我，看到这样的对比数据，我们比用户还要更开心！看来过去三个月挠破了头升级 Spidermonkey 值了！

接下来还有一些场景的对比截图

稳定性提升

前面提到由于历史原因，在很长的一段时间内都没有升级过 Spidermonkey，这个历史原因就是由于 Spidermonkey 每个版本的 API 差异很大，每次升级不仅对引擎绑定层实现的改动很大，而且也导致用户及引擎合作方的绑定代码不得不跟着升级，总会遇到各种各样的问题。所以为了 Creator 能快速稳定地发展，我们才在很长一段时间内都没有升级 Spidermonkey。

那么有些开发者可能就会担心 v1.6 中的升级会不会带来框架的稳定性问题，这点完全不用担心。虽然这次 Spidermonkey v33 到 v52 的 API 改动确实非常大，但正是因为涉及到的绑定层代码很多，我们借此机会重新审核了整个绑定层的实现，在升级的同时，提升了稳定性。具体的改动除了适配绑定层代码到新的 v52 API 以外，还做了以下重构：

- 完全遵守 Spidermonkey 的内存管理规范，避免出现绑定层的 JS 对象被 GC 后继续使用的问题

- 开启 Generational GC 分片垃圾回收，不会出现之前版本中集中 GC 导致的卡顿

- 消除 JSCallbackWrapper，统一使用 JSFunctionWrapper 并加强其稳定性

- 优化 EventCustom, EventTouch, EventMouse 等事件的派发流程，使用纯 JS 事件对象以保障稳定性

- 对基础类型的转换函数加强了保护

- 解决关闭应用时的崩溃问题

- 解决重启过程中的内存泄漏和崩溃问题

实际上这次 Spidermonkey 的升级任务是从四月份 v1.4 发布后就开始了。前后历经近四个月时间的打磨，我们对目前 v1.6 绑定层的稳定性有十足的信心！

不同平台的区别

值得一提的是，近年来 JS 引擎的性能提升主要都集中在 JIT 技术上，可惜苹果平台禁止了第三方 JS 引擎中的 JIT 技术，所以 v1.6 在 iOS 平台上并没有获得显著的性能提升。其他三个平台：Android、Windows、Mac OS X 都可以享受到此次 Spidermonkey 升级带来的性能优化。

原生平台未来的升级计划

关心 iOS 平台的同学也不用太失望，在 v1.7 中，我们将会继续升级 Native 平台的绑定实现，带给大家真正意义的 JSB 2.0，届时会支持 Spidermonkey、v8、JavaScriptCore 三大 JS 引擎之间的无缝切换。这意味着开发者可以在 iOS 平台上使用 JavaScriptCore 和在 Android 平台上使用 v8，并且都能够在 v1.6 的基础上进一步获得 JS 引擎的性能提升。尤其是 iOS 平台，JavaScriptCore 作为苹果的亲儿子，内部支持 JIT，性能提升立竿见影。

前面提到的 Spidermonkey 升级带来巨大的引擎改动，牵一发而动全身，那么 v1.7 同时支持三大 JS 引擎，会不会未来升级更加困难呢？其实 v1.7 从根本上解决了这个问题，我们在 JS 引擎的上层抽象出了 JSB 2.0 API，所有的绑定层代码将按照这套 API 进行重构，而底层我们按照同样的 API 对不同的 JS 引擎进行了封装。未来 JS 引擎层面的 API 将对用户透明，不论怎么升级 JS 引擎，都不会再影响到用户的绑定层代码了，对于引擎的后续发展可以说是一大利好。