（DOC）Displaying Bitmaps Efficiently
这篇是翻译的,
此次是实践,是关于Android系统的图片解码的实例
文中说到:
摄像头在GalaxyNexus拍一张照片有2592*1936像素，如果bitmap使用ARGB_8888配置（2.3默认的），加载这张照片到内存需要消耗约19mb内存，（2592*1936*4bytes）
19m的内存对模拟器的16m来说,显然太大了,但对于真实的机器 ,还是可以的
至于说Android的图片内存8m,这个不知道是听谁说的,总之我也没有找到标准的答案,有可能是在Android刚出来的时候定义的一个堆大小,我觉得最有可能的是这个值作为图片解码的内存大小,却不是对图片的大小限制的.所以上面的图片是可以解码显示出来的.
先说下情况:
一张440*17514大小的图片,直接在galaxy上解析,然后得到Bitmap,再放到ImageView中显示,一切正常的.说下galaxy的情况:
/system/build.prop中的heapsize=64m
两种方法,一种是argb_8888配置,一种 是rgb_565
实践也表明了,两种图片解码后的效果差不多的,如果不是图像处理,完全可以用rgb_565来处理图片的显示,
显然这张图片解析需要29m左右的内存,<64m.所以我觉得Android的内存限制不是只是图片上,而是整个进程的,当进程占用的内存没有超过这个值,就是正常的,而,解析图片通常是最耗内存的操作.
在ImageView中显示一张,argb_8888,然后再解码一次,29*2+其它的操作,对象内存,勉强>64m了,只能解码一次.
使用rgb_565解码一次15m左右,可以有四次的机会,为什么不是三次呢,29*2<64,但一次解析大图,消耗的其它对象内存也大了.
于是修改了/system/build.prop中的heapsize=48m,重启了,
再运行,argb_8888一次解码正常的.二次崩溃.
使用rgb_565解码,可以两次,三次崩溃.
于是修改了/system/build.prop中的heapsize=24m,重启了,
再运行,argb_8888一次崩溃.
使用rgb_565解码,可以一次,第二次崩溃.
,由此可见,不是一张大的图不可以显示出来,通常一张拍摄的照片像2592*1936这样的,有这样的分辨率,就有相应的机器对应,所以内存也就大了,不是所谓的8m.
由于只分析了一些实践结果,对系统的代码没有研究,有可能这是不对的,或许
c对解码图片作了一些内存上的限制.
但是可以知道,8m的内存是不对的,即使现在新机器中最烂的也不小于512m的内存,heapsize也>24m,所以对于上面这种大的图片,使用rgb_565解码,是没有问题的.
final int memClass = ((ActivityManager) this.getSystemService(Context.ACTIVITY_SERVICE)).getMemoryClass();
System.out.println("memClass:"+memClass);
可以得到这个值的大小.
最近做的微博程序中大图浏览直接崩溃,内存不足,64m的内存,缓存各种图片64张,图片大小大约是在400*1600,几十张图片加载后就崩溃了.
当然如果没有必要,还是缩放一下较好:
BitmapFactory.Options options = new BitmapFactory.Options();
使用缩放的效果明显要比使用rgb_565解码糟糕的多了.