性能这样，能忍受，毕竟整个系统优化不是个小工程，关键是，经常这么，升个版本，然后web正常，原生一堆多出来的bug，感觉在web上开发完后，移植应付的态度放到原生上，然后也没在原生进行充分的测试。反正现在我每次升级个版本，想的是性能好点，实际是又多出个bug
问下通过什么接口设置透明度的？
具体的代码可以发一下。
2.x 切换到后台不会停止主循环, 只会暂停场景更新. 3.x 之前的版本会停止主循环, 导致无法在后台执行任何代码, 比如收集/发送统计数据.
事已至此，只能用事实说话了，原生一直是我们最重要的平台，也是研发投入力度最大的，没有之一。从去年开始到 3.3 我们完成了渲染器和渲染管线的完全原生化，包括支持多线程渲染器，这都是非常大的工作量，都在 3.3 交付了。
紧接着我们从今年七月份开始就在做更彻底的原生化工作，可以看下开发分支和目前 3.4 的差异
- Commits: 278
- Additions: 51132
- Deletions: 79330
以上说明的只是努力程度，但是毕竟还没有合并到主仓库，所以用户们感知不到，更彻底的原生化会在明年年中交付给开发者。
和 2.x 的原生对比，2.0 我们是 2018.8 发布的，接下来的原生化历程经历了一年多时间在 2.2.0 原生达成了一个新的里程碑。
引擎的迭代和架构升级都不是一蹴而就的，此次 3.x 的原生化面临的更是非常复杂的 3D 引擎原生化，所以确实还需要一些时间，以上都是为了说明我们在原生上的重视和投入程度，以及后续的规划。
-
为什么每次都要重构，从底层开始重新写起？
因为 2D 和 3D 差异巨大，如果我们故步自封，用 2.x 的架构来约束 3D 引擎的开发，那么 Creator 3.x 一定是一个四不像，无法承载未来 3-5 年的用户需求发展。 -
为什么原生更加不稳定？
这可能是一种认知偏差，聚焦在原生开发上的朋友会更多看到原生的问题，而聚焦在小游戏上的朋友们会更多看到小游戏的问题。引擎的工程和需求复杂度决定了它的边界无法约束，那么无法避免会有很多问题。当然，这不是推脱，发布测试版本也是为了和开发者一起解决你们遇到的问题，这也是测试用户能获取到的好处，就是可以更好保障自己项目在正式版上的体验。
另外，关于 Spine 等模块的问题，确实我们在模块投入上会有一些偏重，Spine 的原生体验之前投入不够，越来越多的反馈我们也看到了，会在接下来尽可能完善原生 Spine，@liqiao 也是团队内专门负责这块的同事。
总之，希望大家理解测试版的意义和我们在原生的进展速度，我们会尽全力不断提升原生平台的体验
12赞
该问题已修复
@property({ tooltip: "子弹物理分组" })
@type(Enum(PhysicsSystem2D.PhysicsGroup))
group = PhysicsSystem2D.PhysicsGroup.DEFAULT;
还没修复。。。。我自己提交PR但是修改方式是错的，会引起混乱，所以把PR关了。
这是我之前提交的修复。
麻烦告知下什么时候能修改？这个实在太重要了，我们从游戏立项到现在就一直没这个。。。
或者麻烦告知下要如何修改，我们先建立自己的内部版本。
1赞
提供一个修改方式，我测试是可以了
思路是直接使用 physicsSystem.PhysicsGroup 替换 physicsSystem2d.PhysicsGroup
在引擎层面，让这两个引用一个东西
那你必须得把3D模块给勾上才行啊。我们是2D项目。
看了下，因为这个 enum 动态取了 config 里的 collisionGroups，但是编辑器里没更新这个数据，所以一直都是 DEFAULT 一个，我们会在 3.4.1 正式版先将这个数据初始化到编辑器的环境里。
1赞
后面又看了下代码，只有 physicsSystem2d.PhysicsGroup 是单独定义的， 其他都都是引用的 physicsSystem.PhysicsGroup，我觉得这种东西就应该是一个才对
是的，但是其实分开也无所谓了。
感谢花时间回复这么多。
十分感谢，项目会第一时间切到3.4.1！
3.1升级上来 发现模型动画放不了
3.1 模型动画有4个 可以正常播放 3.4只能播放一个动画 其他都没用了
建议，引擎的2D物理引擎，在最终计算碰撞的时候，是不是应该只转换到UI坐标系，毕竟是2D的嘛 。而不应该转换到全局的世界坐标。毕竟2D下面，能够确实精确控制像素是非常重要并且真观的。
你的node是世界坐标，转UI坐标和node同步得多麻烦。
你为啥要用UI坐标呢？开发的时候一般情况下都应该以世界坐标为准。
