每个JS VM的优势不太一样，比如SpiderMonkey对native绑定的api调用速度就比jsc，v8块，而ios上jsc的js代码执行速度比SpiderMonkey快很多。
你确定是用了1.8.2版本？1.8.2是有修复 callfunc的问题的。这个有没有复现方法？
能否提供复现方式？目前静态分析很难定位到为题。
你用的版本也是1.8.2么？
我用的是1.8.2 不过我改动了不少代码。
算了，我自己分析吧，估计我改出来的问题。
复现问题太难了，工程太大。
恩，是182正式版的，这个在我这儿也不是必现，偶尔一两次联机调试的时候会发生，我也找不到一点头绪，但Android版确意外的稳定，唯一能确认的就是JSC环境的问题。主要是崩溃发生时，不知道运行了哪段js代码，如果能在引擎层面提供这些信息，我觉得调试就很方便了
不过现在发现，SpiderMonkey和JSC的性能，有时候还不一样，有时sm快，有时jsc快。不过整体上来看，jsc相对平稳，而spidermonkey在长时间运行后，会变慢，可能和GC的累积有关系。
是的，v8和jsc的gc性能是最好的，jsc的gc敏感度非常高，目前对引擎的绑定属于引擎接口的高级绑定，接口复杂度特别高，绑定代码哪里有一点考虑的不周全的地方就有可能在jsc上概率出现问题，而其他js引擎由于相对迟钝，特别是SpiderMonkey，所以比较难出现问题。这也解释了为什么1.6中没有出现的问题，在1.7以上版本ios比较容易概率的出现。这块后续会把绑定层级降低到渲染层面，最大可能降低复杂的绑定关系。
总体上说JSB2.0是个好东西
IOS切换到SpiderMonkey性能还是不行，并且偶尔也会崩溃。我的都是Iphone6Plus了。并且，感觉当前版本的SpiderMonkey的性能还不如Cocos2d-x3.13中的SpiderMonkey的性能。我以前基于Cocos2d-x3.13的性能还是可以的。
Cocos Creator 与 Cocos2d-x 3.13 JSB 比较不太合理，Cocos2d-x 3.x 里面的 JSB 基本上没有框架层的 JS 代码，都是绑定 c++ 接口到 JS 层，JS 层的逻辑很少，而 Creator 的 Engine 层 JS 代码比较重，而且涉及渲染节点与逻辑节点的同步开销，整体开销肯定是比 3.x JSB 更大的。
-x 3.13 用的是 SpiderMonkey v33， Creator 1.6.2 之后是升级到 SpiderMonkey v52，之前的测试与反馈都是 v52 的性能会比v33好很多的。
对比需要做横向的，比如你用 creator 1.5.2 SpiderMonkey 与 creator 1.8.2 SpiderMonkey 比较，如果1.8.2 性能差距非常大，那么我们可能需要细查了。
在即将发布的 Creator 2.0 中，我们重写了渲染底层，性能应该能够达到 creator 历史以来的最好的水平，到时候可以测试一下。
也欢迎提供测试例给我们，以便我们发布前做更多的性能对比测试。谢谢。
即将发布是什么时间？？？
你好，目前的版本我们自己改调整绑定层级在哪里改呢
十分期待，不过我最关心的是IOS上的JSC的问题能否解决，已经困扰我好久了，至今未找到突破口。
应该会根治一些疑难杂症。
这个无法修改的。
大佬，2.0什么时候发布？游戏等着上线，ios版问题还很多，特别是GC很卡，耗时很久，很难接受。
我也是，也等着上线，快发疯了，就是各种崩。
jsb_cocos2dx_manual.cpp:1529
这个行号对不上 v1.8.2 的版本嘞。
你是不是有自己改动引擎什么的？
有没有比较容易复现的 demo 提供一个？
可不可以查一下你游戏中如何使用 sequence + callFunc 的？