[贾贵对比] 3.3.2 IOS 2D metal问题

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的话

image1894×1356 193 KB

image1300×530 41.5 KB

[mtlDevice currentAllocatedSize] 方法获取到的占用为750MB，算上V8等占用，似乎合理了很多，释放image_cache暂时没发现什么副作用，900多MB起码能做调试了

如果取消预加载，进入主场景的速度比2.4.6大幅加快了，快不少，比WEB都快，且和使用预加载的速度差不多，当前来看IOS没必要预加载，应该和metal有关？？这个提升很惊喜。
【但在WEB如果不预加载，场景速度会明显的慢，无法瞬间将所有场景建筑立刻加载出来，需要的话我提供个WEB端的视频】
在取消预加载后，一些不直接使用的资源就不会占内存了，所以又省出了一点空间。

image824×572 52.3 KB

---

强行释放imageCache暂时能做调试继续开发了，无需折腾内存问题了

//我在考虑创建MTLTexture的时候就把图片的data传进来，也就是拓展TextureInfo

image928×164 43.4 KB

然后通过

image2158×554 262 KB

//这个方法来创建MTLTexture，如果这个行不通就在创建buffer阶段通过已有内存创建，也是一点点尝试

---

在2.4.6帧数设置为60的时候，进入游戏场景CPU占用会在100%左右，设置为30在55%左右。
而3.3.2设置为30的时候CPU占用就到了100多，且帧数维持在24左右，跑不到30，优化完内存估计还要再优化CPU占用

3.3.2的GFX Texture mem显示不知道是不是正确

此方法获取到的大小明显大于调试信息，但我不关心这个，只是偶尔测试到了

在3.3.2 WEB运行上面demo的时候会发现GFX Texture mem 增长缓慢

web加载更慢

CPU的占用现在看来是因为render ms过高
2.4.6

13.41ms

3.3.2

36.37ms
导致frame time43.57ms

3.3.2 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。