探寻ASTC纹理压缩后，内存下降的实际值

Creator 2.x
#21

他应该是先测试引擎占了多少内存，减去引擎的内存再去计算。或者多加个十几二十张大图片

#22

可能内存瓶颈不在图片上。导致图片压缩后实际变化不大。

#23

这个波动范围太大了， 可以搞个按钮，分别加载 astc 和png 对比 两个图片代来的内存增长。
这种讨论没有意义 ， 压缩纹理内存占用规则肯定是生效的。

1赞
#24

我将加载的逻辑return，只加载代码分包，重新打了个安卓包，运行看到内存占用只有160MB，可以推断预制体+图片等的占用是有100MB左右的

6
61679×568 123 KB

#25

我写了个按钮，点击后会依次加载40张大约1000x1000尺寸的图集，对比结果：
ASTC8x8：内存从160MB，加载结束后涨到约200MB

7
7844×450 9.08 KB

PNG：内存从160MB，加载结束后涨到约205MB
8
8918×377 6.85 KB

差距为40/45=89%
感觉确实差距不大 :upside_down_face:

#26

这数据看起来不对啊1000*1000一张加载进内存就是将近4m，40张应该是160m左右，astc加载完才200m符合预期，png版应该300多M符合预期

#27

跟踪学习下~

#28

看看 png 解析的时候 Image 走的是哪个初始化方法

#29

对，你说的数据才是理论上正确的。

根据他的内存曲线波动来看，使用png的时候应该触发了gc，而astc那里没有触发gc。会不会有一定的原因。

或者在哪里有什么自动释放的机制？

#30

请问要怎么看呢

#31

我在 web 端测试了一张压缩前后显存大小，显存有明显下降，但是 内存快照没有太多区别。

#32

是不是没有开启这个选项<CLEANUP_IMAGE_CACHE>来删除原始图片缓存,这个在web端默认是关闭的

#33

有可能哦，我再尝试一次

#34

我看我用了内存也没多大变化…大佬找到原因了吗?

#35

这个开关,有注意到吗??

#36

顶起，请问各位大佬 这个有什么结论吗？

#37

3.8.7 版本。 web-mobile 使用 ASTC 和 PNG 没啥区别。

#39

:rofl: :rofl: :rofl: :rofl: :rofl:

#40

下载的是 astc 纹理，spriteFrame.texture.getPixelFormat() 获取的格式也是 astc 。

#44

ASTC/压缩纹理不一定比png小/省内存啊，png毕竟压缩率可以很大。
压缩纹理省显存/带宽，是和 raw rgba/纯像素流对比的。

png 使用时上传gpu需要解码为 raw rgba，那会变得很大，占用显存/上传带宽。
压缩纹理就不需要解码，直接上传gpu就行了，gpu硬件支持/直接用