一、2d游戏最占内存的无疑是图片资源。 二、cocos2d-x不一样平台读取纹理的机制不一样。ios下面使用 CGImage,android和windows下是直接调用png库。我测试了下,使用png库直接读取png会比CGImage还要节约1mb左右内 存(图片所占内存4mb)可是速度要比CGImage慢一倍。时间和空间如何取舍就看实际状况了。不过最佳的选择彷佛是pvr(即便android版本, 即便不使用pvrtc4)。 三、通常来讲,咱们能够直接使用 w * h * bpp获得一张纹理所占的内存,好比一张1024*1024格式为argb8888,那么他所占的内存就是1024*1024*4=4mb。以前看到有博 客提到jpg会开辟3倍与此的内存(先转换为png,而后解析png),可是新的ios系统彷佛没有这个问题。jpg与png所消耗的内存几乎相同,而且 jpg解析速度更快(几乎都是4mb解析+4mb纹理数据,而jpg解析时间是png的一半),可是这样反而很怪异,由于jpg是没有透明色的,一个像素 最多3字节,而png一个像素4字节,jpg纹理应该占用内存更小才对,后来看了下cocos2d的ios加载图片的代码,它把全部纹理转换成 rgba8888格式,因此不管是jpg仍是png,占用的都是4字节。正因cocos2d对其余纹理支持不够好,pvr才会显得那么高效。 四、pvr格式能够被显卡所承认,而不须要开辟临时内存来读取,因此即使同为 argb8888格式的图片,pvr也会比png有效率,虽然不会节约程序稳定运行时的内存,可是会避免加载大量图片时的内存暴涨。 而且若是是ios设备的话,可使用pvrtc4格式的图片,这个格式至关于windows下的dds图片,是能够被显卡直接支持的。它是有损压缩,一 个像素只占4位,不过若是不是有渐变半透明色的话,通常效果能够接受,而其节约的内存和cpu时间很是很是显著。 五、pvr也不是万金油。android设备下虽然可使用pvr格式,可是不能使用pvrtc4,但愿经过pvr像ios设备上同样真正减小游戏内存是不太可行的。 六、pvr.ccz其实就是pvr图片zip打包下,程序读的时候仍是先解压出pvr资源,而后再读取pvr。不过因为压缩下能够极大的减少图片体积,因此虽然多了解压过程也不会有特别多的cpu消耗。 七、一张jpg图片实际加载过程内存消耗,以一张1024*1024 argb8888 500k的jpg图片为例: a.读取图片文件(消耗图片大小内存,500k) b、解析jpg数据(cgimage, 4mb) c、释放500k的图片内存 d、opengl纹理数据(4mb) e、释放cgimage的4mb内存。 注意,这个过程不是必然的顺序执行,释放cgimage内存的实际是有系统决定的,会很快,可是不必定是当即执行。 因此内存会瞬间飙升9mb左右,而后减小5mb,稳定到4mb左右 png图片的加载过程与此相同 pvr图片能够节约解析图片数据到纹理这一步的消耗。也就是说读取pvr图片资源(等价于解压pvr.ccz到内存,若是是1024*1024 argb8888格式的话,那么图片大小就是4mb,ccz压缩后图片1mb左右)消耗4mb,将pvr图片数据提交给显卡消耗4mb。而后释放文件数据 4mb。这么看彷佛跟Png从内存占用上相比也不是很是有优点。(注意这里说的pvr是指pvr封装的argb8888,与pvrtc4的性能有天壤之 别) 八、因为最终消耗内存的都是纹理数据,因此只要纹理数据格式是必定的,不管图片是什么 格式消耗的内存都是同样的。好比使用Png8图片,体积会减小70%,可是内存占用与png24/png32是等价的(读取的时候会内部把调色板还原成真 彩色,也就是说,虽然png8是一个像素只占8位,可是读取到内存中的时候会将调色板颜色还原,依然须要开辟1024*1024*4字节的空间存放纹理数 据)。 固然有无透明色,cocos2d的处理仍是有区别的。若是是无透明色,可使用png24,那么所需开辟的纹理空间就是3mb。 这里还有一点须要说明,通常咱们处理windows下的dds纹理的时候,都习惯将其按2的整次幂对其,虽然图片内容只有900*900,可是图片大小 倒是1024*1024。那咱们读取这个图片所消耗的内存就是4mb,按2的整次幂对其是有助于提升运行效率的,可是不是很是必须的。ios和 android的设备都支持非2的整次幂的纹理。因此若是是png图片,那么它该多大就多大。此时消耗的内存就只有900*900*4=3mb。 九、不要过于迷信所谓的去除alpha通道以节约内存。这个还要实际分析下具体结果。 我测试过(分别用cocos2d-x和鬼火3d引擎),rgba8888 和rgb888格式的png图片显示所消耗的内存是同样的。24位图片虽然读取的时候开辟的内存只有3mb(1024*1024*3,注意若是是用 CGImage读取的话,那这个值就是4mb),可是glTexImage2D提交给显卡后依然会增长4mb内存。可能跟显卡的数据对齐有关。 这里我测试还有一个诡异的地方,若是是用pvr的npot图片的话,rgb888要比rgba8888所消耗的内存要小,可是pot图片二者又是同样的(png图片两种状况都是同样的)。多是powervr显卡有特殊处理。 十、rgb565和rgb5551的图片所消耗的内存是rgba8888的一半,若是没有透明渐变的话,视觉上也看不出什么区别。一些大的背景图能够优先选择这种格式。 十一、pvr图片加载速度要比png和jpg快3~5倍(一样1024*1024 argb8888),png消耗的时间多是700ms左右,可是pvr只须要100ms左右。若是是pvr.ccz压缩下,消耗的时间是200ms左 右。可见pvr在加载速度上仍是有很是大的优点的。这个应该是由于png和jpg须要把图片数据还原为rgba,可是pvr能够直接把图片数据传递给显 卡。pvrtc4的图片是能够被powervr显卡直接支持的。 总结下: 一、最终决定图片占用内存的是它的像素格式和大小,与其扩展名无关。png8 png32 jpg pvr只要其像素格式都是argb8888,那么最终图片占用的内存是同样的。 二、若是不是pvrtc4的格式,那么不要扩展成2的整次幂,由于图片越小,占用内存越小 三、单单去除透明通道不会减小图片所消耗的内存,png和jpg图片也没法减小图片体积,因此不推荐rgb888的格式。替代选择rgb565和rgb5551。 五、当心加载图片时临时开辟的纹理数据形成的内存飙高,能够考虑加入内存池,及时的开辟和释放缓冲区。 六、若是是为了减小图片体积能够选择:一、jpg--压缩比最高,质量较好,可是不支 持半透明 二、png8--一样图片会比jpg略大一些,使用ImageAlpha进行转换,视觉上几乎看不出差异。 这两种图片格式均可以极大的减小图片体积(减小70%~80%),可是无助于减小内存 七、若是是为了减小内存能够选择:一、没有透明色的图片统一转换为rgb565格式, 这个时候没法使用png8了,因此png和pvr.ccz图片大小几乎相同,pvr.ccz速度更快,因此推荐pvr.ccz的rgb565格式 二、若是透明色仅仅是进行关键色标注,而没有渐变混合,那么推荐rgb5551 (r5_a1)的pvr.ccz格式 八、能够考虑写个打包系统,统一把资源文件打包,而不是单个文件用pvr.ccz进行zip压缩,这样能够得到更高的效率。(好比我封装了下暴雪的mpq打包,其读取速度与本地文件读取速度至关,这样就能够得到最佳的读取效率) 最后附上我测试的数据日志,图片是一张1024*1024的图片,实际图片内容大小为960*700。测试设备iphone4,png jpg等图片加载代码修改成windows版本。tex后面是图片的加载时间。 over后面的括号里面是图片加载所消耗的内存。 2012-12-27 14:28:54.614 HelloCpp[4939:707] cocos2d: surface size: 960x640 Cocos2d: cocos2d: cocos2d-2.1beta3-x-2.1.0 Cocos2d: cocos2d: GL_VENDOR: Imagination Technologies Cocos2d: cocos2d: GL_RENDERER: PowerVR SGX 535 Cocos2d: cocos2d: GL_VERSION: OpenGL ES 2.0 IMGSGX535-63.24 Cocos2d: cocos2d: GL_MAX_TEXTURE_SIZE: 2048 Cocos2d: cocos2d: GL_MAX_TEXTURE_UNITS: 8 Cocos2d: cocos2d: GL supports PVRTC: YES Cocos2d: cocos2d: GL supports BGRA8888 textures: NO Cocos2d: cocos2d: GL supports NPOT textures: YES Cocos2d: cocos2d: GL supports discard_framebuffer: YES Cocos2d: cocos2d: GL supports shareable VAO: YES Cocos2d: cocos2d: compiled with Profiling Support: NO tex 195 map_001_BG.pvr map_001_BG.pvr ---over proess:11.0mb (4.0mb) free:274.6mb tex 159 map_001_BG_rgb.pvr map_001_BG_rgb.pvr ---over proess:15.0mb (4.0mb) free:270.6mb tex 711 map_001_BG.jpg map_001_BG.jpg ---over proess:19.1mb (4.1mb) free:266.7mb tex 653 map_001_BG_rgb.jpg map_001_BG_rgb.jpg ---over proess:23.1mb (4.0mb) free:262.6mb tex 670 map_001_BG.png map_001_BG.png ---over proess:27.1mb (4.1mb) free:258.7mb tex 739 map_001_BG_rgb.png map_001_BG_rgb.png ---over proess:31.1mb (4.0mb) free:254.3mb tex 240 map_001_BG.pvr.ccz map_001_BG.pvr.ccz ---over proess:35.1mb (4.0mb) free:250.4mb tex 204 map_001_BG_rgb.pvr.ccz map_001_BG_rgb.pvr.ccz ---over proess:39.2mb (4.0mb) free:246.5mb tex 97 map_001_BG_rgb565.pvr map_001_BG_rgb565.pvr ---over proess:41.2mb (2.0mb) free:244.6mb tex 710 map_001_BG_rgb565.png map_001_BG_rgb565.png ---over proess:45.2mb (4.0mb) free:241.1mb tex 591 map_001_BG_rgba8888f.png map_001_BG_rgba8888f.png ---over proess:47.8mb (2.6mb) free:238.3mb tex 484 map_001_BG_rgba8888f.jpg map_001_BG_rgba8888f.jpg ---over proess:49.7mb (1.9mb) free:236.5mb tex 123 map_001_BG_rgba8888f.pvr map_001_BG_rgba8888f.pvr ---over proess:52.4mb (2.7mb) free:234.1mb tex 589 map_001_BG_rgb888f.png map_001_BG_rgb888f.png ---over proess:55.1mb (2.7mb) free:231.2mb tex 478 map_001_BG_rgb888f.jpg map_001_BG_rgb888f.jpg ---over proess:57.0mb (1.9mb) free:229.4mb tex 92 map_001_BG_rgb888f.pvr map_001_BG_rgb888f.pvr ---over proess:59.0mb (2.0mb) free:227.8mb (lldb) 第二个日志是ios版本的图片加载,其余与上一个相同,能够看到速度要比windows版本的png加载快一倍,可是内存消耗更高 2012-12-27 15:36:10.330 HelloCpp[4979:707] cocos2d: surface size: 960x640 Cocos2d: cocos2d: cocos2d-2.1beta3-x-2.1.0 Cocos2d: cocos2d: GL_VENDOR: Imagination Technologies Cocos2d: cocos2d: GL_RENDERER: PowerVR SGX 535 Cocos2d: cocos2d: GL_VERSION: OpenGL ES 2.0 IMGSGX535-63.24 Cocos2d: cocos2d: GL_MAX_TEXTURE_SIZE: 2048 Cocos2d: cocos2d: GL_MAX_TEXTURE_UNITS: 8 Cocos2d: cocos2d: GL supports PVRTC: YES Cocos2d: cocos2d: GL supports BGRA8888 textures: NO Cocos2d: cocos2d: GL supports NPOT textures: YES Cocos2d: cocos2d: GL supports discard_framebuffer: YES Cocos2d: cocos2d: GL supports shareable VAO: YES Cocos2d: cocos2d: compiled with Profiling Support: NO tex 196 map_001_BG.pvr map_001_BG.pvr ---over proess:11.0mb (4.0mb) free:275.8mb tex 160 map_001_BG_rgb.pvr map_001_BG_rgb.pvr ---over proess:15.0mb (4.0mb) free:271.9mb tex 130 map_001_BG.jpg map_001_BG.jpg ---over proess:19.3mb (4.3mb) free:267.6mb tex 151 map_001_BG_rgb.jpg map_001_BG_rgb.jpg ---over proess:23.5mb (4.2mb) free:263.8mb tex 344 map_001_BG.png map_001_BG.png ---over proess:28.7mb (5.3mb) free:258.7mb tex 328 map_001_BG_rgb.png map_001_BG_rgb.png ---over proess:34.0mb (5.3mb) free:253.6mb tex 237 map_001_BG.pvr.ccz map_001_BG.pvr.ccz ---over proess:38.0mb (4.0mb) free:249.6mb tex 221 map_001_BG_rgb.pvr.ccz map_001_BG_rgb.pvr.ccz ---over proess:42.0mb (4.0mb) free:245.2mb tex 98 map_001_BG_rgb565.pvr map_001_BG_rgb565.pvr ---over proess:44.0mb (2.0mb) free:243.2mb tex 300 map_001_BG_rgb565.png map_001_BG_rgb565.png ---over proess:48.9mb (4.9mb) free:238.2mb tex 293 map_001_BG_rgba8888f.png map_001_BG_rgba8888f.png ---over proess:52.8mb (3.9mb) free:234.2mb tex 87 map_001_BG_rgba8888f.jpg map_001_BG_rgba8888f.jpg ---over proess:55.7mb (2.9mb) free:231.7mb tex 143 map_001_BG_rgba8888f.pvr map_001_BG_rgba8888f.pvr ---over proess:58.3mb (2.7mb) free:228.8mb tex 300 map_001_BG_rgb888f.png map_001_BG_rgb888f.png ---over proess:62.2mb (3.9mb) free:225.3mb tex 87 map_001_BG_rgb888f.jpg map_001_BG_rgb888f.jpg ---over proess:65.1mb (2.9mb) free:222.7mb tex 91 map_001_BG_rgb888f.pvr map_001_BG_rgb888f.pvr ---over proess:67.0mb (1.9mb) free:220.7mb (lldb)