更新
根据测试,IOS 3.3.2的3D性能是明显优于2.4.6的
更新
1.2D renderer ms过高:相同的场景在IOS,2.4.6,渲染时间为13ms左右,而3.3.2渲染时间在35-37左右,此问题官方已在优化当中,且在9月底的3.4计划中就有渲染时间的优化计划。
2.内存占用:当场景元素较多的时候(png,只限于2D),内存会爆表,原因是引擎加载资源占用了一份内存,提交到metal后又占用了一份内存,导致双份内存占用。
引擎本身对此问题就是留有优化的,打开即可。
main.js添加如下代码
cc.macro.CLEANUP_IMAGE_CACHE = true;
cc.dynamicAtlasManager.enabled = false; //动态合图根据自身情况开启。
如果效果不明显,可将引擎占用的内存强行释放(需自定引擎)
旧贴,无需看
更新
尝试优化这个问题,经过查看源码,这也不能算一个bug,只是优化没做好,看了与metal相关的部分代码并学习了一点metal,这一块优化也并不简单。
但能用上metal的话,这些尝试是值得的。
捋了捋大致的加载逻辑是这样
一、JS调用load texture的请求->jsb_global_load_image->createImageInfo->callback将纹理的data回调给JS,JS处理后供开发者使用
二、与此同时发起渲染队列请求,将textureInfo(纹理的信息)MessageQueue给metal渲染,metal消费此消息并执行,根据纹理信息newTextureWithDescriptor新开内存创建出mtlTexture。
同时入列纹理填充的消息 ----> copyBuffersToTexture-> [mtlTexture replaceRegion:…];
上传纹理数据至新开的内存,从而导致第一步内存和 新开内存同时存在数据
我一直在尝试让metal使用第一步的内存,避免额外创建,但要捋一遍整体加载逻辑,又牵扯queue,挺麻烦的,望引擎团队做这一块的人能插手进来
测试机:IPHONEX
系统版本:14.4.1
游戏场景如图,在进入游戏场景前即需要大量的加载资源。(图为WEB端表现)
在进入之前,会有预加载的处理,预加载方式如下
将进入场景所需的资源全部加载到内存中,且使用map存索引,之后再使用此图片/资源的时候,在map中查询以复用
测试对比方式如下,登录相同的账号,在预加载完成后进入游戏场景查看内存占用(如果单独对比预加载,3.3.2内存占用大约在1.45G,为了同时查看CPU的占用情况,所以下方截图都是进入游戏主场景后的占用情况)
3.3.2版本内存及CPU占用
2.4.6版本内存及CPU占用
在3.32中,如果将cc.resources.load 更为 cc.resources.preload,那么预加载的过程大约需要470-500MB内存,但进入游戏场景后立刻飙升到1.1GB,就不截图了,虽然相较load降低了一部分,但也在崩内存的边缘了。
对比都是在不使用压缩纹理的情况下,因为热更新的缘故,所以线上项目也并没有使用压缩纹理,不在考虑范围,同时压缩纹理的构建速度太过夸张的慢了,素材少了还行。