楼上 @2627993092 说的就是主因，目前的框架调整原因让我们使用了 JS 层的 Spine，在动画 simulation 过程中，JS 运算损耗的确很大，我们未来会通过 wasm 或者在框架上支持原生 Spine 的方式来优化。目前对于重 UI 的游戏，2.0 仍然是有大幅度的性能提升的，但是使用 Spine, DB，物理 这类重度计算的模块，性能是会下降
2赞
2.0之后native的性能是不是基本等同于h5的性能? native基本上就只剩下渲染部分了
1赞
这个可以系统的对比一下。我觉得 native 会胜出，h5 是完全的浏览器环境，native 对于 creator 的 js 脚本是提供了一个最小的 JS 运行环境。结构上类似于 Node.js 基于 v8 营造了一个服务器 JS 环境。
一共才这么点数量的spine，帧数怎么会这么低。而且不管浏览器还是native，如果都是js实现的spine库，那么应该没什么区别的，估计还是哪个地方写出问题了。
就算没有这么多spine,iPhone低电量模式下.掉帧就很严重.
我之前也提过这个问题,我以为引擎组会把它做为重点来处理.
都这么久了,也不优化,也从来不提…
总结就是2.0的native就是一坨屎就对了!!!
大大，现在原因确定了，那什么时候会优化这块？？？？？
两位大大， 那优化这块，预计什么时候开始呢？
现在已经上马2.0了，下不了的阿，也用了大量的spine动画，（为什么选择spine，也是因为ccc自带的动画完全满足不了）
这可怎么办是好阿。
原始平台spine问题太多，多到没办法修复了吗？
直接一刀切，统一使用js实现了，如果统一运行库为了提高维护，还能确保性能，那是应该的，但现在的性能已经完全无法支撑开发一个简单的动作类项目了。
我觉得逻辑运算消耗比较高的就应该要用native实现而不是用js，不然creator就根本没办法做native平台的大制作产品。
浏览器和android使用的都是同一个运行库，但性能相差甚远，pc浏览器的性能没什么好说的，android oppo R11的spine表现性能却比iPhone6s iPhone7、8 强，所以我相信一定是ios平台下哪些地方处理的有问题，导致性能差。
希望多关注spine性能，如果说只能做到现在的性能，项目直接完完了。
原本1.10.1的版本下的spine对我来说就只剩下一个bug：ios运行spine动画会偶然性崩溃。2.0.1不崩溃了，但性能差了，无法接受啊
总体上native的性能是变差了的，大多数用户的感受，经过项目两个版本的比较也确实是差了，望注重native性能。
mark 我们也在用spine
现在这种性能会直接导致项目无法完成。未来会通过 wasm 或者在框架上支持原生 Spine 的方式来优化，未来这个时间节点麻烦评估一下实际时间，不然很多人的项目会被影响到弃坑。
1.10.1 的版本问题没有很多啊，但有一个很致命的问题：ios下，运行spine动画会偶然性出现崩溃。
你们敢这么做就说明你们是清楚性能会下降的，现在导致的问题是2.0版本无法满足项目需求，不敢奢求你们快速找出方案提升2.0的Spine性能，退一步，麻烦把1.10.1版本在ios系统下运行spine动画会导致偶然性崩溃的问题修复一下。
崩溃的堆栈是什么，是否有可重现问题的 demo
我的角色全是用spine实现的，一个画面估计最大有200个，这样我不能升2.0了…
崩溃的问题我可以重现然后重新发个帖子。
但2.0.1的ios的spine性能问题也请快点解决下，项目在2.0的版本beta至正式版已经开发有段时间了，迫不得已回退1.10.1还挺麻烦的。
我也发现现在的原生引擎，基本上C++层面就只实现了一个渲染引擎和平台接口的封装，很多逻辑都是在脚本层上实现的，这会不会有问题？
在IOS上我觉得这可能是一个性能问题，特别涉及到密集型运算。
看来回头下 1.10.1还是很有必要的哟。。。
不敢苟同。至少spine，90%的游戏都是重度使用，这个是个非常严重的问题啊。
如果 采用wasm优化，能在下个版本搞出来，或者不超过2个月，我们大家都还可以等等。
否则，真的只能又折腾退回到1.10.1版本去了。
1赞