他应该是先测试引擎占了多少内存,减去引擎的内存再去计算。或者多加个十几二十张大图片
可能内存瓶颈不在图片上。导致图片压缩后实际变化不大。
这个波动范围太大了, 可以搞个按钮,分别加载 astc 和png 对比 两个图片代来的内存增长。
这种讨论没有意义 , 压缩纹理内存占用规则肯定是生效的。
1赞
我写了个按钮,点击后会依次加载40张大约1000x1000尺寸的图集,对比结果:
ASTC8x8:内存从160MB,加载结束后涨到约200MB
PNG:内存从160MB,加载结束后涨到约205MB
差距为40/45=89%
感觉确实差距不大
这数据看起来不对啊1000*1000一张加载进内存就是将近4m,40张应该是160m左右,astc加载完才200m符合预期,png版应该300多M符合预期
跟踪学习下~
看看 png 解析的时候 Image 走的是哪个初始化方法
对,你说的数据才是理论上正确的。
根据他的内存曲线波动来看,使用png的时候应该触发了gc,而astc那里没有触发gc。会不会有一定的原因。
或者在哪里有什么自动释放的机制?
请问要怎么看呢
我在 web 端测试了一张压缩前后显存大小,显存有明显下降,但是 内存快照没有太多区别。
是不是没有开启这个选项<CLEANUP_IMAGE_CACHE>来删除原始图片缓存,这个在web端默认是关闭的
有可能哦,我再尝试一次
我看我用了内存也没多大变化…大佬找到原因了吗?
这个开关,有注意到吗??


