3.3.2的GFX Texture mem显示不知道是不是正确
此方法获取到的大小明显大于调试信息，但我不关心这个，只是偶尔测试到了
在3.3.2 WEB运行上面demo的时候会发现GFX Texture mem 增长缓慢
此方法获取到的大小明显大于调试信息，但我不关心这个，只是偶尔测试到了
web加载更慢
renderer优化劳烦给指个方向
这个我最近有做过一些尝试，可以调试看看渲染管线有没有对自己无效的过程然后自己定制渲染管线取消这些无效操作！
看你是2d项目应该很多3d渲染流程对你无用。可以去掉
3.x原生性能官方不是说提升很大嘛
你说的预加载功能是通过 resources.load 提前加载资源来实现的是吧？
嗯，preload方法也一样慢。
我不大关心web的表现
35ms的渲染时间优化起来心里没底，相同代码2.4.6 是13ms
按你说的方式测试了下，web 上预览确实慢了不少，不过构建后是正常的，3.x 构建后还要快一些。预览慢的问题，我们之后再优化下，问题的原因是 3.x 的资源结构和 2.x 不一样，多了 image asset 这一层，请求的数量多了很多，在 3.3 我们新增了 ccon 格式，这个也会导致预览时请求数量大量增加，两个原因导致预览慢很多。这个后续我们会优化掉
不关心web表现，请问原生的性能问题哪个版本优化掉
性能的问题我们有同学在看
render time这个我也头疼。目前iOS我游戏render time也是30ms头疼。
能不能让我和优化性能的同学对接下，我发个加密的build包让他找一下renderer ms这么高的原因
何止头疼，我这都影响睡眠了
帧数设置为5的话，renderer ms也还是居高不下，metal的updatebuffer方法无论帧数多少一直是以很高的频率在执行，也不知道是不是这个的问题，但消息队列找半天也没找到哪里push的消息，这3.3搞的这一块引擎代码逻辑太复杂了。
引擎团队如果优化不以实际项目做测试，我很担心3.4依然渲染时间过高，导致持续得不到解决，升级后的项目前有狼后有虎，无法继续开发，只得等着引擎团队来解决这个问题。
得了，天天出去遛娃等着引擎团队的好消息好了，有玩家问进度我就告病，这个太复杂插不进手，也不出活，从零开始去优化一个底层的复杂逻辑问题想想都有些害怕。
兄弟我看你drawcall有点高哦。你render time是在电脑web就高么？。那和我有点差别。我是iOS小游戏才有点离谱的高。感觉你可以先优化下drawcall。可以参考下江南百景图的那个PPT
ios复杂场景300多些，很合理，内容复杂drawcall已经优化到了极致。web700多是因为没自动合图，就一句话，2.4.6 13ms 3.3.2 36ms，如果按照cocos官方的宣传方法，可以说3.3.2比2.4.6的渲染时间消耗翻了近三倍
确实可以再尝试下drawcall，300有点太高了，江南百景图那种主城也很复杂，可以优化到只有6个drawcall。
在 2D 性能上，3.x 和 2.x 是有差距的，2.x 针对 2D 渲染是有原生渲染器的，3.x 全是在 ts 层做的流程。所以 2D 性能会好不少，我们正在优化这个差距，但是短时间内还优化不上来。我们先看看你的热点和我们查出来的是否一致，不过短期内是优化不到 2.x 的水平，方便的话你可以把构建的包发到 784358070@qq.com