@hsy5201118 来活儿了
顶 性能是引擎的根基 必须要重视
关我啥事。。。。我没资格进官方，而且我一不会改引擎、二不会用3.x。。。。我就是个菜狗 
看到好几个版本说性能提升了多少多少。。。。
1赞
metal用好了确实会像2.2用v8一样带来大的提升
我估计官方在这帖子之前就是知道这个问题的
难道就我关注web加载这个吗？ 
虽然说web的加载比较碎片化，但是同样的代码逻辑和资源能和2.2差别这么大，肯定是有问题的。天天在web上调试，每次进游戏等半天。绞尽脑汁的优化加载，都没能实现质变，苦啊
你贵哥发帖，你起码得表面下态度！
感谢分析，我们尽快确认完善，渲染器重构完确实有不少细节还没来得及优化，但是热点问题一定会重点重视的
3赞
态度就是：向勇者致敬，感谢勇者为我们踏平道路
1赞
有没有测试包给我们跑一跑？
加密build一个ios项目行吗
我想看 web 项目的加载速度对比那个行么
我抽个demo
Metal 内存问题已经建立内部 issue 跟踪，在 3.4 测试阶段尽快确认，目前还有一些工作没收尾需要一点时间。
另外，麻烦补充一点信息，这个项目在 2.4 和 3.3 上的 dynamic atlas 和 clear image cache 的开启情况如何？
我测试一下
cc.macro.CLEANUP_IMAGE_CACHE = false;
cc.dynamicAtlasManager.enabled = true;
之前有段时间尝试使用动态合图，但不好用，具体因为什么记不得了，好像是因为合图太占用内存，多了几百MB，控制起来很麻烦，对drawcall优化又没什么效果，最后是代码控制合批，ios的性能瓶颈在jit，当时整个场景合批到几十个drawcall（不带UI），复杂场景帧数还是跑不满60。
cc.macro.CLEANUP_IMAGE_CACHE = true;
cc.dynamicAtlasManager.enabled = false;
少了一点
强行释放image_cache的话
[mtlDevice currentAllocatedSize] 方法获取到的占用为750MB，算上V8等占用，似乎合理了很多，释放image_cache暂时没发现什么副作用，900多MB起码能做调试了
如果取消预加载，进入主场景的速度比2.4.6大幅加快了，快不少，比WEB都快，且和使用预加载的速度差不多，当前来看IOS没必要预加载，应该和metal有关？？这个提升很惊喜。
【但在WEB如果不预加载，场景速度会明显的慢，无法瞬间将所有场景建筑立刻加载出来，需要的话我提供个WEB端的视频】
在取消预加载后，一些不直接使用的资源就不会占内存了，所以又省出了一点空间。
强行释放imageCache暂时能做调试继续开发了，无需折腾内存问题了
//我在考虑创建MTLTexture的时候就把图片的data传进来，也就是拓展TextureInfo
然后通过
//这个方法来创建MTLTexture，如果这个行不通就在创建buffer阶段通过已有内存创建，也是一点点尝试
在2.4.6帧数设置为60的时候，进入游戏场景CPU占用会在100%左右，设置为30在55%左右。
而3.3.2设置为30的时候CPU占用就到了100多，且帧数维持在24左右，跑不到30，优化完内存估计还要再优化CPU占用
