三个PNG，一个是10241024，第二个是1024512，第三个是1024*256。
这三个图CCSpriteFrameCache::sharedSpriteFrameCache()->addSpriteFramesWithFile进行加载。
占内存分别是4MB、2MB、1MB，这样计算对吗？
不是，和格式等等有关。
你可以通过
log(TextureCache::getInstance()->getCachedTextureInfo().c_str());
打印你的内存使用情况。
那是什么得code
哥们，你这是什么代码呀？c++吗？
哥们，这是上古cocos2dx，这坟刨的，这是c++
谢谢提醒。
昨天面试问我这问题，我就想问一句知道这个有什么帮助？
你把这个亮出来，你就通过了
1赞
算内存大小啊，不然你怎么知道内存临界值
图像占用内存的公式是： numBytes = width * height * bitsPerPixel / 8
OpenGL ES 纹理的宽和高都要是2次幂数, 以刚才的例子来说, 假如 start.png 本身是 480x320, 但在载入内存後, 它其实会被变成一张 512x512 的纹理, 而start.png 则由 101x131 变成 128x256, 默认情况下面，当你在cocos2d里面加载一张图片的时候，对于每一个像素点使用４个byte来表示–１个byte（８位）代表red，另外３个byte分别代表green、blue和alpha透明通道。这个就简称RGBA8888
图像宽度（width）×图像高度（height）×每一个像素的位数（bytes per pixel） = 内存大小
此时，如果你有一张５１２×５１２的图片，那么当你使用默认的像素格式去加载它的话，那么将耗费
５１２×５１２×４=１MB
1MB = 1024 KB= 1024*1024 B
2赞
和图片格式有没有关系？比如RGBA8888和RGBA4444
我刚刚看了一下是和图片格式有关系的，那么计算就只能靠脚本遍历文件来检测累计，不考虑脚本内开辟的空间，那么这样计算出来根本不符合实际情况，想知道真实的内存占用还不如打开游戏玩几把，记录前后内存对比
基本上格式是一样的，跟美术统一好
请教一个问题，每张png我都会压缩，压缩后能节省80%的空间，也会有一些失真，但序列帧实际也看不出差别，压缩后在内存中是不是也会节省占用
内存只跟图片格式和图片大小有关系，还压缩是减少像素级别，只会减少物理硬盘占用大小，不会减少内存大小
也就是说一张2048*2048 的png无论压不压缩，对性能的影响都是一样的是吗，那这样把png压缩到极致相比耗费的精力和工作量，并不是那么值得去做，毕竟现在网络普遍较好，包体大一些也不成为负担
一张图片加载后要在游戏里显示出来它就得转化成渲染所用的纹理
公式 numBytes = width * height * bitsPerPixel / 8*
这个bitsPerPixel 就与像素格式有关了
一个像素的组成
A：透明度
R：红色
G：绿
B：蓝
ARGB_8888：每个像素占四位，即A=8，R=8，G=8，B=8，那么一个像素点占8+8+8+8=32位
ARGB_4444：每个像素占四位，即A=4，R=4，G=4，B=4，那么一个像素点占4+4+4+4=16位
ALPHA_8：每个像素占四位，只有透明度，没有颜色
1赞
压缩是值得做的，不能只考虑内存消耗，还有IO
读一张1MB的图，始终是比读一张10MB的图快